Source Intake & Authority

Why this page exists

The supplied documentation library contains thousands of files across architecture, implementation, Customer Zero, commercial operations, marketing, historical reports and duplicate/copy variants. It is valuable source material, not a single ready-to-publish authority tree.

⚠️

A document is not current just because it says “final,” “canonical,” “complete,” or “deployed.” Current architecture authority, code/configuration, tests and provider evidence decide what the product actually is and what is live.

Authority order

Current repository canonical architecture and explicit amendments.
Current code, tests, deployment configuration and provider/deployment evidence for implementation status.
Current subsystem contracts and registers.
Supplied structured Spine/Customer Zero source material where it is consistent.
Historical, commercial, marketing and duplicate source material as references only.

Source families and safe use

Family	Safe use	Do not use it for
Modular Spine documentation pack	Doctrine, flow descriptions, projection examples, contract vocabulary	Replacing the current canon without reconciliation
Master Index	Lineage, Workbench/UI concepts, vocabulary	Release/deployment evidence
v1.0 Book-of-Record export	Historical command/event/outbox/projection/reconciliation baseline	Automatic authority override
Customer Zero material	Internal proof-ring and operating-model detail	Claiming external readiness
Commercial/GTM/marketing material	Positioning, enablement, content plans and claim discipline	Runtime security or product-completion evidence
Copy/numbered variants	Version lineage only	Bulk import into this site

Material storage conflict

Historical v1.0 source describes Neon as a control plane and per-tenant D1 as live operational Spine truth. The current repository canon defines Neon/Postgres as canonical business truth and D1 as bounded operational state/projections.

The current model governs. No source page can authorize a second canonical writer, direct Workbench truth access or direct AI/provider mutation. A change would require a founder decision, migration/compatibility/rollback plan, security review, contract updates and deployment-like proof.

Reuse checklist

Before a source page is incorporated, record:

source file and date
→ source class: canonical / reference / historical / commercial
→ current authority compared
→ verified runtime / verified static / intended / drift status
→ conflict and resolution
→ destination owner
→ required test or provider evidence

Do not import a numbered or copy variant where a reviewed source exists. Do not repeat historical launch claims without current proof.

Release Readiness Onboarding