Start with the execution model, the foundational execution architecture: reusable VM/OS support, open-ended compatible network instances, explicit proof profiles and independently placed workers.
| specification | scope |
|---|---|
| release train | origin source pins, stack/product gates, platform receipts and owner promotion |
| execution model | normative architecture; implementation coverage is reported separately |
| native node adapter | durable acceptance, request retry, HTTP bounds and legacy import |
| terms | shared vocabulary |
| types | data/type model |
| languages | language contracts |
| filenames | portable source-tree paths |
| vault composition | first storage/sync use case; secret custody, complete replicas and device-loss recovery |
| routing | the wire obeys the graph: greedy forwarding by locus over FOLLOW links, gravity-pressure fallback; radio stays transport, tru never dials |
Soft3 owns composition invariants. Trident, warriors, proof systems and node products own their specialized interfaces. Foundations explains the substrate; chains as plugins discusses protocol adapters over it.
report placement across the stack
Each repository keeps audits, implementation status reports, benchmark results
and release validation in its root audit/ directory, grouped by subsystem
when needed. specs/ and reference/ define contracts, invariants, formats and
acceptance criteria. Mixed documents keep their contract here and move observed
results into an audit report, linked from the relevant contract or index.
Reports retain their checked revisions, dates, evidence and limitations. Relocation updates relative links and graph paths together. A report's results describe the recorded check; a directory move does not revalidate them.