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.

What Nebbos commits to

Four commitments Nebbos makes to every client.

First — your data belongs to you, in every form it takes inside the platform. Second — every consequential action a Pearl takes carries the identity of a named human who approved it. Third — every action lands in an audit trail that is append-only, hash-chained, and portable to you. Fourth — if you ever leave, your data, your tuned Pearls, and your audit trail export in a machine-readable format on a timeline you control. These are not features. They are load-bearing properties of the substrate. Removing any one of them would require a substrate rebuild.

Why trust is architectural, not contractual.

Every enterprise SaaS contract contains language about data ownership, audit trails, and portability. Nebbos is architected so those commitments are properties the code enforces, not sentences the contract asks you to trust. Your data can’t touch another client’s — the database refuses the read before the query runs. Every audit record is signed the moment it’s written and locked in a chain the storage engine won’t rewrite. Portability isn’t a promise for offboarding day — the export routine runs on every deploy, so we already know it works when you need it. The contract describes what the substrate already delivers.

The four accountability pillars

The four accountability pillars.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Data ownership

Data ownership and portability, in detail.

You own every byte of data your client produces or ingests. This includes raw inputs (documents, events, transactions), Pearl-generated artifacts (proposals, drafts, plans), memory (accumulated context, preference pairs, tuning), audit records, and any derived intelligence. Nebbos’s license to your data is scoped strictly to operating the platform on your behalf — we do not train shared models on your data, we do not aggregate your data with other clients, we do not sell insights derived from your data to any third party. On offboarding, you receive a complete export: raw data + memory + tuned Pearl weights + audit trail + verifier tooling. The export runs on a timeline you control. After confirmed receipt, we execute a documented data-destruction routine and provide the certificate of destruction your legal team needs for retention records.

Which architecture layers make trust real

Which architecture layers make trust real.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Six commitments the substrate keeps.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Common questions from buyer, legal, and CISO.

  1. 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.

  2. Can we run our own client on our own infrastructure?

    Yes — single-client deployment is available on the enterprise tier. Contact enterprise@nebbos.ai.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Certifications

Attestations and certifications.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. GDPR + CCPA + state-privacy regimes

    DPA at /legal/dpa. Data-subject rights (access, correction, deletion, portability) implemented as first-class flows.

Related

  • Security — technical controls in depth

  • Compliance — frameworks and attestations

  • Legal — MSA, DPA, Responsible Disclosure

  • Architecture — the 15 layers

Read the deeper posture.

Trust · Accountable by architecture — Nebbos