Privacy posture.
What we collect, what we refuse to collect, and how the Privacy Broker enforces both. Written in the OS register because privacy law is operating discipline, not legal boilerplate.
What we collect.
Three categories, and only three. Each is collected for a specific operational purpose, surfaced in audit logs, and bounded by the retention windows below.
Category one — operational data on contracted CRE assets.
For Beta Squad cohort members and Tier 1 / Tier 2 customers, the OS ingests CRE-domain data the customer explicitly grants us read access to: BMS / IoT signals, occupancy data (badge / Wi-Fi / sensor), CDE document streams (Procore / Autodesk ACC / Aconex / e-Builder / SharePoint), CMMS work orders, vendor SLA reports, lease abstracts. Always at the customer's direction, never by inference, never by scraping.
Category two — direct contact data.
Email address, name, organisation, role, jurisdiction, and the message you send via the contact / Beta Squad / Mix Daily forms. Used for the response and the publication subscribed to. Not sold, not rented, not enriched.
Category three — site analytics, minimised.
Anonymised page-view counts, referrer category, country-level geolocation. No tracking pixels. No cross-site trackers. No fingerprinting. The site analytics layer is documented in §07 below.
Every data ingestion the OS performs lands in the immutable raw layer (Provenance Hardening v61) with a SHA-256 content-address, file-permission chmod 444, and a per-source consent attestation. If we cannot point at the consent, we cannot ingest the data.
What we refuse to collect.
The refusal list is part of the architecture. Not a marketing posture, not a forward-looking statement — these categories are blocked at the substrate by the Privacy Broker and the Tool Guardrail. Even if a customer or operator wanted to onboard them, the system would refuse.
- Residential leasing PII. Tenant names, household composition, credit data, application records. We are commercial-only by deliberate Fair Housing posture; residential pipelines are out of scope and architecturally absent.
- Patient health information. HIPAA-class records, even when an asset is healthcare-occupied. The OS treats healthcare buildings as buildings; the OS does not touch the PHI inside them.
- Biometric data. Face recognition, gait, voiceprint. The Privacy Broker holds the BIPA + Colorado biometric July-2025 floor; biometric ingestion is blocked at the namespace gate.
- Free-text occupant communications. We do not parse occupant Slack, email, SMS, or chat. Occupancy signal flows through aggregated zone-level counts, not individual identifiable communications.
- Cross-tenant aggregation without consent. One tenant's data does not feed another tenant's brain. The B5 multi-tenant invariant is enforced in code at the brain-write boundary; cross-tenant flow is opt-in only via the deal-precedent librarian for archetype inference.
- Browsing / behavioural advertising data. The site does not run advertising trackers, retargeting pixels, or third-party advertising scripts. Ever.
How long we keep it.
Retention windows are designed against the operating purpose, not against the longest legal latitude. Default retention is the shortest period that lets the OS produce a useful citation chain.
- Operational CRE data — retained for the duration of the contracted engagement plus 90 days for transition handoff. On termination, the immutable raw layer is exported to the customer in CycloneDX-compatible format; our copies are then destroyed except for legally-required tax / audit retention.
- Direct contact data — retained until you unsubscribe or request deletion. Mix Daily subscriber lists are pruned of inactive addresses (no opens / clicks for 12 months) on a quarterly Sunday sweep.
- Site analytics — anonymised aggregates only; raw access logs purged after 30 days.
- Receipts ledger entries — receipts published with anonymised customer identity stay in the public ledger indefinitely (the ledger is append-only by Doctrine §II). Anonymisation parameters are documented in the Beta Squad terms; no asset name, address, or specific monetary figure unless explicitly cleared by the customer in the receipt envelope.
- Security incident logs — retained 24 months per OWASP ASVS Level 2 guidance.
The receipts ledger is append-only. Corrections land as new entries with back-references. We do not retroactively edit the ledger, which means once an anonymised receipt is published, it stays published. Anonymisation is the only protection on the ledger side, and it is rigorous — see §02 of Beta Squad terms for full detail.
Privacy Broker enforcement.
The CRE-EN Privacy Broker is the keystone privacy artifact in BEAST OS. It is described in operator language on the Detections page and in capital-efficiency terms on the PropOS Architecture essay. In legal language, the Broker enforces three discipline floors on every consequential data flow:
- Differential privacy. Laplace mechanism with explicit ε-budget per zone per day. Default
ε = 1.0. Once exhausted, downstream consumers receive a last-good envelope rather than a synthesized number from depleted entropy. The exhaustion is published on the receipts ledger. - K-anonymity floor. Default
k = 5. No bin released contains fewer than five distinguishable records. Increases tok = 10for sensitive zones (executive floors, medical isolation rooms, regulated-data spaces). - Regional consent rule pack. Eleven jurisdictions live: GDPR Art. 9, BIPA, CCPA, Colorado biometric (July 2025), EU AI Act, UK GDPR, SG PDPA, HK PDPO, JP APPI, AU Privacy Act, Korea PIPA. The applicable rule fires per asset jurisdiction; consent-on-file is a precondition, not a parameter.
The Broker fires on every cross-squad occupancy broadcast. Every fifteen minutes, the CRE-EN commander emits an OCCUPANCY_BROADCAST envelope — but only after the Broker has consumed the ε-budget, honored k-anonymity, and verified the consent gate. The envelope itself carries the audit trail; downstream squads that consume it carry the back-reference into their own decisions.
Eleven jurisdictions, one posture.
Most CRE-AI vendors localise privacy as an afterthought, and the result is a translation layer. We treated jurisdictional privacy as substrate from day one. The active rule pack:
- European Union (GDPR Art. 9) — special-category data prohibition; Article 6 lawful-basis enumeration; Data Protection Impact Assessment required for asset-occupancy fusion.
- United Kingdom (UK GDPR) — equivalent regime; ICO consultation thresholds tracked.
- Singapore (PDPA + PDPC) — consent withdrawal, data-portability, breach notification 72-hour rule, transferred to PDPC. SG-resident processing default for SG-located assets.
- Hong Kong (PDPO) — DPP1-DPP6 enforcement; cross-border transfer with consent.
- Japan (APPI) — anonymisation standards aligned with PPC guidance; cross-border transfer to GDPR-adequate jurisdictions only.
- Australia (Privacy Act + APPs) — APP 1-13 mapped; OAIC notifiable data breach scheme.
- South Korea (PIPA) — pseudonymisation per 2020 amendments; PIPC notification thresholds.
- United States — California (CCPA + CPRA) — verifiable consumer rights, opt-out of sale (we do not sell), AG enforcement.
- United States — Colorado (Biometric law, July 2025) — explicit biometric consent regime; honored at the namespace gate.
- United States — Illinois (BIPA) — written-consent biometric regime; enforcement through private right of action.
- European Union (EU AI Act 2024) — Title III high-risk-AI obligations on occupancy fusion; risk management + transparency + data governance + technical documentation per §11-15.
The applicable rule fires per asset jurisdiction at task start. The Broker reads the asset's jurisdiction tag and applies the correct rule pack; the customer's master engagement contract documents the cross-jurisdictional fallback if assets sit in multiple regimes simultaneously.
Your rights.
Whatever your jurisdiction, you have at least these rights. Some jurisdictions add more; we honor the more-protective standard when jurisdictions overlap.
- Access. You can request a copy of the personal data we hold on you. Default response time is 30 days; we usually return inside 14.
- Correction. You can request correction of inaccurate data. Same response window.
- Deletion. You can request deletion of your personal data. Operational data covered by an active engagement contract may be retained until contract end + 90 days handoff window; everything else (contact data, analytics, etc.) is deleted on request inside 30 days.
- Portability. You can request export of your data in a machine-readable format. We default to CycloneDX-compatible JSON for operational data and CSV for contact data.
- Withdrawal of consent. Where processing is based on consent, you can withdraw it at any time. Withdrawal is effective on the day the request is acknowledged.
- Objection. You can object to processing based on legitimate interest. We re-evaluate the balancing test inside 14 days and either continue (with documented justification) or stop.
- Complaint. You have the right to lodge a complaint with your supervisory authority (PDPC for Singapore, ICO for the UK, DPC for Ireland, your state Attorney General in the US, etc.). We will not retaliate, will cooperate with the authority, and will notify you in parallel.
To exercise any right, email beast.aicowork@gmail.com. The Founder reads every privacy request personally and acknowledges within three operating days.
Cookies + analytics.
The site runs no third-party advertising trackers, no retargeting pixels, no fingerprinting scripts, and no cross-site identifiers. The analytics layer is minimal and self-hosted.
- Essential cookies — session and CSRF tokens for the contact / Beta Squad / Mix Daily forms. Strictly necessary; you cannot opt out without losing form submission.
- Aggregate analytics — anonymised page views, referrer category (search / direct / link), country-level geolocation (no city, no postal code, no precise IP retention beyond 24 hours). Aggregated to the day-and-page level.
- Subscription analytics — Mix Daily subscriber metrics: opens, clicks, unsubscribes per issue. Standard email-platform metrics; not linked to site visits, not enriched, not sold.
If your jurisdiction requires explicit consent for non-essential cookies, the consent banner fires on your first visit and the choice is honored across the site. The default if you have not consented is essential cookies only, and the site fully functions in that mode.
Incident notification.
Operating incidents that affect personal data are notified to affected individuals and the relevant supervisory authority on the schedule the most-protective jurisdiction requires.
- Detection — Tier-1 security scanner chain runs against every untrusted input surface (web, email, RAG, handoff, Drive). Tripwires logged to
injection-attempts.jsonl; HIGH-severity events page the Founder inside 1 hour. - Assessment — within 24 hours of detection, the incident is scoped, blast-radius computed, and the remediation plan documented.
- Notification — affected individuals notified inside 72 hours (GDPR / SG PDPA standard); supervisory authorities notified inside the regulator's required window. We meet the shortest applicable window when multiple regimes apply.
- Public ledger — every confirmed incident lands on the Receipts page with severity, blast-radius, remediation status, and post-mortem reference. No retroactive edits.
- Coordinated disclosure — security researchers can disclose vulnerabilities to beast.aicowork@gmail.com; PGP key on request. Acknowledgement within 24 hours; coordinated disclosure timeline per OWASP guidance.
Privacy posture is operating discipline.
If you have a question this page does not answer, the Founder reads every privacy email personally inside three operating days.