Portability & export
Data portability is exercised on every production deploy rather than at offboarding. The platform executes a full export against scoped test tenants as part of every rollout, using the same code path a production operator export would use. A failure in the export path is a deploy-blocking failure.
Continuous exercise
The deploy pipeline executes a full export against a scoped test tenant on every production release. The export uses the same code path, tool chain, and bundle format that a production operator export would use. A break in the export path fails the deploy.
The operational consequence is that on any given day the export path has been exercised within the past several hours against production code. When an operator elects to move, the move is a data retrieval operation rather than a project initialisation.
Bundle structure
An operator-initiated export produces a single archive with five sections. Each section is described by a manifest included in the archive.
| Section | Content |
|---|---|
| Structured data | Every operator-scoped row from every substrate table the operator has touched, emitted as JSON Lines with stable field names. One file per table. Schema references accompany each file; schema changes within the export window are documented in the manifest. |
| Audit chain | Audit-chain entries scoped to the operator identities included in the export, accompanied by a signed hash-verification receipt. Independent verification does not require further platform calls. |
| Knowledge graph | The operator’s slice of the knowledge graph, including Pearl memory registers, insight rows, playbook selections, and prediction traces. Emitted as stable-shape JSON with per-node provenance. |
| Attachments | Uploaded documents, PDFs, images, and meeting recordings preserved in original bytes with original filenames and content types. Each file references its provenance in the structured data. |
| Cradle re-provisioning packet | For Host-tier and Architect-tier operators, a packet permitting re-mount of Pearl memory on a replacement Cradle. Issued only when the operator authenticates on a currently-held Cradle. |
Independent verification
Every bundle includes a verify.sh script. The script walks the audit-chain segment inside the bundle, recomputes every hash, and compares the result to the signed receipt embedded in the bundle metadata. Script dependencies are limited to POSIX shell, sha256sum, and a JSON parser.
tar -xzf nebbos-export.tar.gz
cd nebbos-export
./verify.sh
# Sample output:
# ✓ audit-chain: 12,483 entries walked, all prev_hash/next_hash bonds match
# ✓ signed receipt matches platform-issued receipt
# ✓ manifest checksums match file contents (1,247 files)
# EXPORT VERIFIEDThe bundle manifest documents every field the manifest carries, permitting a party unfamiliar with Nebbos source code to read the bundle format directly.
Bundle exclusions
The bundle contains only content the operator has a claim to. Nebbos internal operational data — model weights, shared platform artefacts, and other operators’ scopes — is not included, as the exporting operator has no claim to that content.
See The audit chain for independent chain verification and Row-level isolation for the enforcement of scope boundaries at the substrate.