Platform Truth
Use this page when you need the shared truth model for Helpifyr: contracts, projections, readiness, and documentation integrity that multiple repos or workflows rely on.
When to use this page
- You need to verify what the platform currently believes is true.
- You are comparing docs, source, and runtime posture.
- You need the common truth layer before operations, integration, or publication work.
Prerequisites
- You understand the owner split between source repos, reviewed docs materialization, and live publication.
- You can read route families under
/api/v1.
Truth model
Platform truth is the layer that turns distributed owner facts into shared, machine-readable, operator-usable evidence.
It includes:
- contract publication
- projection catalogs
- version and drift truth
- docs-system readiness and publication integrity
- readiness families that support bounded operator decisions
Architecture / Flow
Step-by-step procedure
1. Start with the common route families
Illustrative reads:
GET /api/v1/contracts/registry
GET /api/v1/contracts/drift
GET /api/v1/platform/projection-catalog
GET /api/v1/platform/version-truth
GET /api/v1/docs/platform
GET /api/v1/docs/readiness
2. Match the route to the kind of truth you need
- contracts:
- what is formally published
- drift:
- where expected and current state diverge
- projections:
- what operators and downstream consumers should read
- docs truth:
- whether publication and reviewed artifacts align
3. Use platform truth to arbitrate disagreement
If docs, runtime, or product behavior disagree, the first question is not “which page feels right.” The first question is “which shared-truth surface publishes the current verified state.”
4. Keep truth publication owner-clear
Platform truth does not erase source ownership. It publishes shared evidence while owner repos and runtimes still own their respective changes.
Verification
This page is being applied correctly when:
- the relevant truth family is identified
- disagreements are checked against shared-truth routes instead of assumptions
- owner boundaries remain explicit after the readback
Common failure modes
Using platform truth as a substitute for source ownership
Problem:
- readers stop tracking where the canonical source actually lives.
Better path:
- use platform truth as shared evidence, not as a replacement for owner identity
Comparing docs and runtime without checking a common truth surface
Problem:
- conflicts are argued from symptoms instead of evidence.
Better path:
- use the route family that publishes the relevant contract, projection, or readiness truth
Source Truth
- Mission Control and Operator Context
- Runtime Projection and Readback
- Docs Platform Truth
- Reference: API Surface Map
- Validation and Readback Workflow