6.uDoc Vault — versioned HTML documents, shared and annotated

1. Data model — projects, files, immutable versions

A project holds many files (folders, relative cross-links). Every file versions independently and immutably: nothing overwrites a version's bytes or its discipline report. Uploading a path that already exists appends a new version — a whole-folder re-upload bumps exactly the files that changed. No code path may update a V# item in place.

2. The discipline check — the document is untrusted

The platform's own users are the upload vector, and a document is untrusted content. The discipline check decides whether a version's scripts execute at all; its report is stored immutably with the version. Deterministic checks are authoritative for security; a Bedrock pass is advisory (findings + explanations) and authoritative for quality (e.g. the doc-theme palette). It fails closed: anything erroring or timing out saves the version with scripts disabled.

3. Rendering in an opaque origin

Bytes are fetched through the authenticated API and rendered via srcdoc into <iframe sandbox="allow-scripts"> — never allow-same-origin. With no separate serving hostname, that opaque origin is what keeps a live document away from Console cookies and tokens. Adding allow-same-origin, or serving documents as text/html on the Console origin, is a security regression that must not merge.

4. Sharing + version-anchored comments

Documents are shared to named Console members — the share picker is a real-user directory keyed by cognito:username, sourced from the obs activity table (only users who have actually signed in). A share can be revoked inline. Readers annotate the exact version they were looking at: a comment is pinned to the V# it was made against, so it never silently re-attaches to a later revision. Annotate mode blocks click-through so annotating never triggers the document underneath.

5. The system-publish path (automated writers)

Automated producers don't have a signed-in user, so Doc Vault exposes a system-publish path: a direct lambda:InvokeFunction carrying { source:'system-publish', … }, checked before the HTTP gates — the IAM invoke permission is the authorization (the same proof-by-invoke pattern as the trash sweep). It ensures a _system-owned project by fixed projectId, optionally grants a viewer, then runs the same commit invariants (discipline check + append-only version).

Two producers use it today: Foundation Audit (audit reports) and the Console MCP publish_evaluation tool (scheduled-evaluator reviews). Both write through the identical gate a human upload passes.

6. Files at a glance

• Design: cartridges/global/doc-vault/ANVIL.md (purpose, data model, threat model — read before changing anything)
• Backend: lambda/handler.js (JWT + X-Origin-Secret + system-publish), the store, and lib/system-publish.js
• Frontend: frontend/ — project tree, version viewer, share dialog, annotations, toolbar (Add Document · New Project · Download SDK)
• Authoring kit: creating a project offers a downloadable kit (CLAUDE.md + a doc-theme starter) so authored documents pass the discipline check by construction