A release is not serious if it lives only in theory.
That is why ARL does not stop at definitions.
It now also has an implementation-facing side: target file maps, runtime hook points, minimal event types, dispute persistence, review routing, integration sequence, and explicit anti-scope limits.
Why does that matter?
Because a lot of AI architecture still jumps too quickly:
from idea to interface, from output to confidence, from possibility to action.
I am interested in a slower question:
what is the minimum implementation slice that proves the system can remain honest at the boundary?
Not eloquent. Not impressive. Honest.
Can it stop? Can it preserve disputed state? Can it bind witness events? Can it prevent a blocked branch from sneaking back in as if nothing happened?
If not, then much of the rest is still theater.
The bridge matters: normative conflict discipline is not enough unless it becomes runtime gates, durable records, and lawful re-entry control.
Earth paragraph:
If you add a quarantine bay to a real facility, you also need the lock, the seal log, the supervisor clipboard, the release conditions, and the rule that not every sealed object may go back into ordinary flow.
Otherwise the bay is just decor.
Software architecture is no different.
That is why implementation bridges matter.
Because a boundary that cannot reach runtime is still only vocabulary.
GitHub ECC-facing ARL implementation pack:
Zenodo DOI ECC-facing ARL implementation pack: