Contracts and evidence

Every present-tense product sentence needs a status. Without one, readers treat vision, history, and shipping behaviour as the same contract.

Status vocabulary

Status	Meaning	Allowed on public pages	Required evidence
Current contract	Behaviour you may design against for a named target runtime	Yes, as “supports / does / rejects”	Current source or types and tests or observed local run on the target version
Architecture	How layers fit; orientation only	Yes, clearly as explanation	Consistent with current structure; must not invent new public APIs
Experimental / gap	Incomplete, partial, or not E2E-verified	Yes, only if labelled as such	State what is missing or unproven; do not soften into a promise
Lineage	Why an older name still appears	Yes, with explicit non-promises	Product records, reference apps, or dependency facts—not feature parity
Unresolved	Needs a product or engineering decision	Prefer issue / review notes; short public caution only	Name the decision; do not invent a default

Evidence order (mandatory)

Current code, types, tests, and a local run prove “now supports.”
Merged PRs prove a change landed once. Re-check the current tree; later commits may have removed or narrowed it.
Planning docs, open issues, draft architecture notes, articles are archaeology. They may guide research; they do not establish a public contract alone.
When sources conflict, public docs state the current implementation, and the conflict goes to research-ledger.md or an issue comment—not into a marketing rewrite.

How to classify a sentence

Draft sentence	Correct status	Rewrite pattern
“`arc afs ls` lists a path”	Current contract	Keep only after running it on the documented CLI version
“AFS UI relates UI work to AFS paths”	Architecture	Keep as explanation; do not add “stable extension API”
“Instance DID lifecycle is complete for all remotes”	Experimental / gap (if unproven)	Say what is verified locally; mark remote lifecycle separately
“Discuss Kit was absorbed into ARC”	Lineage	State reference Blocklet / surfaces; deny full old-feature equivalence
“Third parties can ship any UI device”	Unresolved / not current	Do not publish as contract until code + E2E sample exist

What each board type should carry

Board type	Primary status mix
Architecture (this board)	Architecture + lineage; pointers to contracts
AFS / AUP / Web Device / Blocklets / Identity / CLI	Mostly current contract; mark experimental gaps explicitly
Product marketing pages	May use lineage language; never invent developer contracts

Version pinning

When a page includes commands or field-level behaviour:

Name the CLI or package version used for verification.
Show actual outputs or error shapes when the page teaches a command.
If your install differs, re-run before treating the page as authority.

This board’s orientation facts were checked with arc 2.0.0-beta.28 and ARC source 44fbd616f. Sibling boards may pin their own versions; prefer the stricter or more recent check for operational work.

Red lines that override status

Reader-visible text still follows site positioning constraints (product and technical claims only; no price or return promises; no banned marketing phrases; no claiming unimplemented features as shipped). Architecture status does not excuse a §1C overclaim.

Map and reading order: Overview
Old product names: Product lineage
Term index: Reference