The AUP contract can be observed through four distinct layers. They can move at different speeds:
| Layer | What it can establish |
|---|---|
Installed arc CLI/runtime | Commands that were actually run, local behavior, diagnostics |
| Current source checkout | Implementation semantics currently under development/review |
| Generated JSON/artifacts | What a chosen compatibility consumer expects at that point |
| Showcase source/README/static page | Examples and history, not proof of a current registered deployment |
This board’s command-bearing paths were exercised with arc 2.0.0-beta.25. Implementation-derived statements point to the current inspected source and should be rechecked when the installed runtime differs.
Check a target rather than assuming “latest”
arc --version
arc dsl validate .
arc blocklet check .
arc blocklet run .Record the version, source/artifact form, registered page/route, target renderer, and observed result. A physical Showcase page file does not by itself prove that a route is registered or that a remote deployment is current.
JSON-first and DSL-first are both supported source arrangements. A DSL-first project may expose JSON virtually or materialize it for a particular consumer. A passing build on a newer runtime must not be used to declare compatibility with an older runtime or an untested device renderer.
When a new behavior is discovered, preserve its target version and evidence before turning it into a public reference claim.