Acceptance Standard
A journey is accepted only when the public reader can follow it without private translation.
QUADPublic Accountability
A journey is accepted only when the public reader can follow it without private translation.
These paths are public acceptance targets. The owning subdomain still carries current route state.
Tooling can read the static journey standard at data/acceptance-journeys.json. The file is an acceptance register, not proof that a route is open or complete.
A real product path needs terminal states, not just green checks.
The owning surface shows the action, result, receipt, fee, and finality or delay label.
The route says no with a named reason and a next public check.
The route names what it waits for: payment, proof, finality, sibling state, review, or recovery.
A timeout, retry, reissue, refund, repair, or restore path produces its own receipt or status.
Boundary-crossing material is held for classification instead of being admitted as clean state.
Stale or partial evidence stays useful, but the public claim becomes smaller.
These can be useful evidence, but they are not enough to claim product readiness.
It proves one path was possible, not that failures, refunds, stale data, or support are ready.
It can guide development, but public readers need a public route or a clear local-only label.
It is not current telemetry unless the owning surface publishes freshness and current-state evidence.
Core, Infra, Bridge, and Liquid do not inherit each other's acceptance state.
A visible button does not mean the action is allowed, funded, live, or safe to attempt.
Useful for triage, but not a replacement for owner-surface receipts or status.