One decision, from design question to the next session.

The five steps

1. Ask the design question

   A laptop is offline when a #builds alert lands. What should it see when it reconnects, and for how long?

   The person

   Faces a question the project’s architecture notes still listed as unresolved. The agent compares the model’s current answer with the code.

   Continuum

   Supplies the answer in force. The model said deliveries were retained until acknowledged. The code expired them after 24 hours and still counted them as delivered.

   The next person

   Works from a recorded mismatch with exact wording, not someone’s memory of how replay works.

2. Model the answer

   The agent writes the rule as a requirement and links it to the service that must satisfy it. The change compiles against the pinned model before anyone reviews it.

   The person

   Decides the behaviour: a bounded window, after which a delivery expires and is reported as expired.

   Continuum

   Produces a change file against the current model state, then a new compiled state that every later session can name.

   The next person

   Can ask the model which service owns the rule and read the requirement in one sentence.

   ADL · architecture/model/hash-relay.adlexcerpt

   requirement BoundedOfflineRetention {
     desc "A delivery queued for an offline endpoint is replayable for a
           bounded replay window set per deployment. When the window elapses
           the delivery becomes expired, whether or not the endpoint ever
           reconnects. … Expired is a terminal outcome that is reported as
           such and is never counted as delivered."
   }
   
   service DeliveryService {
     satisfies: …, HashtagDelivery.BoundedOfflineRetention
   }

   Where ADL and BDL each contribute

   ADL describes the system. The replay rule is ADL because a specific service, DeliveryService, has to enforce it. Notice that the model states that the window is bounded. The 24-hour default is a deployment setting recorded in the decision.

   BDL describes the business, independent of any system. In HashRelay it holds commitments like this obligation, and questions still open, such as whether uninstalling the agent should also remove the device at the server:

   BDL · architecture/business/hash-relay.bdlexcerpt

   obligation ForgetDeviceOnUninstall [internal-commitment] {
     activatedBy DesktopAgentRemoved
     statement "When a subscriber removes the agent, the device credential
       and any decision grant on that computer are removed and the grant
       is revoked …"
   }
   unspecified UninstallServerDisposition {
     question "When the agent is uninstalled, is the endpoint also removed
       at the server, or does it stay listed (offline) …?"
     accountable "Product owner"
   }

3. Review the decision

   The agent proposes ADR-001 with its rationale, the alternatives it rejected and the risk. A different person accepts it.

   The person

   The project owner reads the proposal and accepts it. The record requires that the approver is not the author.

   Continuum

   Keeps a signed decision record and checks the decision against the model: 2 expectations missing before the change, both satisfied after it.

   The next person

   Sees what is in force, why, and which alternatives were already rejected, so the decision isn’t reopened by accident.

   Decision record · ADR-001 checkscontinuum-cli 0.26.0

   Before the model change
   Alignment: change-required — 0 hold, 2 missing from the model
     exists BoundedOfflineRetention: missing
     DeliveryService satisfies BoundedOfflineRetention: missing
   
   Accepted by the project owner · option bounded-replay-window
   
   After the model change
   Alignment: aligned — all expectations hold
     exists BoundedOfflineRetention: satisfied
     DeliveryService satisfies BoundedOfflineRetention: satisfied

   Condensed from architecture/decisions/DECISIONS.md, events e3–e6. “Alignment” compares the decision with the model only. The record states that no source code is read.

4. Build and test against it

   The agent writes two regression tests first, one on each side of the boundary, then fixes the code.

   The person

   Reviews the code change, which comes with tests at 23 hours and 25 hours.

   Continuum

   Records the test results as implementation evidence, labelled reported, not verified by Continuum. The compiler still warns that the model declares no test that verifies the requirement.

   The next person

   Knows which tests protect the boundary, and that this link is reported in the decision record, not declared in the model.

5. Pick it up in a fresh session

   Six days later, an agent in a new session drafted macOS and Linux support. It began from the exact model state ADR-001 produced and kept the replay rule unchanged.

   The person

   Asks for a new capability. They don’t re-explain how offline replay works.

   Continuum

   Pins the proposal to its base state and marks it as a proposal: not approved, not adopted.

   The next person

   Reviews only what the proposal adds, knowing the replay behaviour is unchanged.

   2026-11-11-m2-desktop-portability.adl-changeexcerpt

   // A PROPOSAL: authored 2026-11-11 by an agent …
   // not approved, not adopted, no decision accepted.
   // What it deliberately does NOT claim: no new protocol message …
   // ack and replay stay as CatchUpWithoutInterruption /
   // BoundedOfflineRetention state them …
   
   base package Avlon.HashRelay state "sha256:a89061e4…f7f"  // the state ADR-001 produced