Implementation Evidence
Truth Machine was distilled from multiple systems rather than designed from an empty abstraction. Each report is bounded to an exact revision and separates mechanically observed behavior from interpretation.
These are evidence reports, not retroactive conformance certificates.
| Implementation | Domain | Mechanisms evidenced | Facet required |
|---|---|---|---|
| Flow | Manufacturing-account coordination | Evidence, reviewed deltas, current truth, provenance, publications | No; optional outside cuts exist |
| Inference operations | Runtime fleet state | Typed current projection, full journal, governed live observation | No |
| Cloud operations | Shared hosting state | Ownership boundaries, exact deployment identity, observation, rollback | No |
| Project proposals | Pre-project decisions | Stable packets, exact source reviews, lifecycle, handoff | No |
| Kinra Corpus | Organizational truth | Evidence, immutable records, attributable atomic transition, current selection | Explicitly no |
Evidence classes
Section titled “Evidence classes”Some source repositories are private because they contain operational or organizational context. Their reports are bounded maintainer attestations: the named revision and conclusions are durable, but a public reader may not be able to inspect the complete source.
The Truth Machine reference repository is intended to provide a completely publicly auditable implementation after its bootstrap and first publication are accepted.
Transfer rule
Section titled “Transfer rule”A mechanism enters the portable specification only when:
- a concrete system paid for it through a real correctness or operating tension;
- the enforcing mechanism can be identified at an exact revision;
- its domain-specific schema can be separated from the semantic invariant;
- later implementations reproduce, narrow, or contradict the lesson; and
- the public claim states what remains unproved.