Trust
Accountable by architecture.
Every action a Pearl takes is attested in an audit trail your CISO, your general counsel, and your regulator can read. The governance is the substrate, not a feature.
The four accountability pillars.
- Every human approval attested and time-stamped
Every consequential action is approved by a named human. The approval carries their identity, the timestamp, the context they saw, and the specific action they authorized. The record is signed the moment it’s written — verified end-to-end by your auditor’s own tool.
- Every Pearl action logged to an append-only audit trail
Every action a Pearl performs — every read, every proposal, every write — is written into an append-only chain. Each record depends cryptographically on the one before it. Your inspector-general walks the chain end-to-end and sees whether anything was inserted, altered, or removed.
- Every request carries identity through client isolation
Client isolation is enforced by the database itself, not by the application on top of it. Every query proves identity before it runs; a bug in application code can’t leak data across clients because the database refuses to serve the read. Structural, not policy.
- Every audit trail is portable to you if you leave
Audit-trail export is a first-class capability, not a departure-day scramble. Request a full export any time in a machine-readable format with an independent verifier. Because the routine runs on every deploy, you know it works when you need it.
Which architecture layers make trust real.
- Client isolation at the database
Enforced by the database itself, not by the application. A bug in application code can’t leak data across clients — the database won’t serve the read. Structural, not policy.
- Hardware-attested identity on every request
Every request carries an identity your CISO can trace. Service accounts, humans, and workloads each have distinct identity classes with distinct authorization scopes.
- Named human on every consequential action
Every write, every elevated call flows through an approval graph. Approval routes are configurable per domain, per action class, per risk tier.
- Portability tested on every deploy
Offboarding is a documented flow with fixed timelines. The export routine runs on every deploy so we already know it works when you need it.
- Audit trail your inspector-general reads directly
Append-only chain, hash-signed, verifiable end-to-end by your auditor’s own tool. The record your regulator reads.
Six commitments the substrate keeps.
- Your preference pairs train YOUR Pearl only
Preference pairs from your operators tune the Pearl running for your client. They do not train a base model available to any other client.
- Your metrics stay yours
No cross-client aggregation for our own benchmarking or marketing. Your operational metrics leave your client only when you export them.
- 30 days advance notice on any subprocessor change
The infrastructure vendors Nebbos itself runs on are disclosed at /legal/subprocessors. Enterprise customers get 30 days advance notice of any change. These vendors don’t touch customer data — that lives on the customer’s Cradle.
- Every consequential action carries a named human approval
Not a configuration flag — an architectural property. There is no version of the substrate where consequential actions run autonomously.
- Offboarding is documented, timeline-fixed, and tested
The export routine runs on every deploy so we know it works. No retention-friction pattern, no departure-day scramble.
- Every Pearl action ships with the reasoning trace attached
The human who approves sees why. The audit trail records what the Pearl considered and what it recommended before the human decision.
Common questions from buyer, legal, and CISO.
- How does client isolation actually work?
The isolation is enforced by the database itself, not by the application on top of it. Every request carries a client identity that the database checks against every row before it returns any data. Even a bug in application code can’t leak data across clients — the database won’t serve the read. Your engineers can review the enforcement themselves under NDA.
- Can we run our own client on our own infrastructure?
Yes — single-client deployment is available on the enterprise tier. Contact enterprise@nebbos.ai.
- What happens to our data if Nebbos is acquired?
The MSA carries an acquisition-continuity clause. Any acquirer inherits the data-ownership and portability commitments. If terms change, you trigger the accelerated-offboarding path with no exit fee.
- Can we get a copy of the audit-trail verifier tool?
Yes. It ships with the offboarding export and is available under NDA before then. Written in Rust; verifies hash-chain integrity independently of Nebbos infrastructure.
- What about model-provider data-retention?
Model-provider settings are configurable per client. Anthropic, OpenAI, Google, and self-hosted-model configurations each have distinct retention profiles. Default: zero-retention where the provider supports it.
- How do you handle a subpoena or law-enforcement request?
We route through counsel and notify the client unless legally prohibited. Detailed procedure at /legal/law-enforcement.
Attestations and certifications.
- SOC 2 Type II
Security, Availability, Confidentiality, and Privacy controls ship in the substrate today. The Type II report follows the audit window and is available under NDA when the auditor’s opinion issues. Full status at /compliance.
- ISO 27001:2022
Annex A controls are implemented across identity, access, audit, encryption, and data retention. The ISMS is on the certification track. Full status at /compliance.
- EU AI Act Article 11 · Annex IV
Substrate that generates Annex IV evidence ships today — memory captures model artifacts, reasoning captures decision provenance, attestation captures the audit trail. The client-facing documentation pack lands ahead of the 2027-08-02 deadline. Full status at /compliance.
- HIPAA — healthcare readiness
Technical safeguards ship today — access control, audit trail, integrity, entity authentication, transmission security. Administrative + physical safeguards + BAA template ready ahead of first healthcare deployment. Full status at /compliance.
- FERPA — K-12 and higher-ed readiness
Substrate controls mapped to FERPA educational-records handling. School Official controls, retention configuration, and documentation ready ahead of first district deployment scoped to student PII. Full status at /compliance.
- GDPR + CCPA + state-privacy regimes
DPA at /legal/dpa. Data-subject rights (access, correction, deletion, portability) implemented as first-class flows.
Deeper reading.
Security — technical controls in depth
Compliance — frameworks and attestations
Legal — MSA, DPA, Responsible Disclosure
Architecture — the 15 layers