Evaluation criteria

The following criteria distinguish institutional-grade operations intelligence platforms from application-layer AI products. Nebbos publishes documented evidence against each. Enterprise buyers may score any vendor — including Nebbos — against the same seven criteria using this reference.

01 · Isolation architecture

Institutional operations require data isolation enforced at the storage layer. Application-layer identity checks depend on every code path applying the check correctly; a single missed application check crosses the boundary. Nebbos enforces row-level isolation at the database. Every query is refused before an answer is composed.

Reference: Row-level isolation.

02 · Audit chain

Institutional operations require tamper-evident, append-only records of every substrate interaction. Application-layer logs support operational monitoring but do not satisfy regulatory chain-of-custody requirements. Nebbos writes every read, every write, every tier decision to a hash-chained audit chain that verifies end-to-end from the bundle without vendor involvement.

Reference: The audit chain.

03 · Data portability

Institutional operations require documented data portability. Export runs on every Nebbos deploy against a scoped test tenant, using the same code path a production export would take. The resulting bundle carries structured data, the audit chain, the knowledge graph, attachments, and a verify.sh script that verifies without Nebbos infrastructure. Operators may export at any time on their own timeline.

Reference: Portability & export.

04 · Approval attestation

Institutional operations require cryptographic evidence of human approval for privileged and administrative actions. Application-level policy enforcement records intent but not attestation. Nebbos issues Cradle-signed delegations at Host tier and enclave-signed approval tokens at Architect tier. Every approval is a signature the substrate verifies before state changes.

Reference: Authentication & tiers.

05 · Model-provider posture

Institutional operators require explicit disclosure of vendor model-training practices. Nebbos does not train foundation models. Operator data does not enter cross-tenant training corpora and does not improve shared models. Provider selection (Anthropic, OpenAI, Vertex) is per-operator policy and swappable.

Reference: Responsible AI, principle 03.

06 · API discovery pattern

Enterprise integrations require a discovery mechanism that accommodates platform evolution without client rework. Nebbos exposes a self-describing MCP surface. Integrations pin against list_available_tools, which returns the current tool roster with input schemas and per-tool tier gates. New capabilities become available on the next discovery pass without requiring an integration release.

Reference: MCP reference, OpenAPI spec.

07 · Portability on the operator’s timeline

Institutional operators require the ability to exit on their own schedule with data in an interoperable format. Nebbos publishes the export bundle format on this site. The bundle verifies with POSIX shell utilities (sha256sum, standard JSON parser) and carries every row, audit entry, and attachment scoped to the operator identity.

Reference: Portability & export.

Next steps

• Product datasheet — technical reference for a procurement packet
• Use-case library — deployment archetypes
• Business case — internal decision template
• Contact enterprise@nebbos.ai for a scoped assessment against your operational profile