This page explains how StoryMatrix claims are verified, rendered, and traced back to their source material.
🔹 🧭 Claim registry
90-evidence/claim-registry.json is the machine-readable ledger of project facts and defects. Each record has a unique claim_id, a record_kind, a lifecycle and verification state, a source path, and either executable evidence or a remediation reference appropriate to that record type.
| Lifecycle / verification | Meaning | Required evidence or metadata |
|---|---|---|
active/confirmed fact | The claim is current and confirmed. | A non-empty probe_id and its owning_test_node_id. |
active/confirmed defect | The defect is current and confirmed. | A remediation_reference or exception_reference. |
disputed/conflicting fact or defect | Available evidence conflicts or does not establish one interpretation. | A precise statement of the conflict; no executable probe is implied. |
disputed/stale fact or defect | The record is retained, but its evidence is stale. | A precise statement and its source context. |
planned/unsourced fact or defect | The claim is queued but not established by current evidence. | A statement of what evidence is missing. |
resolved/disproved defect | Evidence shows that the reported defect is not present. | The record remains as a historical audit result. |
superseded/* | The record is replaced by a page or a newer claim. | successor or no_successor_reason. |
archived/* | The record is retained for provenance but is no longer active. | successor or no_successor_reason. |
claim-registry.md is generated from this JSON file. Never hand-edit it: a renderer check compares the committed Markdown byte-for-byte with a fresh render.
🔹 🗃️ Provenance manifests
| File | Tracks |
|---|---|
90-evidence/migration-manifest.json | The migration disposition of source inputs, including active, archived, and protected material and its destination pages. |
90-evidence/legacy-route-manifest.json | Legacy URL paths and the route outcome each path must receive during the build. |
source-registry.json | The source-document inventory, including each input’s disposition, successor target, content hash, and review date. |
The source archive is historical provenance, not behavioral authority; current source code determines the published technical claims.
🔹 🛠️ Add or update a claim
- Edit
90-evidence/claim-registry.jsonand add a unique record with a repo-relativesource_path. - Render the generated page from the content directory:
# Working directory: <repo-root>/wikis/stmx
python3.11 scripts/render-claim-registry.py content- Validate the JSON registry:
# Working directory: <repo-root>/wikis/stmx
python3.11 scripts/validate-claim-registry.py content/90-evidence/claim-registry.json- Confirm the generated artifact is unchanged by a second render check:
# Working directory: <repo-root>/wikis/stmx
python3.11 scripts/render-claim-registry.py --check contentUse a probe only when the named test actually exercises the claim. For a confirmed defect, point to the roadmap remediation anchor instead of inventing a probe.