@ybotok/loam 0.2.0-alpha.1 → 0.2.0-alpha.13

package/SCHEMA.md

@@ -62,6 +62,7 @@ docs/
   architecture/
     landscape.likec4                    global C4 (system landscape)
     subsystems.likec4                   one view per subsystem, views only    [GENERATED: loam subsystem sync]
+    services.likec4                     one overview view per service, views only [GENERATED: loam subsystem sync]
     permissions.yaml                    system-wide authorization vocabulary  [authored, opt-in]
     capabilities.yaml                   system-wide capability vocabulary     [authored, opt-in]
     obligations.yaml                    system-wide architectural obligations [authored, opt-in]
@@ -71,11 +72,13 @@ docs/
     spec.md                             narrative, then `## Requirements` — `Requirement-ID:` REQUIRED
   glossary/<term>.md                 the system's domain vocabulary, one file per term; nesting allowed [authored, opt-in]
   services/<svc>/                    at the root (unfiled), or inside subsystem directories at any depth
-    model.likec4                        boundary C4 (containers/components) [adopt]
+    model.likec4                        boundary C4 (containers/components); extends the map, or stands alone [adopt]
+    likec4.config.json                  one LikeC4 project per STANDALONE service model, create-only  [GENERATED: loam subsystem sync]
     spec.md                          living requirements (Requirement/Scenario)  [adopt]
     arch.spec.md                     living ARCHITECTURE requirements (outbox, retries, alerts; Covers:)  [authored]
     openapi.yaml                     API contract                        [adopt / authored]
     asyncapi.yaml                    async contract (AsyncAPI 3)         [adopt / authored]
+    usecases/<name>.likec4           optional flows INSIDE this boundary — dynamic views over its containers, graded when tagged #req- (any .likec4 beside model.likec4 is read the same way)  [authored, opt-in]
     adrs/NNNN-*.md                   MADR decisions                      [adopt-seed / authored]
     runbook.md                       operational runbook                 [adopt-draft / authored]
     health.yaml                      SLI/SLO, checks, critical deps       [authored]
@@ -86,24 +89,57 @@ docs/
     delta.likec4                     C4 delta (architecture)             [authored]
     specs/<svc>/spec.md              requirement delta (ADDED/MODIFIED/REMOVED + scenarios)  [authored]
     specs/<svc>/arch.spec.md         architectural requirement delta, same algebra  [authored]
-    specs/<svc>/openapi.yaml         the endpoints this feature adds     [authored]
-    specs/<svc>/asyncapi.yaml        the event-contract delta, slot-pinned  [authored]
+    specs/<svc>/openapi.yaml         only the endpoints it adds/changes/removes  [authored]
+    specs/<svc>/asyncapi.yaml        only the event slots it adds/changes/removes  [authored]
     capabilities/<cap>/spec.md       capability delta, same requirement grammar  [authored]
     glossary/<term>.md               a word this feature brings with it; create-only  [authored]
     usecases/<name>.likec4           a FLOW this feature brings; views-only, create-only  [authored]
-    adrs/NNNN-*.md                   feature-level decisions             [authored]
-    verification.yaml                the done-check: claims + verdicts + evidence, one attestation per service  [loam verify --service <id> --record]
+    adrs/NNNN-*.md                   feature-level decisions; they stay with the feature when it archives  [authored]
+    verification/<svc>.yaml          the done-check, one file per attesting service: claims + verdicts + evidence  [loam verify --service <id> --record]
+    verification.yaml                the same answered all at once, and every record from before the directory — read forever  [loam verify --record]
   features/archive/<FEAT>/           a shipped change — the same files, plus:
-    .loam-before/                    the bytes the merge overwrote        [written by loam]
+    .loam-before/                    the bytes the merge overwrote, each as files/<path>.before, and the checklist it shipped with  [written by loam]
   .loam-lock                         transient: one writer at a time      [archive/unarchive only]
   .loam-commit                       transient: the commit intent journal [archive/unarchive only]
 ```
 
 There is no `flows/` tree, and there will not be one. A cross-service **interaction flow** is a
 `dynamic view` under `architecture/` — the one place that already holds every cross-service edge —
-tagged with the capability it realizes. A flow that spans services does not belong under one
-service's directory, and the view's steps join to the landscape's own relationships, which is what
-makes the flow checkable rather than merely drawn.
+tagged with the capability it realizes, or with the suites it runs in (below). A flow that spans
+services does not belong under one service's directory, and the view's steps join to the
+landscape's own relationships, which is what makes the flow checkable rather than merely drawn.
+
+A flow that stays INSIDE one service — the hop sequence behind an arch.spec.md requirement whose
+`Covers:` names containers — cannot live under `architecture/`: loam parses that directory as its
+OWN document set — the map plus its siblings, and nothing under `services/` — so a step naming a
+container does not resolve there, and one such file takes the whole fleet map down
+(`landscape.invalid` plus one `spine.landscape-invalid` per service). That holds however the models
+are shaped: the renderer's root project may also hold every extending model and draw such a step
+perfectly, and loam still grades the map alone, because the map is the document every cross-service
+check reads. It lives beside
+the model instead: every `.likec4` under `services/<…>/<svc>/` other than model.likec4, plus any
+tagged `dynamic view` inside model.likec4 itself, is that service's own LikeC4 project — for an
+extending model, the map plus those documents; for a standalone one, the set
+`services/<svc>/likec4.config.json` registers for the renderer — and `loam validate --service <id>`
+(and `--all`, per service) reads exactly that set, whether or not the project file exists.
+`usecases/<name>.likec4` is the convention; `views.likec4` reads the same. Tag the view
+`#req-<Requirement-ID>` of a requirement in that service's spec.md or arch.spec.md. The tag has to
+be DECLARED somewhere the project can see: for a standalone model that is model.likec4's own
+`specification` — the one block that project has; for an extending model it is
+`architecture/landscape.likec4`'s block, or a tags-only `specification { tag req-… }` beside the
+`extend` (legal, and it lands the tag in the project's specification). Declaring it in BOTH is a
+duplicate, and the code depends on which document carries the second declaration — the finding
+lands where the file is, not at fleet altitude: `c4.invalid` (an ERROR, and the model's grading is
+suspended behind it) when the tags-only block is in model.likec4, `usecase.flow-invalid` when it is
+in a sibling. `c4.fleet-project-invalid` is the fleet-scope class one step out: TWO SERVICES each
+declaring the same tag locally, where no per-service project sees the collision.
+model.likec4 stays THE model:
+`c4.valid`, `Covers:` and every other model check read it alone, and a sibling that does not parse
+is one `usecase.flow-invalid` while the model keeps grading. Files loam does not read: a `.likec4`
+in a subsystem directory, in a feature directory outside `delta.likec4`/`usecases/`/`deployment/`,
+the generated `subsystems.likec4` and `services.likec4`, a sibling the service's own `likec4.config.json` `exclude`
+covers (it is in no project the renderer loads either), and every UNTAGGED `dynamic view`
+anywhere — a diagram, never a use case.
 
 A feature **brings** one the way it brings every other axis: `features/<FEAT>/usecases/<name>.likec4`
 is a views-only document that `loam archive` copies into `architecture/usecases/` and
@@ -112,6 +148,276 @@ would leave behind — so a flow may draw a hop into a service the feature's own
 and a hop into an element the merge does NOT land is refused at plan time rather than archived into
 a map the next reader's `loam validate --all` fails on.
 
+**A fleet flow can also say which SUITE it runs with: `#suite-<name>`.** A suite is a set of
+journeys a test run exercises together — a smoke suite, a payments suite — and a journey joins one
+by carrying the tag on its `dynamic view`, declared like every LikeC4 tag in the landscape's one
+`specification` block (`tag suite-smoke`), so a mistyped suite is a parse error rather than a second,
+empty suite. It is a SEPARATE prefix, not `#cap-`: a capability says what a flow is FOR, a suite says
+what it is RUN WITH, and membership is **many-to-many** — one view may carry several `#suite-` tags,
+and a suite holds as many views as carry its tag, which is why it is a tag and not a directory.
+
+**Tagging is the opt-in, and it grades.** A view carrying only `#suite-` tags — no `#cap-`, no
+`#req-` — IS a use case: every reader takes it (the predicate and the byte gate below now read three
+prefixes), and `loam validate --all` grades its hops like any other's (`usecase.step-unbacked`,
+`usecase.step-contested`, `usecase.step-unlinked`). A journey a test stand is provisioned from must
+be held to the model it is drawn over. The suite tag claims no capability and no requirement, so it
+earns nothing from the capability axis. An UNTAGGED view stays ungraded, exactly as before.
+
+`loam list suites [<name>] [--json]` is the answer the tag exists for: **which services must be up
+for suite X.** For each suite it lists the views carrying the tag, the enumerated services their
+steps resolve to — through the same element→service resolver the step grades use, so a step into
+one of order-service's containers counts order-service — and every participant that resolves to NO
+service, by element id, with whether it (or anything it is drawn inside) carries `#external`: the
+customer who drives the flow, a topic, a partner's API. The walk up stops at the first element
+bound to or titled for a service, as `loam gate`'s partner reading does, so a service drawn inside
+an `#external` grouping is still ours. Those are named and never dropped, because an environment
+list that is silently short comes up, and the journey then fails against something nobody was
+told to start. The payload is `suites[]` (`name`, `views[]` of `{id, file}`, `services[]`, `unresolved[]`
+of `{element, external}`), `ungrouped[]` — the use cases carrying no `#suite-` tag, which every
+per-suite line would otherwise leave out — and `useCases` (`state`: `absent` when the fleet
+declares no use case, `ok`, or `unreadable` with `error`, beside the `unreadable` boolean
+`list capabilities` spells). Over an unreadable `architecture/` the section degrades rather than
+refusing, and `suites` and `ungrouped` are ABSENT rather than `[]`. A `<name>` narrows `suites[]`
+only; an unknown one refuses `unknown-target` with the close names. The listing reads the FLEET
+map's use cases; a `#suite-` tag on a flow inside one service's own project is graded there like any
+other use-case tag, and is not listed — that flow runs inside one service, whose environment is the
+service itself.
+
+### Two shapes of a service model
+
+`services/<…>/<svc>/model.likec4` comes in two shapes, and **the file's own grammar decides which**
+— never a config key, never a flag. loam scans the bytes (comments and strings masked) for a
+top-level `specification { }` block containing an `element` declaration:
+
+- an **extending model** declares no element kind. It is parsed INSIDE the fleet's `architecture/`
+  project — the landscape plus every other `architecture/**/*.likec4` except the generated views
+  files (`subsystems.likec4`, `services.likec4`) — and says what is inside the service with `extend <fqn> { … }` on the element
+  the map already binds to the directory. `<fqn>` is the FULLY-QUALIFIED id: `extend orderService`
+  resolves to nothing when the element is `marketplace.orderService`. No `specification` is needed,
+  no partner is re-declared, and `model {}` or no model at all are both fine. `extend` accepts
+  `#tags` and a `metadata { }` block on the element it opens (merged into it — the map's `service`
+  binding survives) and REFUSES `description`, which belongs on the map's declaration. This is the
+  shape `loam adopt` briefs, and the shape `loam init --create` scaffolds a repository for.
+- a **standalone model** declares at least one `element <kind>` inside a `specification { }` block.
+  It is parsed ALONE, exactly as every model was before this shape existed; it may re-declare the
+  partners it names; and it renders only as a LikeC4 project of its own. Legal forever — a service
+  whose docs are reviewed from its own repository, a model adopted before the fleet had a map — and
+  not what a new model is written as.
+
+**Who declares kinds and tags.** In the extending shape, `architecture/landscape.likec4` is the one
+`specification` block: a kind a model needs and the map does not declare (`element database`,
+`element queue`) is added THERE, once, and a missing one is a single parse error on the model. A
+tags-only `specification { tag req-CANCEL }` beside an `extend` is legal and lands the tag in the
+project's specification — but a tag the map already declares, declared again there, is a duplicate
+blamed on both files. In the standalone shape the model declares everything it uses, which is
+exactly why its copies of the map's elements can drift.
+
+**Seven grades come with the pair**, and one existing grade is narrowed:
+
+| code | shape | what it says |
+|---|---|---|
+| `c4.declaration-diverged` (warn, service) | standalone | an element this model and the fleet map (`architecture/`) both declare, whose `kind`, `title`, tag SET or `metadata { service }` binding differ. The two are joined by id, then by the `metadata { service }` binding both wrote, then by the map element whose id ends with the model's as a dotted tail (`paymentService` ↔ `marketplace.paymentService`) — a tail two map elements answer to joins nothing, and a tail that is a BARE last segment (`db`, `api`) is a key only for a FLEET-LEVEL map element: one no ancestor of which stands for a service, so a top-level element or a box the map draws inside a plain grouping element, never an element drawn inside a service's own. `description` is deliberately not compared — it is prose, nothing grades it, and the other four each change what a view shows or what loam resolves. When the tag sets are all that differ and copying the map's declaration would not clear them — because the difference comes off `specification { element <kind> { … } }` on one side or the other — the message says so and names the document whose specification declares them, rather than asking for a copy. One finding per divergent element; silent while the map does not parse |
+| `c4.element-unowned` (warn, service) | extending | the model declares an element OUTSIDE the element that resolves to this service. Three remedies, first first: a store or component this service owns goes INSIDE the `extend <fqn> { }` block, where its id becomes `<fqn>.<name>`; a system the service reaches belongs in the map, declared once; another service's internals belong in that service's model |
+| `c4.fleet-project-invalid` (warn, landscape) | extending | `--all` only, and not while `landscape.excluded` holds — this load reads what the renderer reads and so has no floor under the map, and one `exclude` entry covering the map turns every extending model's `extend` into an unresolved reference (measured on `examples/docs`: 161 warnings from one line). loam loads the fleet project the way the renderer does — a walk of the docs root, minus everything the root `exclude` covers, minus the generated views files (`subsystems.likec4`, `services.likec4`), minus every STANDALONE service directory (`service.model-unexcluded` owns that state), minus `features/` (a delta carries its own `specification` and the directory is transient) — and reports each error NOT already present in the map alone or in any per-service project the same run made. A `.likec4` in a SUBSYSTEM directory, above every service, is in that set. This is the class no per-service grade can see: two services declaring the same tag locally, two models adding the same child id, a broken untagged sibling nobody opted in. All of them are renderer-fatal. `locations[0]` is the file the error is in and the message tail names the failure it actually is |
+| `service.likec4-config-stray` (warn, landscape) | extending | a `likec4.config.json` beside an extending model. The renderer registers it as a project of its own rooted at that directory, so the docs root stops being a one-project workspace (`likec4 validate .` then refuses without `--project`), and wherever that nested project claims the model it parses alone, out of the root project where the map's kinds are: the model does not resolve and `export json --project fleet` loses the service's containers (measured, likec4 1.59.2 — which of the two happens depends on the workspace; on `examples/docs` the fleet export was byte-identical with and without the file, on a seeded fleet the containers went). Run `loam subsystem sync`: it deletes the file. Deleting it by hand works too. loam never writes one beside an extending model |
+| `service.model-excluded` (warn, landscape) | extending | the root `likec4.config.json`'s `exclude` covers this model's directory, so the renderer never loads it and the service is a box with nothing inside it. An entry is read the way the renderer reads it (measured, likec4 1.59.2): a bare entry is a raw path PREFIX starting on a `/` boundary, so `services`, `services/`, `services/*`, `services/**`, `services/**/*`, a wildcard segment in the middle and the bare `services/pay` all cover `services/payment-service` — while the glob form `services/pay/**` wants the literal separator and covers nothing there. An entry shaped like a FILE rather than a directory (`services/**/model.likec4`, `**/model.likec4`) is reported too, with a different repair: `loam subsystem sync` maintains only the `services/` directory entries, so that shape has to be narrowed or deleted by hand. The finding quotes the entry verbatim, because the repair is to edit that line; `loam subsystem sync` is the repair for the directory shape |
+| `service.model-unexcluded` (warn, landscape) | standalone | the mirror, and the one that costs most: the root `exclude` does NOT cover a standalone model's directory, so the renderer merges it into the root project and reports every kind and element it declares as a duplicate — blanking the whole project, not just this service. An entry already covering the directory in any of the spellings above satisfies it, and `sync` appends no second glob for one. Same repair |
+| `service.likec4-config-missing` (warn, landscape) | standalone **only** | a standalone model with no project file beside it. It renders nowhere from the docs root until `loam subsystem sync` writes one. An extending model never earns this |
+| `landscape.excluded` (warn, landscape) | either | `--all` only. The root `likec4.config.json`'s `exclude` covers `architecture/landscape.likec4` itself — an `architecture/*.likec4` written for a palette is the spelling that does it. The renderer then loads NO fleet map: it draws nothing, and every extending model in the root project resolves against nothing. loam is unaffected — the architecture loader keeps the map whatever the list says — which is exactly why the state was invisible. `c4.fleet-project-invalid` is suspended behind it, on the cascade rule `permissions.invalid` states: that check reads the renderer's project, so the same entry would come back once per unresolved reference instead of once as the cause, and the message says the fleet project is not graded until the entry goes. The finding quotes the entry verbatim, and `loam subsystem sync` is NOT the repair: it maintains only the `services/` entries and leaves every other line as the team wrote it |
+
+`c4.invalid` and `c4.valid` are unchanged codes with adjusted scope: for an extending model every
+error the per-service project raises is THIS model's, including one the parser blames on the
+landscape, because the map parsed clean on its own; and `c4.valid`'s message reads
+`extends the fleet map — N elements · M relationships`, followed by ` · K tagged flow(s) graded`
+when the service's own project declared any (the one surface a healthy intra-service flow appears
+on). When the map itself does not parse, an
+extending model cannot be read at all: neither code is emitted, and `spine.landscape-invalid` says
+so with the clause ` — and model.likec4 extends it, so the model cannot be read either`.
+
+Every other model-dependent check reads the same slice it always read — the service's OWN elements
+and relationships. For an extending model that is what the project holds minus what the map alone
+holds, plus the **partners** its own edges point at and their ancestors, so `health.yaml`'s
+`kafka` still resolves when the only edge names `kafka.orderEvents`. Nothing reads the map's edges
+as the model's.
+
+**What loam grades is still the `architecture/` project alone.** The renderer's root project is
+WIDER than the fleet map: it also holds every extending model. loam's fleet checks — the spine, the
+bindings, the fleet-shape advisories, and the steps of every `architecture/usecases/` flow — read
+the landscape plus its `architecture/` siblings and nothing else, whatever shape the models take.
+So a cross-service flow names SERVICE elements: a hop naming a container an extending model
+declares renders perfectly and is `landscape.invalid` for loam. That is deliberate, and the reason
+is blast radius — a service's model is graded on its own merits, and one broken model must never
+blank the fleet's own map. A container-level flow has its own home beside the model that declares
+the container. The same holds for a feature's `features/<FEAT>/usecases/` flow, and the gate says
+so before the merge rather than after it: the preview stages no service model, and it ROUTES a
+nested addition into the model that owns that service's interior exactly as `loam archive` would.
+So a hop naming `<service-fqn>.<container>` resolves in neither the preview nor the tree the archive
+leaves, and `usecase.flow-invalid` refuses — where the un-routed preview resolved it, passed the
+gate `--approve` cannot override, and landed a flow the next `loam validate --all` failed on.
+
+**Which relationship a hop exercises.** A hop is backed by the relationships declared between its
+two endpoints, or — only when there are none — by those whose endpoints resolve to the same two
+services, so a hop between two services matches an edge drawn into one of their containers. A reply
+written `a <- b` is looked up under the call it answers. Nothing behind the hop is
+`usecase.step-unbacked` (error). Candidates that all name one operation attribute the hop to it.
+Candidates that name different operations — an edge with no `metadata { op }` counts as naming
+none, which differs from naming one — are `usecase.step-contested` (warn), unless **the step's
+title opens with a name one candidate declares**: its `op`, or the message it `publishes` or
+`consumes`, followed by the end of the title or by punctuation. Then the hop is attributed to that
+candidate:
+
+```
+model {
+  web -> payments 'Calls authorizePayment' { metadata { op 'authorizePayment' } }
+  web -> payments 'Calls refundPayment' { metadata { op 'refundPayment' } }
+}
+views {
+  dynamic view uc_refund {
+    #cap-payments
+    web -> payments 'authorizePayment — authorizes the payment'
+    web -> payments 'refundPayment(orderId)'
+    web -> payments 'takes the payment back'
+  }
+}
+```
+
+The first two hops are attributed and the third is contested. The rule is deliberately narrow,
+because a guessed operation reads exactly like a right one in every rollup built over a flow. The
+name must OPEN the title, matched exactly with case included. It must end there or at a character
+that cannot continue a name — anything but a letter, digit, `_`, `.` or `-` — so
+`authorizePaymentAsync` picks nothing. Any words after it must follow punctuation (`:`, `(`, `,`, a
+dash): as the first word of a sentence it is prose, so against a `read` edge `read: the order`
+picks and `read the order` does not, and neither does `reads the order before release` against a
+`release` edge. A relationship's own title is prose and picks nothing. The pick runs only among the
+candidates the endpoints found, and only when they disagree: a title never backs an unbacked hop,
+never reaches the service tier when the exact one answered, and never overrules candidates that
+agree. A pick that still disagrees — one name declared as one edge's `op` and another's `publishes`
+— leaves the hop contested over every candidate. A hop picked by a message is an event hop, which
+`usecase.step-unlinked` exempts. `loam diff --base` and the contract-removal gate read the same
+attribution, so a picked hop is a victim of the removal of its own operation and of no other.
+
+It is the title because nothing else on a step can carry the choice, as measured at the LikeC4
+1.59.2 pin. `metadata` and tags on a step are parse errors. A step's kind exists only as
+`-[kind]->`; it needs a declared `relationship` kind, and it names a transport, so a caller's
+reserve, read and release calls to one provider are one kind. And drawing the hop between elements
+that each carry exactly one candidate works only where the graded project declares those elements —
+a service's own flow over its containers, or a map that draws a service's containers itself. It is
+closed on a fleet flow whose two services are single elements on the map, because a container an
+extending model declares does not resolve there (above). A sequence diagram labels a message with
+the operation it invokes anyway.
+
+**Private stores.** **Where a store is drawn is the team's choice.** A store one service owns may be
+nested UNDER that service's element — written in the service's `extend <fqn> { store = database … }`
+block, or inside the service's element on the map when the map draws that service's containers — or
+drawn beside the services as an element of its own. Both are first-class and loam grades neither as
+wrong. Until 2026-09-07 the second earned `landscape.datastore-private` at one consumer, a warning
+whose whole message prescribed deleting the peer while the identical store nested was silent: it
+graded the drawing rather than the architecture, and it is retired. Infrastructure is not a service
+either — an element whose kind is `database`, `queue`, `topic`, `cache` or `bucket` is out of the
+service census, so an owned store drawn at fleet level is not `landscape.service-undocumented`, is
+not a `loam gate` partner, and mints no `service.exists` verification claim. The `extend` placement
+needs an EXTENDING model: a model that declares its own `specification` is parsed alone, so
+`extend <fqn>` resolves nothing there, and for such a service the map is the only nesting site (or
+migrate the model — see "Two shapes of a service model" above).
+
+What the choice DOES decide is one thing, and it is a fact about LikeC4 rather than a preference: **a
+second consumer's edge resolves only against a declaration the MAP holds**, because a per-service
+project is `architecture/` plus one model. Draw a container-level edge to `<owner-fqn>.<store>` in
+another service's model while the store lives in the owner's `extend` block and that model is
+`c4.invalid` ("Could not resolve reference to Referenceable named '<store>'"). So a store a second
+consumer will name has to be on the map — nested inside the owner's element there, or beside the
+services. That was always the load-bearing half; the prescription around it was not.
+
+Nesting closes no door in the other direction: loam counts a
+consumer a service's EXTENDING model attests exactly as it counts one the map draws, so a nested
+store two services reach is `landscape.datastore-shared` — the store's owner plus every service
+whose model draws a call at it or below it, outbound or, since a store never initiates, inbound
+from it (*Which way an edge points*). The second consumer draws that call as a
+container-level edge to `<owner-fqn>.<store>` in its OWN model, and the service-level twin on the
+map as usual. The two placements give the store the same id,
+`<owner-fqn>.<store>`, so moving the declaration OUT of the owner's `extend` block into the owner's
+element on the map rewrites no edge and no `Covers:` line — measured on `examples/docs`, where
+moving `db` out of order-service's `extend` block into `orderService` on the map left the model at
+12 elements · 8 relationships, left `Covers: marketplace.orderService.db` in its `arch.spec.md`
+resolving, and left checkout-web's container-level edge to it resolving. The move BACK is free only
+while no other service names the store: with checkout-web's edge drawn, putting `db` back into
+order-service's `extend` block is `c4.invalid` on checkout-web's model ("Could not resolve
+reference to Referenceable named 'db'"), or `landscape.invalid` plus one `spine.landscape-invalid`
+per service when that second edge is drawn on the map. `landscape.datastore-shared` needs a second
+consumer to fire, so it always prints in the state where map→extend breaks, and its message says
+so. It is the one datastore grade left, it fires at two consumers for both placements alike, and it
+states a coupling rather than prescribing a move: shared means the same DATA, and if two services
+only share a host or a cluster the honest model is one private store each. The consumer census is
+fleet-scope: it reads
+EXTENDING models only, because their ids are the map's fully-qualified ids and the join is exact,
+while a standalone model's ids are its own file's and are never matched to a landscape element.
+
+**Renderer consequences.** The root project holds the map **and** every extending model, so one
+`npx likec4 start` at the docs root draws the fleet and the inside of every adopted service, and
+the project picker holds one entry. A standalone model is the exception, and it costs two files:
+ONE entry in the root `likec4.config.json`'s `exclude` covering its directory (its kinds would be
+duplicates of the map's inside one project), plus its own `likec4.config.json`, which is what makes
+it a project of its own.
+`loam subsystem sync` maintains both halves — it writes the per-service file for standalone models
+only, and rewrites the root `exclude` so that it holds `services/<tree>/**` for exactly the models
+that stand alone. The rewrite removes the wholesale `services/**` and every `services/<tree>/**`
+naming a directory that IS a service, keeps every other entry in the order the team wrote it (a
+`services/legacy/**` for a directory that is no service survives untouched), and appends the
+standalone entries sorted. It runs when at least one extending model exists, or when a standalone
+model's directory is not covered — so a repository whose models all stand alone behind `services/**`
+is never touched, and a fresh scaffold that gains its first standalone model earns the entry on the
+next sync. `--json` reports it as `projects.exclude`, with what was added and removed; the text view
+prints one line when it rewrote. An entry covers a directory when it names that directory —
+`<dir>`, `<dir>/`, `<dir>/*`, `<dir>/**` and `<dir>/**/*` all do, and a wildcard segment in the
+middle (`services/*/legacy`) matches one level — or when it is a raw path prefix of it from a `/`
+boundary, which is what the renderer measures: `services/pay` covers `services/payment-service`,
+while `services/pay/**` covers nothing there. An entry is normalised the way the renderer
+normalises it before anything is matched: a leading `./`, an inner `/./` and an inner `//` are
+resolved away, a TRAILING `/` is not (bare `architecture` also hides `architecture-old/`,
+`architecture/` does not), `.//` leaves a literal `.` directory and hides nothing, and a BACKSLASH
+is a literal character to the matcher, never a separator — `services\order-service\**` hides
+nothing at all, so loam neither grades on it nor rewrites it. Measured at the 1.59.2 pin against
+`npx likec4 validate .` file counts; the table is in `src/core/c4/root-project/exclude.ts` and
+pinned in `test/root-exclude.test.ts`. A directory the list already covers in
+any of those spellings earns no second entry. `projects.exclude` carries `updated`, `entries`,
+`added`, `removed` and `unreadable` — the last is `true` when the root file exists and loam could
+not read an `exclude` list out of it, which is never the same answer as `entries: []`, and the list
+is then reported untouched. Beside it, `--json` carries
+`projects.created` (the per-service project files written) and `projects.removed` (POSIX paths
+relative to the DOCS ROOT, deleted this run, sorted by path; `[]` otherwise) — and
+`projects.created` is spelled the same way. Both are relative to the docs root, not to the
+repository root, which differ whenever `docsDir` is a subdirectory. A fresh repository is
+scaffolded with
+`exclude: ["**/node_modules/**", "features/**"]`.
+
+**Migrating a standalone model to the extending shape** is a documented recipe an agent performs;
+loam does not rewrite a model, because the comments in a real one are somebody's and not loam's to
+reflow. In order:
+
+1. Write into `architecture/landscape.likec4` any element kind the model uses that the map does not
+   declare (`element database`, `element queue`), and any element the model reaches that the map
+   does not draw — an external system, a broker's topic — as the fleet's own declaration.
+2. Delete the model's `specification` block.
+3. Delete every element the map declares: the service's own element, and every re-declared partner.
+4. Wrap what is left in `model { extend <fqn> { … } }`, `<fqn>` being the fully-qualified id of the
+   map's element for this service. Child ids inside the block stay relative; internal edges may be
+   written inside it.
+5. Move the cross-boundary edges outside the `extend` block and spell both endpoints in full —
+   `marketplace.orderService.outbox -> kafka.orderEvents`.
+6. Requalify every id that names one of those elements from outside the file: the `Covers:` lines in
+   `arch.spec.md`, the `of <element>` and `include` lines of any `views` block, and the hops of any
+   `#req-`-tagged flow beside the model. There is no suffix matching anywhere — `orderService.db`
+   does not answer for `marketplace.orderService.db` — so every model-local nested id has to be
+   rewritten. `health.yaml`'s `dependencies:` are the one place that usually needs no edit, because
+   a dependency resolves when an element of the own slice answers to it **by id, `metadata { service }`
+   binding or title**, and the slice holds the service's own elements plus every endpoint of the
+   model's own edges and each endpoint's ANCESTORS: `kafka` still answers through an edge naming
+   `kafka.orderEvents`, and a peer service still answers through the binding on the map's element.
+   Prefer the service id or a top-level system id there — those two spellings resolve under either
+   model shape, and a model-local nested id does not.
+7. Delete `services/<…>/<svc>/likec4.config.json`.
+8. Run `loam subsystem sync` (it rewrites the root `exclude`), then `loam validate --all`.
+
 ## Subsystems — a navigable tree under `services/`
 
 `services/` may be one flat level (the compatibility case, and forever legal) or an unbounded tree
@@ -134,6 +440,13 @@ A directory under `services/` is classified **three ways, never two**:
    subsystem's marker while another moves a service in, and the group directory would otherwise be
    read as one empty service. The fleet is never reported smaller than it is.
 
+A directory named for one of the service's own subdirectories (`adrs/`, `usecases/`, `ui/`) is
+service interior wherever it sits: the walk never reads one as a service or a subsystem, and never
+counts one as the subdirectory that makes its parent a group. Writing the documented
+`services/<id>/usecases/<name>.likec4` slot into a directory that holds no artifact FILE yet used
+to make the walk read `usecases` as a service and its parent as an unmarked group — three errors
+earned by following the instruction `loam init` had just scaffolded.
+
 `subsystem.yaml` is a **marker, not a manifest**:
 
 ```yaml
@@ -154,7 +467,9 @@ claimant). Subsystem names take the service-id grammar (`subsystem.name-invalid`
 is unbounded and is the author's problem, not the tool's. A service directly under `services/` is
 **unfiled** — permanent, normal, and never a finding; `loam list` carries the count
 (`unfiledServices`, plus `services[].subsystem` and `subsystems[]`), and an empty subsystem is
-legal, since `loam subsystem new` must be usable before anything moves in.
+legal, since `loam subsystem new` must be usable before anything moves in. A service `loam archive`
+creates lands unfiled too: the archive takes no placement input but the tree itself, never the map's
+nesting ("How archive writes, and how unarchive undoes it" has the decision).
 
 The tree is mirrored into **one generated file, never into the authored landscape**:
 `architecture/subsystems.likec4` holds LikeC4 **views only** — no model, no tags, no `specification`
@@ -164,21 +479,263 @@ check uses; a member nothing models is omitted, which `landscape.service-unmodel
 reports). The output is deterministic and line-oriented — subsystems sorted by path, members by id,
 one `include` per line, no timestamps, no absolute paths — so it is byte-reproducible on any machine
 and two concurrent moves into different groups merge in git without intervention.
+
+**Styling.** Each generated view carries `global style subsystems` — after its `title` and
+`description`, before its `include`/`group` — exactly when the `architecture/` project declares a
+global style with that id: `global { styleGroup subsystems { style element.tag = #external { color gray } } }`
+(or the single-rule `global { style subsystems … }`), in the landscape or in ANY `.likec4` under
+`architecture/` the root `likec4.config.json`'s `exclude` does not cover — a `palette.likec4` beside
+the map works, and one under an excluded path is loaded by neither the renderer nor loam.
+`architecture/landscape.likec4` is the one exception: loam keeps the map in that set however the
+list is written, because an architecture project with no documents in it reads as a fleet that
+models nothing. With the targeted tag declared in the `specification` block.
+Declaring it is the whole opt-in. loam reads only that the id is declared, never what the group
+says, and writes nothing when it is not — a reference to an undeclared style is a parse error that
+blanks the whole `architecture/` project in the renderer. When the project declares style groups
+under other names only, the file opens with one comment line naming them and saying none is
+`subsystems`, and the views carry the renderer's defaults; there is no single-group fallback.
+Both halves restale the file once (`subsystem.views-stale`) until the next `loam subsystem sync`:
+declaring or removing the group named `subsystems` changes whether the views carry the
+`global style subsystems` line, and declaring or removing a group under ANY OTHER name changes the
+disclosure comment that lists what is available. Whether a service's own views can borrow that group depends on the shape of
+its model: a model that EXTENDS the map is in the root project, so a `global styleGroup` declared
+under `architecture/` reaches the views beside it and referencing the id there is legal; a model
+that STANDS ALONE is a project of its own, and a group declared under `architecture/` does not reach
+it — those views need a declaration of their own, or the reference is the parse error that blanks
+that project.
+
+Each view carries the **label a human reads**: `title`, and `description` when the marker authors
+one. The title is the subsystem's **path** — every marked ancestor's label and its own, joined with
+` / `, so `services/platform/order-flow` reads `Platform / Order flow` — and each label is the
+marker's `title`, falling back to the directory name (an unlabelled view is shown by its id, which
+is hex-escaped for injectivity and reads as `subsystem_platform__order_2dflow`). LikeC4
+reads that path as folders: the view list mirrors the directory tree, showing one folder per
+ancestor and the leaf's own label as the title. A `/` **inside** a label becomes `∕` (U+2215), so an
+authored slash can neither hide half of what somebody wrote nor invent a folder level the tree does
+not have. Both strings are somebody's prose written into syntax, so both are normalized to one line
+and escaped. Titles are not unique — only ids are — and renaming a parent's title rewrites every
+view beneath it.
+
+The **boundary** each view draws is a fact about the landscape, never a setting:
+
+1. an element that holds *exactly* the subsystem's members and nothing else is included beside the
+   leaves, so the renderer nests them in the box the author drew, under the author's title;
+2. a landscape that nests nothing puts the services in a `group '<title>'` of loam's own, mirroring
+   the directory subtree, so a parent subsystem shows its children as boxes rather than one pile;
+3. members that ARE nested with no element owning exactly them get no box and one comment line —
+   `// model: no boundary — <id> also holds services outside this subsystem.` — because a synthetic
+   box would look identical whether or not the tree and the map agree. That comment is the whole of
+   what loam says about the two disagreeing: nothing grades it, nothing fails on it, and it lands in
+   the diff of the commit that caused it. **The tree and any `group` nesting in the landscape stay
+   independent**; `loam subsystem move` never rewrites the map, and no finding compares them.
+
+Because the boundary depends on which *other* services sit under an element, an unrelated adoption
+or archive can flip a view from boxed to flat — a new reason to see `subsystem.views-stale`, and why
+`loam archive` withholds its "complete + current" line and names `loam subsystem sync` when it left
+the file behind.
+
 `loam subsystem sync` is the one regenerator (it also *removes* the file when the tree has no
 subsystems), every `loam subsystem` write verb regenerates it inside the same transaction, and
-`validate --all` grades staleness by **byte comparison** — exactly one error,
-`subsystem.views-stale`, on exactly that file; nothing in loam ever parses it: a views-only document
-does not parse standalone (its `include` lines reference elements the landscape defines), and it
-holds **static** views, whose contents loam never reads in any document. Only the LikeC4 renderer,
-which merges the whole `architecture/` project, resolves its includes.
+`validate --all` grades staleness by **content comparison** (line endings normalized; a CRLF
+checkout changes no fact) — one error,
+`subsystem.views-stale`, per stale generated file, each naming its own path (there are two of them;
+`architecture/services.likec4` is below); nothing in loam ever parses either: a views-only document
+does not parse standalone (its `include` lines reference elements the landscape defines), and both
+hold **static** views, whose contents loam never reads in any document. Only the LikeC4 renderer,
+which merges the whole `architecture/` project, resolves their includes.
+
+`sync` refuses to rewrite this file while the `architecture/` project cannot be read. The render
+needs the map's elements and its global-style census, and a tolerant "no elements" answer wrote a
+file holding title and description alone — the `global style subsystems` line, every `include` and
+the boundary comment gone — while reporting `updated … 1 subsystem view(s)` and answering `current`
+ever after. So: a load error falls back to the landscape FILE when that parses on its own (a
+duplicate `subsystems` group declared in two `architecture/` documents costs nothing), and when
+that fails too the facts are UNKNOWN. With an existing views file, `sync` then writes nothing about
+it, prints why, and reports the `--json` action `blocked`, with `blocked.reason` reading
+`landscape-invalid` — exit 0, because `loam validate --all`'s `landscape.invalid` is the gating
+surface. With no file yet, and inside a tree-changing verb's commit window (`new`/`move`/`rm`/
+`rename`, whose contract is that the file lands with the change), the tolerant shape is written as
+before and the same note is printed.
+
+### `architecture/services.likec4` — one overview view per service
+
+The **second generated views file**, written by the same `loam subsystem sync`, in the same commit,
+removed by it when the map draws no service, and graded by the same `subsystem.views-stale` on its
+own path. Views only, one per service the fleet map draws, sorted by service directory id:
+
+```
+view service_payment_2dservice of marketplace.paymentService {
+  title 'Payments / payment-service'
+  global style services
+  include *
+  include kafka.orderEvents
+  include marketplace.checkoutWeb
+  include stripe
+  exclude * -> *
+  include -> marketplace.paymentService
+  include marketplace.paymentService ->
+  include marketplace.paymentService.* -> marketplace.paymentService.*
+}
+```
+
+**Why the peers are named one by one, measured at the 1.59.2 pin on a 120-service and a 58-service
+fleet.** The obvious recipe — `include <fqn> -> *` and `include * -> <fqn>` — is wrong at fleet
+scale and looks perfect on a small flat fixture, which is how it would have shipped. LikeC4 draws a
+counterpart at the highest ancestor that is not also an ancestor of the subject, so on a map that
+GROUPS its services (which is exactly what a 100-service fleet needs at fleet level) every peer
+collapses to its group box: the naive view of one service in the 120-service fleet drew six group
+boxes and **0 of its 10 nodes had drill-down**. loam already reads elements and relationships, so it
+names each peer itself — the far endpoint of every edge touching the service or anything inside it,
+spelled as the map declares it, so an edge at a topic names the topic and not the broker, which is
+the truer picture and the one the map already draws. `exclude * -> *` then drops the peer-to-peer
+cross traffic (23 edges down to 7 on the same fixture), and the three lines after it put back
+exactly the subject's own: the UNARY `include -> <fqn>` / `include <fqn> ->`, never the binary
+wildcard, which re-introduces the parent group boxes as extra nodes (16 instead of 10). `include
+<fqn>.* -> <fqn>.*` is the interior wiring, and it is legal on a childless element — it simply
+matches nothing — which is what makes one line work for both model shapes: an extending model's
+containers are in the root project and appear, a standalone model's are not and the line is silent.
+
+Measured at 58 services in 11 groups: a median of **10 nodes and 8 edges** per generated view, every
+peer that is a service carrying drill-down into its own generated view, and `npx likec4 export json`
+— which layouts every view — costing about **7 ms per generated view** (1.3 s with 120 of them
+against 451 ms without). `likec4 start` layouts on demand, so a reader pays for the one view they
+open, and the generated views are all small BY CONSTRUCTION; the expensive view is the hand-authored
+fleet one, and it is unaffected.
+
+**Drill-down is the `of`, and it costs one keyword.** `view <id> of <element-fqn>` names the view's
+subject, and LikeC4 then computes `navigateTo` on that element's node in **every other view that
+draws it** — no authored links anywhere. So one generated view per service makes the fleet map,
+every subsystem view and every other service view click-through into the service. The subsystem
+views take the same keyword when the map holds an element owning exactly that subsystem's members,
+which closes the mesh — `fleet → payments → payments/service-22 → identity/service-45 → identity`,
+every hop generated, none authored.
+
+**Two views of one element are legal, and the FIRST DOCUMENT ALPHABETICALLY wins** the default
+navigation target — measured by renaming the files, LikeC4's load order being alphabetical by path.
+Both stay reachable: inside a view of the subject, the subject's own node navigates to the OTHER
+view of the same element, so the renderer cycles between siblings and nothing is orphaned.
+`architecture/landscape.likec4` sorts before `architecture/services.likec4`, so a team's authored
+`view of <element>` written in the map keeps precedence over the generated one, and neither is lost.
+loam does not detect this and never will: **docs/DESIGN.md rule 26 forbids loam reading what a view
+SHOWS**, in any document, so it may not look at an authored `view of` to decide whether to emit. It
+emits for every service the map draws, and the alphabet settles the rest.
+
+**The first line is the deed, and every writer checks it.** Both generated views files open with a
+`// generated by loam` mark, and that mark is what makes the path loam's rather than the team's.
+These are the only two filenames loam RESERVES inside `architecture/`, a directory that is otherwise
+entirely authored, so a repository that already had a file at one of those paths must not lose it to
+an upgrade — the archive's promise that authored bytes stay authored holds here too. Every writer of
+these paths reads the first line first: `loam subsystem sync` reports that one file `refused`,
+writes nothing for it, still does the rest of its work, and exits 1; `loam subsystem new`, `rm`,
+`move` and `rename` and `loam seed` refuse the WHOLE operation with `already-exists`, writing,
+renaming and staging nothing, because their commit window exists precisely to land the generated
+file in the same commit as the change to the tree — completing half of that would manufacture the
+`subsystem.views-stale` state the window exists never to leave behind. The consequence to know: a
+file with no mark is never regenerated, and an EMPTY file carries no mark either, so a truncated one
+must be deleted by hand before sync will write it again. loam's own staging is atomic and cannot
+produce one.
+
+**Titles are folders, because there is nothing else.** LikeC4 has **no view-folder syntax** —
+`views { group 'X' { … } }` is a parse error at the pinned version and the AST carries no view-group
+type at all. What it has is the title: a view title is split on `/` into browser folders and only
+the last segment is shown. So a per-service view is titled `<subsystem path> / <service directory
+id>`, built from the same path helper the subsystem views use, and the two generated files fold into
+ONE folder tree mirroring `services/`. An unfiled service is its own id at the root. The service
+**directory id** is used rather than the map element's title: it is the name every loam command
+addresses the service by, it cannot drift from the map, and a directory id cannot contain `/`. A
+`dynamic view` you author under `services/<…>/<id>/usecases/` lands in the same folder when you
+title it `'<subsystem path> / <service id> / <use case>'` — a convention loam states and never
+grades.
+
+**Which services appear.** Exactly those the element→service join resolves, the same join the
+subsystem views use. A service the map does not draw is omitted — its absence is already
+`landscape.service-unmodelled`, and rendering only what the committed map resolves is what keeps the
+output a function of committed bytes. **View ids** are `service_` plus the same hex escaping the
+subsystem view ids use, so the two generated files cannot collide with each other, and an authored
+view claiming one is `subsystem.view-id-collision` — which names the file and the reserved prefix. A
+`service_` id is reserved only for a service the map actually draws. **Style**: `global style
+services`, presence-detected off the parsed map's declared style ids exactly as `subsystems` is, and
+written only when a group of that name is declared — a reference to an undeclared group is a parse
+error that blanks the whole project.
+
+### The per-service LikeC4 project file
+
+A different artifact from the two generated views files above, and the tree's other renderer
+concern: `services/<…>/<svc>/likec4.config.json`,
+which `loam subsystem sync` also writes, beside every **standalone** `model.likec4` that has none.
+An extending model needs no such file and never gets one: it belongs to the root project, which is
+where it parses, and a project file beside it is `service.likec4-config-stray` — which `sync`
+DELETES, in the same journaled commit as everything else it writes. A standalone model
+needs one because it cannot share a project with the map — it declares its own kinds, and inside
+one project every declaration is a duplicate blamed on the map too — so `sync` also keeps the root
+`exclude` covering exactly the directories of the models that stand alone. Before extending models
+existed, `services/**` was excluded wholesale and every model needed the file; what that exclusion
+cost went unstated for a release: an
+adopted service was a box on the fleet map with nothing renderable inside it. Measured at the
+pinned likec4, a project file INSIDE a service directory is registered as a project of its own
+regardless of the exclusion, so a docs root holding standalone models loads `fleet` plus one
+project per such service, each carrying LikeC4's own `index` view of the containers beside the
+authored one, and a model that does not parse breaks only its own project. (An extending model
+is inside `fleet`, so a model that does not parse breaks the root project instead — the trade the
+shape makes, and `c4.fleet-project-invalid` is what names it before a reader meets it in the
+renderer.) The file is **create-only for a standalone model** —
+never compared, never rewritten — under the root config's ownership rule, not the
+views file's: there is no `-stale` grade because nothing can make it stale. It is removed in
+exactly one state, and only there: beside a model that EXTENDS the map. That nested project claims
+the model out of the root project — the workspace loads two projects, the model is Invalid inside
+its own one (the map's kinds are not in there with it) and `export json --project fleet` then loses
+the service's containers. Which of the two the workspace does was measured both ways at the 1.59.2
+pin: on a seeded fleet whose model extends a top-level id the containers went; on `examples/docs`
+the root project kept the model and the export was byte-identical. What is true in every state is
+the second project itself — `likec4 validate .` at the docs root refuses without `--project` from
+the moment that file exists. So it is not a harmless leftover, and `loam subsystem sync` deletes
+it. One beside a model that is GONE stays: that one really is the team's — though the same second
+project it registers is there too, so `likec4 validate .` and `likec4 build` at the docs root need
+`--project` while it stands (ROADMAP's "Known and carried, 2026-09-04"). Its bytes are a
+function of the id alone (two keys, `name` and `title`), so placement never changes them and a
+`subsystem move` carries the file with no write of its own — it rides inside the rename the move's
+transaction already journals (in a git-backed repo, commit the files `sync` wrote first: `move`
+refuses over untracked paths, `move-uncommitted`); a compare would only fight the keys LikeC4 lets a
+team add (`title`, styles). `name` is the id with every
+`.` folded to `-` (LikeC4's name grammar refuses the byte; loam's id grammar admits it), prefixed
+`service-` when the result would equal the root project's `fleet` (a nested project of that name
+is silently registered as `fleet-1`) or LikeC4's reserved `default`; `title` is the id verbatim,
+and the title is what the renderer's project picker shows. The name is **not injective**, and
+that is disclosed rather than escaped away: an id spelled billing.core beside a service literally
+named billing-core, or `service-fleet` beside `fleet`, share a name and LikeC4 suffixes the later
+one `-1`; no loam
+finding grades it, because the picker still reads the id. Order is a gate — the root file first
+(`loam init --create` writes it, `loam doctor` prints it), then `sync`: without the root file
+nothing is written and the text output says so. No model, no file: a spec-only service is owed
+nothing and gets its file on the first `sync` after its model lands. No legal id, no file either: a
+directory whose name breaks the service-id grammar (`service.id-invalid`) would get a `name` the
+renderer silently drops, and a create-only file the renderer ignores would silence the grade for
+good, so `sync` skips it and the rename that clears `service.id-invalid` earns the file.
+`validate --all` grades presence only — one warning per service with
+a STANDALONE model and no file, `service.likec4-config-missing`, on the fleet `landscape` target,
+never an error, never in `--service`, `status` or `doctor`; the fix is `loam subsystem sync`, never
+a hand-written file. Its two siblings grade the extending shape's version of the same question —
+`service.likec4-config-stray` for a project file that should not be there, `service.model-excluded`
+for a root `exclude` entry that hides the model from the renderer — and `sync` is the repair for
+both: it removes the stray and rewrites the entry. A third reads the same list and is nobody's to
+rewrite: `landscape.excluded` says an entry covers `architecture/landscape.likec4` itself, so the
+renderer loads no map at all — `sync` maintains only the `services/` entries and will not touch that
+line, and the finding quotes it so its author can. It also suspends
+`c4.fleet-project-invalid` for that run, because the renderer's project is exactly what the entry
+broke and grading it would report the one line once per extending model. A
+feature's `delta.likec4` is deliberately out of scope: the directory is transient and
+`loam archive` moves it where a project file would still be registered, so every shipped feature
+would keep a dead project in the list forever.
 
 A move is **one journaled transaction over N directory renames plus the regenerated views file**
 (`loam subsystem move <name>... --into <sub|.>`; `rename` is a one-rename move; whole subtrees move
-as one rename). It refuses only when git reports uncommitted changes under a directory being moved
-(`move-uncommitted` — where git will not say, it proceeds), and after landing it stages the renames
-and the views file in git without committing. Archive snapshots survive any of this: a version-3
-snapshot re-keys `services/` entries by `(service, artifact)` and restores wherever the service
-lives *today*.
+as one rename), **plus every relative markdown link the renames would break** — out of the moved
+documents and into them, rewritten in the same commit (Conventions, above, has the rule). It
+refuses only when git reports uncommitted changes under a directory being moved, or in a document
+outside it that the move would relink (`move-uncommitted` — where git will not say, it proceeds),
+and after landing it stages the renames, the relinked documents and the views file in git without
+committing. Archive snapshots survive any of this: a keyed (version 3 or 4) snapshot re-keys
+`services/` entries by `(service, artifact)` and restores wherever the service lives *today*.
 
 ## Canonical joins
 
@@ -193,6 +750,7 @@ lives *today*.
 | Capability | requirement `Capability:` (list; also `Capabilities:`) | `architecture/capabilities.yaml` OR `capabilities/<cap>/spec.md` | declared capability id, `/` allowed for nesting |
 | Capability requirement | requirement `Realizes:` (list) | a requirement in `capabilities/<cap>/spec.md` | `<capability-id>#<Requirement-ID>`, split at the LAST `#`, with an optional `@<digest>` pin |
 | Capability requirement (flow) | a `dynamic view` tag `#req-<slug>` | a requirement of the capability the view's `#cap-` tag names | the `Requirement-ID` with every character outside `[A-Za-z0-9_-]` flattened to `-` |
+| Service requirement (flow) | a `dynamic view` tag `#req-<slug>` in a `.likec4` beside model.likec4, or inside it | a requirement of the service whose directory holds the file, from either spec axis | the `Requirement-ID` flattened as above |
 
 These keys are independent: an operation id is not a permission and a service id is not inferred
 from a feature directory. A file can therefore be structurally valid while a join is broken; the
@@ -202,6 +760,71 @@ The last two exist only inside an `archive`/`unarchive` commit window and are re
 belong in the docs repo's `.gitignore`. Finding one at rest means a write did not finish:
 `loam doctor` grades it, and the next `archive`/`unarchive` repairs or refuses.
 
+### Which way an edge points
+
+LikeC4 accepts an arrow in either direction, and some of loam's readers draw meaning from it. This
+section lists every reader and the drawing each one expects. A reader not listed here ignores
+direction.
+
+| Reader | Expects | Drawn the other way round |
+|---|---|---|
+| The HTTP spine, `metadata { op }` | caller `->` provider: the `op` resolves against the TARGET's `openapi.yaml` | graded against the wrong service: `spine.op-undefined` there |
+| The event spine, `metadata { publishes }` | producer `->` topic: `publishes` binds the edge's SOURCE | when the source is infrastructure and the target is a service, the key binds nothing: `spine.message-unbound` (warn) on the target |
+| The event spine, `metadata { consumes }` | topic `->` consumer: `consumes` binds the edge's TARGET | when the target is infrastructure and the source is a service, the key binds nothing: `spine.message-unbound` (warn) on the source |
+| The consumer census behind `landscape.datastore-shared` and `landscape.platform-candidate` | a service at the SOURCE of an edge into the element, or an outbound call in the service's extending model | for infrastructure, either direction counts; for any other element the arrow is read, so a system calling INTO the fleet is not consumed by the services it calls |
+| Review order (`loam list --review-order`) | a plain edge is a call, so its source depends on its target; a `consumes` edge is a delivery, so its target depends on its source | the dependency is counted backwards |
+| Use-case hops (`dynamic view`) | each hop backed by a relationship drawn the same way | `usecase.step-unbacked`; a reply hop is written `<target> <- <source>` and is looked up under the call it answers |
+| `Covers:` edge entries | `a -> b` names the edges from `a` to `b` | `covers.unknown` |
+
+**Infrastructure** here is an element whose kind, or an ancestor's, is one of `database`, `queue`,
+`topic`, `cache` or `bucket`, and which stands for no service: a table nested in a `database` is
+part of it. These are the kinds that exempt an owned store from `landscape.service-undocumented`,
+and the limitation is the same: the hook is a kind NAME, so a kind spelled `postgres`, or a broker
+drawn as a plain `softwareSystem`, is not infrastructure. Infrastructure never initiates and never
+decides: a store, a topic or a bucket neither calls nor publishes nor consumes. Both rules below
+follow from that one fact.
+
+**THE ARROW FOLLOWS THE MESSAGE on the event spine**, producer to topic and topic to consumer. A
+key bound to a topic is therefore on the wrong end of its edge, because a topic is what sits
+between a producer and a consumer and is never either of them. Through 0.2.0-alpha.10 such a key
+was skipped without a word: the document validated, the metadata parsed, and the spine graded one
+link fewer. `spine.message-unbound` now says so, at service scope (the living map) and at feature
+scope (a delta's tagged edges), and it spells the edge turned round. When the edge carries both
+keys, turning it round would only move the warning to the other key, so the message says to put
+the key at fault on an edge of its own.
+
+loam reports the reversed edge and does not quietly bind it to the other end. Review order and
+use-case hops read the same arrow, and re-binding the spine alone would make it agree with a
+drawing those readers still take the opposite way. An `#external` system at the bound end is not
+this case. `crm -> billingService` carrying `publishes` says that an outside party produces the
+message, which `spine.message-unproduced` accepts and `spine.message-external` grades, and a
+`consumes` on an outside system says that an outside party consumes it. Both drawings are correct
+and stay silent. So does an edge with no fleet service at either end, such as an `#external`
+producer publishing to the broker. A key bound to a service is graded against that service's
+contract, so a wrong drawing there already surfaces as `spine.message-undefined`.
+
+**For the census, infrastructure's direction carries no meaning.** Fleets draw a read as a call
+(`service -> store`) or as the data's flow (`store -> service`), and both are common. The census
+counted only the first, so a second consumer drawn as data flow vanished, and so did the
+`landscape.datastore-shared` it should have caused. The event doctrine above draws every consumer
+as `topic -> service`, so no broker's consumers were ever counted toward
+`landscape.platform-candidate`. Both directions now count, from the map's edges and from an
+extending model's attested calls alike.
+
+**A relationship's KIND is drawing, never a join.** No reader in the table above reads a kind:
+`metadata { op }`, `publishes` and `consumes` are what every grade joins on, and `-[calls]->`
+changes what the renderer draws and nothing loam decides. The convention loam teaches is in
+`loam instructions loam-drawing`: one kind per kind of traffic — `publishes` from producer to topic,
+`delivers` from topic to consumer, `reads`, `writes` and `readsWrites` with a store edge always
+written service `->` store and the kind's style placing the arrowhead, `calls` for a request, and
+`connects` wherever no evidence gives a direction yet. The fleet map `loam init --create`
+scaffolds and the one `loam seed` templates both declare those seven kinds, and declare them only:
+seed's edges stay plain, because `fleet.yaml` says who calls whom and nothing about what an edge
+carries. One consequence is mechanical rather than a convention. `loam archive` splices a delta's
+edge into the map verbatim and never copies a `specification` declaration, so a kind the living
+map does not declare leaves the merged map unparseable and the archive refuses with
+`merge-failed`. Declare a kind in the map before a feature that draws one archives.
+
 ## `loam.json` — the wiring, one file per repository
 
 The docs repo is one repository; each governed implementation boundary is represented by a code
@@ -242,7 +865,10 @@ so running loam from a subdirectory works; `loam init` writes the file where it
   this repo, digests that document and compares it with the committed
   `services/<id>/openapi.yaml`: `openapi.generated-stale` (warn) when they differ,
   `contracts.source-missing` (error) when nothing is there, `contracts.source-invalid` (error) when
-  the path escapes the repository or the file does not parse.
+  the path escapes the repository or the file does not parse. The stale warning's `details` name
+  the operationIds that differ (served but not in the committed copy, committed but no longer
+  served), and its message says when the two sets agree, so a reworded description no longer reads
+  the same as twenty vanished endpoints.
 
   **loam reads it and never writes it.** The copy into the docs repo stays a human `cp` reviewed in
   a pull request — that is what keeps the committed contract a document somebody agreed to rather
@@ -404,10 +1030,119 @@ the target is unchanged, only the route to it — which is what lets an author w
 resolves where they wrote it, in the pull request that reviews it, and keeps it resolving after it
 ships. This applies to the service and capability spec merges alike, and predates the glossary: a
 delta requirement citing an ADR always had it. A link inside a fenced block or a code span, an
-absolute URL, a site-root path and a bare `#section` are left exactly as written.
+absolute URL, a site-root path and a bare `#section` are left exactly as written, and so is a link
+whose text still reaches its target from where it lands.
+
+**A link into the feature itself follows the file to where the archive puts it.** The same archive
+that moves a requirement two directories up moves the rest of the feature too, so the rule for
+writing a link is one sentence — write the link that resolves where you write it — and archive owns
+the rest:
+
+- a file the archive COPIES into the living tree is cited at its living copy: a term the feature
+  introduces (`features/<FEAT>/glossary/<term>.md` → `glossary/<term>.md`), a flow
+  (`architecture/usecases/`), a topology document (`architecture/`);
+- every other file under the feature — its ADRs above all, its intent, its deltas — is cited where
+  the archived feature keeps it, `features/archive/<FEAT>/…`.
+
+So `[Order](../../glossary/order.md)` written in `features/<FEAT>/specs/<svc>/spec.md` (the
+feature's own term) and `[Order](../../../../glossary/order.md)` (the term's future living path,
+which `link.unresolved` already treats as resolved while the feature is in flight) land as the same
+link. **A feature ADR is never copied into the living tree**: it records a decision taken for that
+change, it is part of the change's history exactly as the deltas are, and the living documents that
+cite it point into `features/archive/<FEAT>/adrs/`. A decision meant to govern beyond the change
+belongs in `architecture/adrs/` or the service's own `adrs/`, written there in the same pull
+request. A term the archive copies gets the same treatment as the requirements: its own relative
+links are re-expressed for `glossary/`, two directories up from where it was written — the one
+change to an otherwise byte-for-byte copy.
+
+**The documents that stay in the feature keep links that resolve from `features/archive/<FEAT>/`.**
+The archive is a directory rename, and every markdown document it carries — the intent, the
+feature's ADRs, its deltas, the archived copy of a term, any other `.md` under the feature — was
+written one directory shallower than where it now sits: `../../services/x/spec.md` in
+`features/<FEAT>/intent.md` would name `features/services/x/spec.md` from the archive. So the archive
+re-expresses their links for the move, in the same commit, under the rename's own rule: a target
+inside the feature moves with it, so a link from the intent to its own ADR or its own term is left
+exactly as written (the archived record keeps citing the archived copy it was reviewed against, not a
+living one that goes on changing), and every other target stays put, so only the routes the rename
+broke change. The plan lists each one as an `update` before the `move`, and the text output says
+`feature documents: N relinked for features/archive/<FEAT>/`; the snapshot parks each pre-image like
+any other write, so `loam unarchive` puts the authored bytes back and archive-then-unarchive stays a
+byte-for-byte round trip — and, like any file the archive wrote, one edited under
+`features/archive/<FEAT>/` since is a later change `unarchive` will not discard without `--force`
+(`snapshot-stale`). A document that is not UTF-8 is left as written, and the text output says so. The
+links are true **as of the archive**, and that is the whole promise: archived features stay out of
+`link.unresolved` and out of `subsystem move`'s rewrite, because a later rename is a later commit and
+the archive is history — what the archive owes is not to break them itself.
+
+**A document outside the feature that links into it keeps a link that resolves.** The same rename
+takes `features/<FEAT>/` away from under every document that cites something in it — another change
+in flight that builds on this one's decision (`../<FEAT>/adrs/0001-x.md` from its intent), a living
+ADR citing the decision taken for a change still open — and no edit made in advance could have
+helped, because the archived path does not exist until the archive does. So the archive rewrites the
+links INTO the feature from every other authored document — the fleet's own documents, every
+service's, every other in-flight feature's: the corpus `subsystem move` rewrites for its renames —
+in the same commit, under the rule for a link into the feature above: a file the archive copies into
+the living tree is cited at its living copy, everything else where the archived feature keeps it.
+These documents are the living corpus and the other changes in flight, not the record of this one, so
+they follow a term to its living copy where the feature's own documents keep citing the archived one.
+Every other link keeps its spelling, and a living document the merge also rewrites is relinked from
+its merged text, as one write. The plan lists each as an `update` before the `move`, and the text
+output says `links into the feature: N document(s) relinked for features/archive/<FEAT>/`. The costs
+are the ones `subsystem move` names, said the archive's way: a `verified` `spec.md` or `arch.spec.md`
+the relink moves off its `content_digest` joins `revouchOwed`, exactly like one the merge moves, and
+a living requirement whose route it rewrote moves the digest a feature in flight may pin with
+`Based-On:` (`delta.baseline-stale` until `loam rebase` — a `note:` line in the text output). There
+is no `move-uncommitted` refusal: archive does not stage in git, and its undo is the snapshot, where
+each relinked document is an ordinary row. `loam unarchive` puts the authored bytes back, and a
+document edited since — another feature's intent included — is a later change it will not discard
+without `--force` (`snapshot-stale`). A document whose own feature has been archived or removed since
+is neither: `unarchive` leaves it as it is and says so (`left:` in the text output; `--json` has no
+key for it), because putting it back would recreate a one-file `features/<other>/` that every reader
+lists as a change in flight — beside the archived one, or in place of the one somebody abandoned.
+
+**`loam subsystem move` and `rename` keep the same promise.** A move is a directory rename and a
+relative link is a route between directories, so the move rewrites every relative link it would
+break, in the same transaction as the renames: the links out of every markdown document under a
+moved directory, and the links into a moved directory from every other authored document (the
+fleet's own documents, every service's, every in-flight feature's — archived features are history
+and are left as they are). A link whose text still reaches its target from the new place — a
+sibling moving with its document — keeps its exact spelling. Each rewritten document is listed in
+the text output (`relinked <path>`) and in `--json` as `relinked`, staged in git with the renames,
+and asked the same uncommitted-work question: a document OUTSIDE the moved directories that the
+move would relink, and that git reports as uncommitted or untracked, refuses the move with
+`move-uncommitted` exactly as a dirty file under a moved directory does. A rewritten route is
+still a changed byte, and the move says what that costs rather than leaving it to the next gate: a
+`verified` document it relinks no longer hashes to its `content_digest` (`content.stale` until
+its owner re-vouches — the archive merge's `revouchOwed` in another form), and a living
+requirement it relinks moves the digest a feature in flight may pin with `Based-On:`
+(`delta.baseline-stale` until `loam rebase`). Both arrive as `warnings` (`note:` lines in
+text); neither is softened, because the alternative was a link that resolves to nothing.
+
+**When archive CREATES a living document, it carries what the delta marked as the document's own —
+and nothing else.** "loam merges requirements, never prose" is not an aversion to prose: a delta's
+prose is about the CHANGE — the scaffold's own title is `<svc> — requirement delta for <FEAT>` — and
+a living document that kept it would describe a pull request that merged months ago. A machine
+cannot tell narrative about the service from narrative about the change, so a new
+`services/<svc>/spec.md`, `arch.spec.md` or `capabilities/<cap>/spec.md` gets:
+
+- the delta's frontmatter **`owner`** (service specs; a capability document carries no frontmatter)
+  — the one field that describes the service rather than the change or a vouch;
+- the delta's **H1**, unless it is about the change — it names the feature, or calls itself a
+  delta — in which case the title is the id (`<svc> — architecture` for an `arch.spec.md`);
+- the delta's **`## Purpose`** section, verbatim, with its links re-expressed like the
+  requirements' — the explicit marker, and the one OpenSpec's living specs already use;
+- one sentence linking back to the archived delta — "Created when FEAT-1 was archived; its delta
+  keeps the prose written for that change", with "its delta" the link — so nothing the merge left
+  behind is unreachable.
+
+The plan prints one note per created document saying which of these it carried and where the rest
+stays. Only on creation: a living document that already exists keeps its own narrative, edited in
+place, and a `## Purpose` in a delta against it merges as nothing — the plan says so on that file's
+line rather than letting it vanish.
 
 **Frontmatter**: `status`, `owner`, `service` or `feature`, `last_verified`, `vouched_by`, `sources`
-(literal files and directories), `sources_digest`, `content_digest`, `sources_files`, `vouch_scope`.
+(literal files and directories), `sources_digest`, `content_digest`, `sources_files`, `vouch_scope`,
+`adoption`.
 `loam validate` reads it in exactly three files — a service's living `spec.md`, its living
 `arch.spec.md` when present (same conventions, same checks, only the label differs), and a feature's
 `intent.md`: the documents whose identity and status everything else joins on. `adrs/` and
@@ -456,7 +1191,12 @@ two checked files:
   `--all` alike, from the docs repo included. A `verified` spec whose current body hash mismatches
   gets `content.stale` (**warning**, the `sources.stale` grading: the doc changed since it was
   vouched, and only a person can say whether verified still holds). A verified doc with no
-  `content_digest` predates the stamp and stays quiet — the fix is re-vouching.
+  `content_digest` predates the stamp and stays quiet — the fix is re-vouching. Every fleet readout
+  carries the same fact, because it is computable from the docs repo: `loam list` shows
+  `vouched (stale)` and owes the row `re-vouch` in `missing` (so `--needs-work` lists it), `loam
+  status` counts it under `services.contentStale` and emits `next.revouch` instead of
+  `next.fleet-clean`, and `validate --all`'s scorecard counts it under `provenance.contentStale`.
+  The rung stays `vouched` — a person did stamp the document — exactly as for `vouch_scope` below.
 - `vouch_scope` — written by `loam vouch --sample <n>`, never by hand, and present only when the
   person who vouched read a recorded SAMPLE of the document rather than all of it. One flat string,
   `sampled <k>/<n> seed=<16 hex>`: k sections read of n, and the seed that chose them. `status`
@@ -472,6 +1212,23 @@ two checked files:
   `loam list`, `loam show` and `loam status`, since the sample is per file. A later FULL
   `loam vouch` deletes the field, which is the only thing that clears the warning; deleting it by
   hand forges a full vouch out of a partial one, and the generated `AGENTS.md` says so.
+- `adoption: partial` — written by `loam archive`, never by hand, on a service's living `spec.md`
+  only, and only when the archive CREATES it for a service that existed before the feature (its
+  directory is enumerated) and that the feature's own `delta.likec4` does not introduce. What lands
+  then is that feature's slice — the requirements it added — and nothing about what the service
+  already did, so the document is not an adoption, and the decision is to say so where every
+  fleet readout looks rather than to refuse the archive: the plan prints why the file is marked,
+  the maturity ladder keeps the service at `partial` (a spec.md carrying the marker does not count
+  toward `documented`; `loam list`'s `missing` names `loam adopt --service <id>`, so the scorecard
+  and `--needs-work` see it too, and `loam gate --service <id>` refuses the deploy with
+  `gate.service-undocumented` exactly as it did before the archive), and `loam status` keeps
+  `next.adopt` for it — in place of `next.complete-service` — with a sentence that does not claim
+  the file is missing. A service the feature introduces is never marked — its slice
+  is all of it — and neither is a spec.md that already existed. `loam adopt` flags the file `PARTIAL`
+  and counts it as owed (`targets[]` carries `partial: true`), while its action stays `diff` — never
+  replace it: write the baseline from the code around the slice, then **delete the line**, which is
+  the only thing that clears it. Any value other than `partial` reads
+  as absent.
 - Missing fields are warnings, and `loam list` reports the fleet's draft/verified/unmarked split.
 
 **Vouching** (`loam vouch --service <id>`, run in the service's own repo) is the human promotion
@@ -615,7 +1372,21 @@ There is no manifest of services: the directories under `services/` **are** the
   why the two are graded differently;
 - two elements resolving to the **same** `services/<svc>/` → `landscape.binding-duplicate`
   (**warning**): every element→service join picks one of them arbitrarily, so the other's edges are
-  quietly filed under a service that does not own them.
+  quietly filed under a service that does not own them;
+- an element resolving to a `services/<svc>/` that no edge in the map touches, while that service's
+  `model.likec4` parses and declares at least one call across its own boundary →
+  `landscape.service-isolated` (**warning**, never gating): the service is drawn and invisible to
+  every cross-service check, and the finding names the attested calls to draw as edges on the
+  existing element, collapsed to the service. Evidence-gated on purpose — a service with no model,
+  an unparseable one (`c4.invalid`), or a model reaching nothing is silent here, because an edgeless
+  element that is TRUE is a fact and an invented edge is a dependency the fleet then plans against;
+  the adopt brief's `landscape.touched` is the only place that silent state is named. And BINARY:
+  one edge closes it, so a map drawing one of five attested calls is silent too — the check is
+  touched/untouched, never a set difference over the attested calls, because loam cannot tell a
+  call the map forgot from one the fleet deliberately does not draw at its own altitude. "Edge in
+  the map" means an edge in the `architecture/` PROJECT — the landscape plus every other `.likec4`
+  under it, minus the generated views files (`subsystems.likec4`, `services.likec4`) — and `loam adopt` reads the same set. An
+  `#external` element is never the subject, whatever directory it is bound to.
 
 **`architecture/landscape.likec4` is required, not optional.** Its absence is a finding, never a
 skipped check: an **error** as soon as `services/` holds at least one service directory, and a
@@ -626,7 +1397,7 @@ it cannot be silence: with no map, the whole cross-service layer — the C4↔AP
 `landscape.service-unmodelled`, every derived view — computes nothing and *reports* nothing, which
 reads exactly like a clean fleet. `loam init` scaffolds the file (empty, commented, parsing clean)
 so a fresh docs repo starts from a real one rather than from that ambiguity, and `loam adopt` briefs
-the block each service still owes it.
+the write each service still owes it — the block, or the edges on an element no edge touches.
 
 Absences inside a service directory are graded too. A directory with no `spec.md` is a **warning**
 (`service.no-spec`) — partial adoption is a supported state, but the checks that file feeds are
@@ -649,7 +1420,11 @@ A missing `openapi.yaml` is graded on what already points into it, under one cod
 And `loam validate --service <id>` for a directory that does not exist at all is an **error**
 (`service.unknown`) that suggests close ids — never `loam adopt`, which would steer an agent into
 adopting the typo. Only a legal id earns that grading: a name that is neither an existing directory
-nor a legal service id is refused as `invalid-option` before any path is built from it. A
+nor a legal service id is refused as `invalid-option` before any path is built from it. A service
+an active feature introduces is not a typo: its only documents are that feature's `specs/<svc>/`
+until it archives, so the same error names the feature and `loam validate --feature <FEAT>` instead
+of a near-miss, and a bare `loam validate` in a repository bound to that service validates the
+introducing features in its place (`--json` says so in `boundService`). A
 `features/<FEAT>/specs/<svc>/` directory addressing a service that neither exists as
 `services/<svc>/` nor is introduced by that feature's own tagged `delta.likec4` is the same class of
 mistake and gets its own **error**, `delta.service-unknown`, naming close ids: archiving would
@@ -717,9 +1492,64 @@ under any flag — `x-loam-remove` and `x-loam-based-on` are stripped at path le
 level alike, on every merge branch. A path item consisting of nothing but a marker publishes no
 phantom path. The same feature must carry a `REMOVED` requirement whose `Operations:` line names
 that id. Coherence gates an absent path+method, an id mismatch, an unjustified marker, a removed
-requirement with no marker, and a new tagged C4 edge consuming the operation being removed.
+requirement with no marker, a new tagged C4 edge consuming the operation being removed, and a
+removal anything would still consume after the merge (`openapi.remove-op-consumed`, error,
+`--approve` overrides — **Who still consumes it** below says what counts). A `REMOVED`
+requirement owes a marker only while there is a living operation for it to retire: not for an id
+the service's living contract does not define (a consumer's `REMOVED` requirement naming another
+service's operation), and not for one this delta already replaces at its address (the overwrite
+below — no marker could be written there, since the replacement holds the slot). A living
+contract that does not parse proves neither exemption, so the marker stays owed.
 `serviceOperationIds` evaluates the feature as living upserts minus removals, so other same-feature
-checks see the post-archive contract. Archive deletes only the matching method, reports removals in
+checks see the post-archive contract.
+
+**An overwrite can remove an operation too, and is graded as one.** The merge writes per method and
+path, so a delta defining ANOTHER operationId where a living operation lives replaces it there — and
+when the contract the merge would write then defines the living one nowhere, it has left the
+contract with no marker for any of the checks above to read. Coherence asks the removal's own
+consumer question of it, on the merged contract: `openapi.remove-op-consumed` (error, `--approve`
+overrides, exactly as for a marker) while anything would still consume it after the merge. With no
+marker there is no `REMOVED` requirement either, so the provider's own requirement naming the old id
+stays unless the feature `MODIFIES` it to name the new operation or `REMOVES` it — and a `REMOVED`
+one owes no marker here. A new tagged edge onto the replaced operation is `c4-api.op-removing`. The
+fix is the delta's choice: define the replaced operation at another address in the same delta if it
+is to stay; for a rename, redraw the living edge and restate the governing requirement. An
+overwrite of an operation nothing names stays the advisory `api.op-unconsumed` it always was.
+
+**Who still consumes it — one answer for the gate, `loam diff` and `loam archive`.** The consumers
+of an operation are read once, the same way for every reader (`core/consumers/`):
+
+- every edge of the `architecture/` **project** whose `metadata { op }` names it and whose target
+  resolves to the provider — any document the spine grades, never `landscape.likec4` alone (when
+  only a sibling document fails to parse, the map file's own edges still count);
+- another service's requirement — in `spec.md` **or** `arch.spec.md` — whose `Operations:` line
+  names it, **unless that service's own contract defines the same id** — then the line names that
+  service's own operation: `validate` resolves a spec.md `Operations:` line against its own
+  service's contract, and `loam dependencies` reads a line in either file naming an operation its
+  own service provides as no dependency on anybody (an unreadable or absent contract proves no
+  ownership, and the line counts);
+- the use-case hops the model attributes to it (a contested hop is a doubt, never a consumer);
+- the provider's OWN documents still naming it — its `spec.md` requirements, and edges it draws to
+  itself. Not its `arch.spec.md` lines: `validate` grades an `Operations:` line in spec.md only, so
+  one in arch.spec.md strands nothing (another service's does count — it is a dependency on this
+  contract, as `loam dependencies` reads it). The gate counts these, because the merge strands them as surely; `loam diff` and the archive's
+  `openapi.op-modified` warnings answer who ELSE is affected, and leave them out (a service owes no
+  operationId to itself).
+
+The gate reads all of it **after the feature's merge**: a requirement the same feature `MODIFIES`
+to drop the id, or `REMOVES`, no longer counts — another service's too, so retiring the consumer in
+the same feature is a fix the gate sees — and one of its own `ADDED`/`MODIFIED` requirements naming
+the id does. A delta the merge would refuse to apply fails closed: the living requirements count,
+plus every one the delta adds or modifies. Edges and hops are read as they stand: the landscape
+merge only ADDS edges and a feature's flows are create-only, so no feature document can take one
+away — drop or redraw a living edge by editing the living map in the same change. The refusal lists
+the consumers in its `details[]`, in the order `loam diff` lists the victims of the same removal.
+A consumer document nobody could read refuses too, and is named there: a spec file that does not
+decode (another service's, or the provider's own), or a service id two directories claim — the gate
+cannot prove such a document does not name what is leaving, so it says it could not check, never
+that the fleet still consumes it. An edge drawn with no `metadata { op }` and a contested use-case
+hop are doubts about a drawing: `loam diff` lists them, and they never refuse, since `loam seed`
+draws every edge without an op. Archive deletes only the matching method, reports removals in
 text and `openapiRemovals` JSON, never copies the marker into living OpenAPI, and deliberately does
 not garbage-collect components. A removal marker in a living `openapi.yaml` is
 `openapi.remove-marker-living` (error). The usual staged-write rollback and `unarchive` snapshot
@@ -731,9 +1561,11 @@ A `paymentService -> kafka 'Publishes PaymentAuthorized'` edge used to read as f
 while naming no contract anybody could check. The event axis is the API axis's mirror, in **AsyncAPI
 3.0** — only 3.0, because its operations are named top-level objects carrying
 `action: send|receive`, the exact analog of an `operationId`, where 2.x spells the same thing as
-`publish`/`subscribe` under a channel and leaves whose perspective they take ambiguous. A 2.x
-document declares no `operations` and reads as a contract with no messages rather than as a
-mis-parsed one. Like OpenAPI it is read with a shallow structural walk over the `yaml` parse, never
+`publish`/`subscribe` under a channel and leaves whose perspective they take ambiguous. A document
+whose `asyncapi:` field says 1.x or 2.x is refused as one `asyncapi.invalid` naming the version, and
+nothing on the event axis is graded against it: reading it as a 3.0 contract with no messages used
+to turn every edge and requirement into a misleading `spine.message-undefined`. The AsyncAPI CLI's
+`asyncapi convert --target-version=3.0.0` upgrades it. Like OpenAPI it is read with a shallow structural walk over the `yaml` parse, never
 a real AsyncAPI parser: the slice loam joins on is small enough that the parser's model would be
 dead weight, and adding it would be a fourth runtime dependency.
 
@@ -796,9 +1628,14 @@ the edges point at channels it is the channels that collect three consumers each
 broker leaves a row of untagged hubs behind it.
 
 **The feature lifecycle, mirrored from the OpenAPI axis.** A feature changes this contract through
-`features/<FEAT>/specs/<svc>/asyncapi.yaml` — a **complete AsyncAPI 3.0 document**, exactly as an
-openapi delta is a complete document: the author restates the living contract around the part they
-are changing, and the machinery tells restatement from edit. Identity is the **slot** — the pair
+`features/<FEAT>/specs/<svc>/asyncapi.yaml` — a self-contained AsyncAPI 3.0 document holding **only
+the slots the feature adds, changes or removes**, exactly as an openapi delta holds only its own
+operations: the merge walks only the slots the delta declares, so a slot it leaves out stays as the
+living contract has it, and an edited slot is written out whole. A slot restated without being
+changed is legal and the machinery tells it from an edit, but it buys nothing and costs a pin,
+which a parallel feature's removal turns into `asyncapi.baseline-invalid` and `asyncapi.slot-revived`
+— or, unpinned, into `asyncapi.slot-revived` alone, the contract axis's revival check (under *Living
+spec vs delta* below) on this axis's identity. Identity is the **slot** — the pair
 (section, key) over the three named sections `channels.<key>`, `operations.<key>` and
 `components.messages.<key>` — and the join token stays the message name. Three feature-only keys,
 spelled and shaped exactly as on the OpenAPI axis: `x-loam-based-on` inside a slot's value (written
@@ -850,11 +1687,50 @@ decision that reverses that stance: the removal family exists, a message-slot re
 justified by a `REMOVED` requirement's `Publishes:`/`Consumes:` line (channel and operation slots
 need exactness only — requirements join on message names and never on channel or operation keys, so
 demanding a justifying requirement there would invent a join the corpus cannot express), and
-`asyncapi.remove-message-consumed` gates a removal the living fleet still consumes. The lag argument
+`asyncapi.remove-message-consumed` gates a removal the fleet would still consume after the merge —
+a `consumes` edge of the `architecture/` project, another service's `Consumes:` line in either spec
+file (no ownership rule here: a consumer declares the message in its own contract as `receive` by
+construction), a use-case hop backed by such an edge — or whose provider's own `Publishes:` line the
+merge would leave behind, or its own `publishes` edge (the spine grades that edge on its source,
+`spine.message-undefined`; drop or redraw it in the living map), which covers a message slot re-keyed to another name or a send operation
+turned around as surely as a marker: read after the merge, as on the HTTP axis, and a `REMOVED`
+requirement owes no marker for a message the merge already takes out. **A consumer counts only
+while nothing would still send the message after the merge** — no service, and no `#external`
+element whose edge publishes it: the join is fleet-global, and a consumer with another producer is
+not stranded — `spine.message-unproduced` grades a consumer by exactly that, an outside producer
+included (*The direction is not decoration* above), and `loam diff` reports such a removal as
+`diff.message-removed`, "still sent by …", naming an outside producer as `<title> (#external)`.
+The senders are read after the merge too: a service this feature carries an event delta for sends
+what the merged contract would (the delta itself, where it creates the contract), and vouches for
+nothing where the merge cannot be simulated, so a feature retiring the message from every sender
+is still refused; an unreadable contract never vouches. The outside producer is read off the
+living `architecture/` project with validate's own rule, and only while that project parses. The
+landscape merge only adds to the map, so no feature takes its edge or tag away — but the rule also
+asks that no `services/<id>/` directory stand for the element, and the merge creates one from each
+`specs/<id>/` the feature carries. So the rule is asked over the directories as the merge leaves
+them: a feature that onboards the outside system as a service (`specs/legacy-gateway/`, its element
+titled or bound `legacy-gateway`, or a topic nested inside it) takes the producer away, and a
+retirement in it is refused unless something else still sends the message — the new service's own
+contract, in its `specs/legacy-gateway/` delta, for one. A `publishes` edge
+from an `#external` element that only the feature's own C4 delta draws does not count either —
+draw it in the living map, or archive with `--approve`. Another sender does not excuse the
+provider's own `Publishes:` lines and `publishes` edges — those are graded against its own
+contract, whoever else sends the message — nor its own unreadable spec files; another service's
+unreadable spec file, or an id two directories claim, refuses only while nothing would send. The lag argument
 survives as an **operational warning**, not a veto: passing the gate proves the *documents* agree
 nobody consumes the message — it does not prove no consumer is still reading the topic with lag, so
 sequence the runtime retirement accordingly.
 
+**The same senders answer the consumer this feature ADDS.** A delta `Consumes:` line or tagged
+`consumes` edge naming a message nothing would send after the merge is `spine.message-unproduced`
+at feature scope — the error the next `validate --all` would raise against the consumer, raised
+before the archive lands it. Here an `#external` publisher the feature's own delta draws DOES count:
+it is an addition, the one thing the landscape merge makes, and the map `validate --all` then reads
+carries it. The suspension is service scope's: any contract in the fleet that does not read leaves
+the question unanswered. When only another in-flight feature's delta sends the message, the finding
+softens to `spec-event.message-pending` (a requirement line) or `c4-event.message-pending` (an
+edge) — archive that feature first; archived ahead of it, the consumer is unproduced until it lands.
+
 **Payload-schema correctness stays out of scope, stated so the boundary reads as a decision rather
 than a gap.** loam never validates that a payload schema is correct JSON Schema, correct Avro, or
 correct anything: digests are content identity and every check joins on names. A fleet that wants
@@ -914,7 +1790,9 @@ the source for tests.
   diff, tagged to the feature.
 - **`loam archive <FEAT>`** merges the delta into the living state on three axes — **requirements**
   (`spec.md`, and `arch.spec.md` beside it: the two files ride one merge code path, parameterized by
-  filename), **API** (`openapi.yaml`), **architecture** (`landscape.likec4`) — then archives the
+  filename), **API** (`openapi.yaml`), **architecture** (`landscape.likec4`, plus the
+  `services/<…>/<svc>/model.likec4` of each service whose EXTENDING model owns an addition nested
+  inside it) — then archives the
   feature, so the living state stays complete. Archived deltas are the evolution history (like
   `git log`). `--dry-run` prints the whole plan and writes nothing.
 - **Coherence gate:** `loam validate --feature` checks the three axes agree (C4 edge `op` ↔ OpenAPI
@@ -933,7 +1811,11 @@ the source for tests.
   (`spec-api.op-pending` / `c4-api.op-pending`) naming that feature — archive it first — because the
   fix is ordering, not authoring.
 - **`loam unarchive <FEAT>`** takes an archive back: it restores the living docs and re-opens the
-  feature.
+  feature, and names any generated views file the restore left behind the tree (`staleViews`).
+- **A document the merge CREATES** — a new service's `spec.md` or `arch.spec.md`, a capability's
+  `spec.md` — carries what the delta marked as its own (frontmatter `owner`, a title that is not
+  the change's, the `## Purpose` section) and one line linking back to the archived delta;
+  Conventions, above, has the rule.
 - **The requirement baseline.** A MODIFIED requirement carries its full new text rather than a diff,
   so the merge REPLACES the living requirement instead of folding into it — and two features
   rewriting one requirement destroy the loser's text entirely. `loam validate` names the other
@@ -962,19 +1844,35 @@ the source for tests.
   never the resolution itself — a pin says "I read this version", so `loam rebase` reports every
   requirement that moved and says plainly that restamping without re-reading merges your text over
   theirs. There is deliberately no three-way merge: requirement prose does not merge.
-- **The same baseline on the contract axis, where it matters more.** A feature's `openapi.yaml` is a
-  **complete document, not a patch** — authors restate the living contract around the slot they
-  change — and the merge upserts every operation the document spells. The collision therefore needs
-  no overlap between the two features at all: two deltas over one service, editing *different*
-  operations, destroy each other, because whichever archives second pushes its authoring-time copy
-  of the operation it never meant to touch back over what landed in between. On a service with
-  thirty operations a delta quotes twenty-nine of them, and each is a candidate. So every operation
-  in a feature contract carries **`x-loam-based-on`** — the same 16-hex digest, in the
+- **The same baseline on the contract axis.** A feature's `openapi.yaml` is a **self-contained
+  document holding only what the feature adds, changes or removes** — not a copy of the living
+  contract. The merge walks only the paths and methods the delta spells: an operation it leaves out
+  stays exactly as the living contract has it, a local `$ref` (`#/components/schemas/Order`)
+  resolves into the living document, and a brand-new operation, path-level key or component has no
+  living version to pin, so an add-only delta never trips `openapi.baseline-missing` and needs no
+  `loam rebase` at all. What the merge does upsert is every operation the document *does* spell,
+  so an operation quoted without being changed — copied for context, or a whole contract pasted in
+  — is a collision waiting for somebody else's edit: two deltas over one service, each quoting the
+  operation the other edits, destroy each other, because whichever archives second pushes its
+  authoring-time copy back over what landed in between. A quote also costs something even pinned:
+  it is one more pin, and a pinned quote whose living operation a parallel feature removes is
+  `openapi.baseline-invalid` — the living slot is gone, so the pin is founded on nothing — an
+  error that blocks the archive until the quote is deleted. Unpinned, the same quote has no living
+  operation behind it, so the baseline axis cannot tell it from an addition — and it used to
+  archive as one, at exit 0, putting the retired operation back. The **revival check** below is
+  what refuses it now. So a delta quotes nothing it does not change, and every operation in it that
+  the living contract already holds carries
+  **`x-loam-based-on`** — the same 16-hex digest, in the
   vendor-extension shape this axis already uses for `x-loam-remove`, written by `loam rebase` and
   stripped on merge exactly like `Based-On:`. The digest is taken over the operation's *canonical*
   form (object keys sorted), which is the same comparison `isDeepStrictEqual` makes when the merge
   decides an operation "differs" — so a pin goes stale exactly when the merge would say something
-  moved, never over a reordered key. The pin is always the digest of the **living** operation, and
+  moved, never over a reordered key. The pin is keyed by the slot, method and path, on both sides,
+  so an operation written with no `operationId` — living or in the delta — is pinned, graded and
+  quoted exactly as a named one: `loam rebase` always pinned against whatever stood at the slot,
+  and the gate once read named operations alone, so it refused the pin rebase had just written as
+  one over "no operation at that slot" and never asked an unnamed quote for a pin. The pin is
+  always the digest of the **living** operation, and
   that one rule yields both merge verdicts by itself: an operation the author only quoted is
   byte-equal to living, so its pin equals its own content and **the merge skips it entirely**
   (reported as `· quotes …` in the plan, so the plan never silently writes less than the delta
@@ -984,7 +1882,8 @@ the source for tests.
   decision, reverting an operation nobody edited is a bug. `openapi.baseline-missing` is a warning
   that gates the archive, exactly like its requirement-axis sibling — every unpinned restatement is
   a candidate rollback — and it is reported **once per service** rather than per operation: the fix
-  is one command, and twenty-nine identical findings teach people to filter the code out. **Covered
+  is one command, and the twenty-nine identical findings a contract pasted whole from a
+  thirty-operation service would raise teach people to filter the code out. **Covered
   since the path-item/component baselines landed:** the same discipline now reaches the two surfaces
   the operation pin cannot — path-level keys (`parameters`, `servers`, `summary`, `x-*`) and every
   `components/<kind>/<name>` — through a single feature-only root record **`x-loam-baselines`** (`{
@@ -999,6 +1898,93 @@ the source for tests.
   component copying is verdict-driven, with genuinely new components copied only when reachable from
   content actually written. Removal markers still carry no pin, since
   `openapi.remove-target-mismatch` already checks that exact slot.
+- **A retired operation does not come back by accident.** An operation the living contract does
+  not hold is either new or *retired*, and the living contract alone cannot say which: both are
+  simply absent. So the feature gate also reads what every **archived** feature took out — the
+  `x-loam-remove: true` markers left in `features/archive/<FEAT>/specs/<svc>/openapi.yaml` and
+  `asyncapi.yaml`, through the same relocation rule the gate applies to an in-flight delta (a
+  marker on an id the same delta redefines elsewhere moved it, and retired nothing). A delta entry
+  that is not itself a removal, that its service's living contract does not hold, and that an
+  archived feature retired is **`openapi.op-revived`** (by operationId — a
+  retired operation quoted at a new path is the same operation back) or **`asyncapi.slot-revived`**
+  (a `channels` or `operations` slot by its key; a message by its *name*, wherever it is declared).
+  A relocation retires nothing, but it VACATES an address — and so does a retirement, once a later
+  feature re-adds the id somewhere else — so the index records, per id, every address an archived
+  feature's executed marker vacated, which feature, and for a move where its delta put the id. The
+  finding is judged on the contract the archive would WRITE: the check runs the archive's own
+  merge of the delta over the living contract and compares where each operationId stands there with
+  where it stands now. An (operationId, address) the merged contract has and the living one lacks
+  is `openapi.op-revived` when the living contract holds the id nowhere and an archived feature
+  retired it (anywhere — by identity) or moved it away from that very address, or when the merged
+  contract answers the id at two or more addresses and an archived feature retired it at, or moved
+  it away from, that very address: archived, it would answer the id at both. An id that the living
+  contract still holds and the merged contract answers at exactly one address is never a revival —
+  a delta moving it back with its own removal marker where it lives now, or swapping another
+  operation in there (named or not: the merge writes per method and path), leaves it at one
+  address — while a marker standing where the id does not live deletes nothing, and excuses
+  nothing. One address is no exemption for an id the living contract holds nowhere: that is the
+  first case, so a quote of an address a move vacated is the finding even after a hand edit took
+  the id out of where the move put it. Reading the merged contract replaced a
+  case-by-case re-derivation of the merge that each review found a new hole in.
+  On the event axis the same rule runs on the message name, over the event merge: the addresses a
+  feature vacates are `components.messages` keys (a marker there) and the inline declarations a
+  channel removal took. A delta that restates the channel an inline declaration stands in (with
+  the message as a `$ref`) or retires that channel takes the name out, since a channel upsert
+  replaces the channel's interior; a marker nested on the inline message does not
+  (`asyncapi.remove-marker-inline`), so the finding names the channel as the remedy. A channel or
+  operation slot's identity is its key, so moving one is a retirement plus an addition, graded as
+  such. A message declared inline under a channel the delta brings back is that channel's
+  interior, and the channel's finding stands for it — unless the merged contract declares the
+  name somewhere else too (an archived feature re-declared it under `components` when it retired
+  the channel): then the inline declaration is a second place of its own, and gets its own
+  finding, since the channel's says nothing of the duplicate `--approve` would archive.
+  Both are warnings that **gate** the archive, `openapi.baseline-missing`'s doctrine: the document
+  is legal, and re-adding a retired operation can be exactly what a feature means — a retirement
+  rolled back — so `--approve` carries the call, and the archive output then names what came back
+  and whose retirement it reverses. The message offers both remedies: delete the quote if it only
+  restated the operation; archive with `--approve` if the feature brings it back on purpose (a pin
+  over nothing is `openapi.baseline-invalid`, so a deliberate re-add drops it first). At a vacated
+  address beside a living one it names the address to drop instead: delete the quote, or, to move
+  the id back on purpose, take it out of where it lives now in the same delta (a removal marker
+  there; for a message declared inline, restate or retire its channel; for a `components.messages`
+  key, also restate every channel or operation of the merged contract still `$ref`-ing it, with
+  the `$ref` pointed at the quoted key — the message names them, since a marker alone would leave
+  them pointing at nothing and their send would stop sending the message) — and where the delta
+  already spells that address, so no marker can stand there, archive with `--approve`. A slot
+  holds one entry, so where the living contract has ANOTHER operation (or message) at the address
+  the delta spells the id at, the merge replaces it there: the message names it ("now holds
+  'requestCancellation', and archiving this delta replaces it there"), and the move-back remedy
+  says to define it at another address (another key, for a message) in the same delta if it is
+  to stay — never an address
+  "the living contract no longer has", a remedy that once led to a clean gate and an archive that
+  deleted the other entry unnamed. `loam rebase`
+  never pins such an entry as new: it prints the same finding (`revived[]` in `--json`) and leaves
+  the decision to the author. It asks the question of the delta as it will WRITE it, pins
+  included: a quote pinned to its own content is skipped by the merge, and the same quote
+  repinned to whatever now lives at its address is an edit the merge writes — so a revival
+  rebase's own repin creates is in that list, `--dry-run` included, and the next validate agrees. A channel-slot removal retires the messages its living channel
+  declared inline, which the delta never spells, so those names are read from the archived
+  feature's undo snapshot (`.loam-before/`, the pre-image of the contract the merge ran against) —
+  only while that pre-image still hashes to what the manifest recorded. A marker is a request, not a
+  record of what happened: the OpenAPI merge deletes a living operation only when the one at the
+  marker's own method and path carries the marker's `operationId`, and the event merge deletes a
+  `channels` or `operations` slot only when the living contract has that key, and a
+  `components.messages` slot only when the message declared there carries the marker's name. A
+  marker that missed — archived past `remove-target-missing` or `remove-target-mismatch` under
+  `--approve` — deleted nothing, so each marker counts only if the same pre-image held its target
+  (a contract the archive created, or never wrote, lost nothing to it); a feature with no intact
+  snapshot cannot be checked, and its markers count as written. Two marker
+  shapes are never sources, because neither can match anything: a marker with no `operationId`
+  (`openapi.remove-marker-anonymous`) and one written at path level
+  (`openapi.remove-marker-path-level`) — a feature archived past either under `--approve` left the
+  operation living.
+  **The honest limit:** the check knows only what the files under `features/archive/` record. A
+  removal made by hand-editing a living contract leaves no marker anywhere, and an archived feature
+  deleted from disk takes its markers with it; both read as "never retired", and a quote of such an
+  operation grades as an addition exactly as it did before the check existed. A channel's inline
+  messages drop out the same way when its feature carries no intact pre-image (archived before the
+  snapshot existed, or the snapshot edited or removed since) — the channel slot itself is still
+  caught. No git history is read: the archive directory is the record.
 
 A requirement may carry a stable identity in its body: `Requirement-ID: <id>`, where the ID matches
 `[A-Za-z][A-Za-z0-9._-]{0,127}`. It is optional for backward compatibility. When present in a delta,
@@ -1044,14 +2030,26 @@ scenarios exercise. Comma-separated, same keep-last-line quirk (and the same rep
 
 - a **C4 element** — its id (`paymentService.db`), or the service a bound/titled element stands for;
   resolved against the service's own model plus the landscape (for a feature delta: the feature's
-  `delta.likec4`, the landscape, and the service's model);
+  `delta.likec4`, the landscape, the service's model, and the map the merge would leave — and an
+  entry that resolves ONLY through the delta's own ids is `covers.unknown` at feature scope, because
+  the merge lands a stub's children under the living element it binds to, so the delta's spelling
+  is not the map's: write the service name, or the id the merged map gives the element);
 - an **edge** — `paymentService -> kafka`, each side resolved the same way against the declared
-  relationships;
+  relationships. Direction counts: `kafka -> paymentService` names a different edge (*Which way an
+  edge points*). The entry may carry the relationship's kind exactly as LikeC4 writes the edge,
+  `paymentService -[async]-> kafka` or `paymentService .async kafka`. loam identifies an edge by
+  its two endpoints and reads no relationship kind, so the kind is read past rather than compared:
+  either kinded spelling covers exactly what `a -> b` covers, every kind of edge from `a` to `b`.
+  (Through 0.2.0-alpha.10 both kinded spellings were always `covers.unknown`: the bracket form
+  split at the `->` after the `]`, and the dotted form was read as one element id.);
 - a **health signal** — `alert:<id>` / `sli:<id>`, ids the service's `health.yaml` declares.
 
 An entry that resolves to nothing is `covers.unknown` (**warning**, with close ids offered where
 they exist): the typo guard, because a mistyped entry silently costs exactly the coverage it was
-written for.
+written for. It is suspended — every form at once — for a service whose `model.likec4` could not be
+read, whether the model itself does not parse (`c4.invalid`) or it extends a map that does not
+(`spine.landscape-invalid`): an entry naming a container of an unread model is not a typo, and the
+one repair brings the whole grade back on the next run.
 
 **Coverage obligations** — both warnings, deliberately: they never gate `archive`, and `--strict` is
 the CI escalation.
@@ -1059,7 +2057,10 @@ the CI escalation.
 - `c4.uncovered` (feature scope): a NEW tagged element or tagged edge in the feature's
   `delta.likec4` that no requirement across the feature's `arch.spec.md` deltas covers.
   Grouping-only elements follow the landscape checks' exemptions (`person`-kind elements,
-  `#external` tags).
+  `#external` tags, and a GROUPING — an element that stands for no service and contains one, such
+  as a new domain `group` drawn around a new service: there is no obligation a group can carry, and
+  the service inside it is graded on its own). The `Covers:` line it offers is the spelling that survives the merge — an edge
+  by its endpoints' service names, an element by its service or the id the merge gives it.
 - `health.uncovered` (service scope): an alert or SLI declared in `services/<svc>/health.yaml` that
   no requirement in the LIVING `arch.spec.md` covers. This is the moment `health.yaml` stops being
   inert — and all loam reads out of it is ids: the recognized keys are top-level `slis:` and
@@ -1072,12 +2073,21 @@ the CI escalation.
   **warning** (`health.invalid`): its ids are unknown, not empty, so `health.uncovered` stays quiet
   AND the `Covers: alert:/sli:` entries of that service go ungraded — the old silence turned every
   such entry into a false `covers.unknown` "typo" pointing at the spec, when the truth was the file.
+  At FEATURE scope the same code names what the merge takes away: a signal the living
+  `arch.spec.md` covers that this feature's arch delta would leave covered by nothing — a MODIFIED
+  requirement restates its whole block, so a `Covers:` entry not carried over is one it deletes.
 - `health.dependency-unmodelled` (service scope): a `dependencies:` id that nothing in the service's
   OWN `model.likec4` answers to — by element id, `metadata { service }` binding, or title; exact
-  match, with a did-you-mean hint. Deliberately the service model and never the landscape: the
+  match, with a did-you-mean hint. Deliberately the service model and never the landscape read on
+  its own: the
   landscape carries only what crosses the service boundary, the model carries everything the service
-  touches (a private store as a nested container — `landscape.datastore-private` is the check
-  pushing it there), and that is the set the on-call file must agree with.
+  touches (a private store nested inside the service's own element — one of the two placements
+  "Private stores" above leaves to the team, and `landscape.datastore-shared` is what a second
+  consumer of that nested store earns), and that is the set the on-call file must agree with. For an extending model
+  the set is its own SLICE: the elements it adds, plus the partners its own edges point at and their
+  ancestors — so a dependency named `kafka` resolves through an edge that names `kafka.orderEvents`,
+  and a peer service resolves through the `metadata { service }` binding on the map's element the
+  model points at. A partner the model never reaches still does not answer, which is the check.
 
 The rest of the machinery treats the axis as what it is — requirements. `loam archive` merges an
 `arch.spec.md` delta into the living one through the same code path as `spec.md` (same delta
@@ -1161,12 +2171,15 @@ digest:
 - stamps: line 1 is `# generated by loam v<version> — …` (the AGENTS.md stamp pattern — the file is
   never to be hand-edited), and each scenario carries the tag `@loam-digest-<16hex>` on the line
   above its `Scenario:` keyword: the first 16 hex characters of `loam verify`'s scenario body hash —
-  sha256 of the body lines joined and edge-trimmed, salted with the file name on the arch axis, the
-  exact recipe `scenario.tested` claim ids fold in — so the stamp, the claim and the spec can never
-  disagree about what a scenario says, and identically-worded scenarios across `spec.md` and
-  `arch.spec.md` can never share a digest (a business-axis test run cannot answer for an arch
-  scenario). A tag rather than a comment because cucumber's JSON report carries tags per scenario
-  (`elements[].tags`): the stamp rides through the runner untouched, which is what
+  sha256 of the body lines joined and edge-trimmed, salted with the owning SERVICE and, on the arch
+  axis, with that axis's file name — the exact recipe `scenario.tested` claim ids fold in — so the
+  stamp, the claim and the spec can never disagree about what a scenario says. Both salts are there
+  for one reason: a digest that spanned two namespaces would let a green run answer a question
+  nobody ran a test for. Identically-worded scenarios across `spec.md` and `arch.spec.md` can never
+  share a digest (a business-axis test run cannot answer for an arch scenario), and neither can two
+  services wording a scenario the same way (one repository's green run cannot answer another
+  repository's claim). A tag rather than a comment because cucumber's JSON report carries tags per
+  scenario (`elements[].tags`): the stamp rides through the runner untouched, which is what
   `loam verify --results` matches on.
 
 **Staleness** (`loam validate --service <id>`, service-repo-scoped like the `sources.*` chain):
@@ -1239,6 +2252,12 @@ requirement also needs a current `Based-On:` pin before archive; `loam rebase <F
 Omitting or leaving the intent as scaffold text raises the gating `intent.empty` /
 `scaffold.placeholder` warning, so the old one-file shape is not archive-ready.
 
+Below that floor is no feature at all. A change that touches no requirement, no operation and
+no fleet edge — a refactor, a dependency bump, a fix that brings the code back to behaviour the
+living spec already documents — leaves the docs repo untouched: it is a code PR, then
+`loam validate --service <id>` in the service repo, where `sources.stale` names the moved paths, and
+the re-vouch they owe (`loam vouch --pack` is the reading list; the vouch is a person's).
+
 Each axis may be legitimately empty, and the checks grade absence differently from
 emptiness-by-accident:
 
@@ -1249,11 +2268,17 @@ emptiness-by-accident:
   declared-but-untagged is almost always a forgotten tag, while declaring nothing is a legible
   statement that the architecture is unchanged.
 - **openapi delta** — absent whenever the feature adds no operations; a requirement change that
-  stays inside the existing contract has no API axis to speak on.
+  stays inside the existing contract has no API axis to speak on. Present, it holds only the
+  operations the feature adds, changes or removes.
 - **requirement delta** — the axis that is nearly always present, because a feature that changes no
   requirement changes no promised behaviour. The exception is architecture-only work: a new service
   in the C4 delta with no `specs/<svc>/spec.md` gets `service.no-requirement-delta` as a warning,
-  not an error.
+  not an error. "New service" is the fleet census's reading of the map the merge leaves: a tagged
+  `softwareSystem` of ours — not `#external`, not a grouping, drawn inside nothing but groupings
+  the delta declares — that no `services/<id>/` answers for and the living map does not already draw. A
+  delta's `#external` producer owes no requirement delta, and neither does the stub of a living
+  element (whose living tags the merge keeps, so a re-declared `#external` system stays external
+  whatever the stub says).
 
 `intent.md` is where the "why" lives — the delta says what changed, and nothing else says what for —
 and the archive gate holds it to that: `intent.empty` (a warning that gates, `--approve`
@@ -1262,6 +2287,16 @@ a feature cannot fold into the living docs with its reason unwritten. Its siblin
 `scaffold.placeholder` refuses the rest of an unedited `loam new` scaffold the same way — the exact
 template strings, a requirement or description nobody authored, must not become living truth.
 
+The scaffolded `intent.md` also carries an optional `## Open questions` heading over a comment.
+It is where `loam-feature`'s analyze step — between authoring and `loam rebase` — writes what the
+documents leave open: a SHALL two engineers could build two ways, a value or window two services
+state differently and which side refuses, a `Realizes:` that does not deliver its capability, an
+edge with no stated timeout, retry, partial-failure or compensation answer, a neighbour left out of
+`--touches`. A person answers by editing the file. Nothing grades the section: `intent.empty` reads
+past it, so questions written there are never mistaken for the Why, and they never gate the archive —
+every check loam has is a join between exact tokens, and whether two services MEAN the same thing by
+one is the part no join reads.
+
 ### Where a capability lives (a declared name, and the document behind it)
 
 A business capability — "payment splitting" — is spread across the living specs of every service
@@ -1428,13 +2463,19 @@ refusing it, which is why the flattening is a whitelist and not a list of substi
   document declares no requirements yet, it declares none flattening to this slug (close ids
   offered, each already spelled as the tag to write), or two of its ids flatten to one slug.
 
-**Either reserved prefix opts a view in.** A view carrying `#req-` and no `#cap-` is an author who
+**Any reserved prefix opts a view in.** A view carrying `#req-` and no `#cap-` is an author who
 asked to be graded and forgot half the claim; it earns the `unscoped` message rather than silence.
-That opt-in is **one predicate**, and every reader takes it: `loam validate`, `loam diff`,
-`loam delta`, `loam status`, the context and explore packs and `loam list capabilities` all decide
-"is this a use case" the same way, so a flow one of them can see is a flow all of them can see. The
-byte scan that lets a fleet with no use cases skip the LikeC4 load looks for both prefixes for the
-same reason — a gate narrower than the predicate is silence, not a smaller answer.
+A view carrying only `#suite-<name>` is a use case too (see the layout section above). That opt-in
+is **one predicate**, and every reader takes it: `loam validate`, `loam diff`, `loam delta`,
+`loam status`, the context and explore packs, `loam list capabilities` and `loam list suites` all
+decide "is this a use case" the same way, so a flow one of them can see is a flow all of them can
+see. The byte scan that lets a fleet with no use cases skip the LikeC4 load looks for every prefix
+— `cap-`, `req-` and `suite-` — for the same reason: a gate narrower than the predicate is silence,
+not a smaller answer. It looks for each written as a tag REFERENCE: a `#`, then only what LikeC4
+skips between the `#` and a tag's name (whitespace, line breaks, comments), then the prefix — the
+only way a view carries a tag. A prefix in prose, a title or a `tag cap-…` declaration does not open
+it, so a hand-drawn `.likec4` beside a service's model that names `suite-` in its title, carries no
+tagged view and does not parse is not loaded and earns no `usecase.flow-invalid`.
 
 Being SEEN is not the same as claiming something, and the difference is worth stating because it
 looks like a gap and is not. A view with no resolved `#cap-` tag claims no capability, so it seeds
@@ -1465,6 +2506,21 @@ turn a mistake into a green fleet. And a run that could not READ the flows (a si
 an `architecture/` that did not parse) suspends `capability.requirement-unrealized` entirely: loam
 did not look, which is never the same answer as "there is nothing there".
 
+**A `#req-` tag inside a service's own project is scoped by the SERVICE, not by a capability.** A
+`dynamic view` beside model.likec4 carrying `#req-<slug>` resolves against the `Requirement-ID`s of
+that service's spec.md and arch.spec.md together — flattened by the same rule, an id both declare
+resolving once, and `many` when the two documents declare ids that flatten alike, because a
+Requirement-ID is unique inside ONE document and a flow beside the model has two.
+`usecase.requirement-unresolved` there has four arms: no document at all, no identified requirement,
+none flattening to the slug (close ids offered), or two that do. No `#cap-` tag belongs there
+(`usecase.capability-unresolved` says so, vocabulary or not); `usecase.step-unlinked` never fires
+on a hop whose caller and provider resolve to the same service — a service owes no operationId to
+itself — and still fires on a hop from such a flow into another service's element (a stand-in the
+model declares for a sibling, with no `metadata { op }`), exactly as on the fleet map; and a
+resolved service-local claim is the join being checked and nothing more today: it
+enters no capability `keptBy`, counts toward no `Covers:` or `c4.uncovered`, appears in no pack,
+`loam list capabilities`, `loam diff` or `loam delta`, and no feature carries one yet.
+
 **Both corpora are reported together, and neither is derived from the other.**
 `loam list capabilities --json` carries `keptBy` (the flows keeping a promise) beside `realizedBy`
 (the service requirements realizing it) on every `requirements[]` row, with the same three-state
@@ -1516,9 +2572,11 @@ requirement grammar and delta algebra every service spec already uses —
 nesting spelled by the tree exactly as the living corpus spells it
 (`features/FEAT-9/capabilities/payments/refunds/spec.md`). `loam archive` merges it through the same
 transactional path as every other document and **creates `capabilities/<cap>/spec.md`, and the
-`capabilities/` tree itself, when the feature is the first to name that capability**;
-`loam unarchive` takes it back and removes what the archive created; `loam rebase` pins its
-`MODIFIED`/`REMOVED` requirements.
+`capabilities/` tree itself, when the feature is the first to name that capability** — titled by
+the delta's own H1 unless that title is about the change, with the delta's `## Purpose` as its
+narrative and a line linking back to the archived delta (Conventions, "When archive CREATES a
+living document"); `loam unarchive` takes it back and removes what the archive created;
+`loam rebase` pins its `MODIFIED`/`REMOVED` requirements.
 
 **Both lifecycles coexist and neither is deprecated.** A capability document may still be edited
 directly under PR review, like `capabilities.yaml` and the use cases. What changes for a document a
@@ -1533,6 +2591,41 @@ they gate archive. Without that the feature-local delta becomes a second way to
 requirements: a capability requirement carrying `Operations:` would merge into the living tree and
 only then earn its error, against a document whoever reads the finding did not write.
 
+**A promise a living flow keeps, rewritten, is named.** A MODIFIED keeps the `Requirement-ID` and
+replaces the text, so a living flow tagged `#req-<id>` still resolves after the archive and every
+grade of it stays green — while it may draw exactly what the new wording forbids. Nothing in loam
+reads a flow's meaning, so `usecase.requirement-modified` (**warning**, never gates) names each such
+flow under `validate --feature` and in the archive's warnings: an `architecture/` flow whose `#cap-`
+tag scopes its `#req-` tag to a capability requirement this feature modifies, and — at the service
+altitude, where the directory is the scope — a flow beside a service's model whose `#req-` tag names
+one of that service's spec.md / arch.spec.md requirements the feature's `specs/` delta modifies. Read
+the flow against the replacement, and redraw it (or drop the tag) in the same change if it no longer
+keeps the promise.
+
+**A promise a living flow keeps, removed, is the fleet's error one archive early.** A REMOVED
+requirement leaves the flow's `#req-` tag resolving to nothing, so the very next `validate --all`
+reports `usecase.requirement-unresolved` against the living flow. The same walk, over the same two
+altitudes and scopes, now raises that code at feature scope — **error**, gating the archive, with the
+view as its subject exactly as the fleet names it, and a message naming the living flow file and the
+requirement the feature removes. It is graded against what the merge leaves, not against the REMOVED
+list: a removal the same delta re-spells under an id that flattens to the same tag keeps the tag
+resolving and earns nothing; and a service-local tag reads BOTH of that service's documents, skipping
+a requirement under a `## REMOVED Requirements` heading as `validate --all` does, so an id the
+document the feature leaves alone still declares keeps it resolving too. The same verdict is asked of
+a MODIFIED: it keeps its id, but an id the feature adds beside it can flatten to the same tag, and
+then the flow earns this error (naming the colliding ids) instead of `usecase.requirement-modified`,
+whose "the tag will still resolve" would be false. Only a tag that resolves today is asked about —
+one already broken is `validate --all`'s finding now. `--approve`
+may override it, as it overrides `capability.remove-requirement-realized` for the same retirement
+seen through a `Realizes:` line: whether to retire a promise something still claims is the author's
+call, and the living docs then carry exactly the error named. The fix inside the feature is to drop
+the tag from the living flow (or point it at the promise that replaces this one) in the same change,
+or to MODIFY the requirement instead of removing it.
+
+The cost of both is a byte scan for the tag's spelling, the living document of a touched service's
+other axis, and a LikeC4 load only for a project a document carrying the tag is in; a feature that
+modifies and removes nothing pays nothing.
+
 **The archive refuses a promise nothing keeps, in both directions.**
 
 - `capability.uncovered` (**warning that gates**, `--approve`-overridable) — the feature ADDS a
@@ -1552,6 +2645,13 @@ only then earn its error, against a document whoever reads the finding did not w
   does not land, or a landscape merge that itself refuses. The flows were not graded, so the archive
   would copy them into `architecture/` for somebody else's `validate --all` to fail on. `--approve`
   overrides loam's judgement about coherence, never its ability to read an axis.
+- `usecase.step-unbacked`, `usecase.requirement-unresolved`, `usecase.capability-unresolved`
+  (**errors**) and `usecase.step-contested`, `usecase.step-unlinked` (warnings) — the flows that DO
+  read, graded by the very grader `validate --all` runs over a living flow, against the post-merge
+  map and the capability vocabulary and requirement ids the merge would leave (an id this feature's
+  capability delta adds resolves; one it removes does not). Each message opens with the feature
+  file's path. Before these ran here, a hop nothing backs and a `#req-` tag nothing scopes archived
+  clean and turned the next `validate --all` red.
 - `usecase.flow-exists` (**error**, never `--approve`-overridable) — a flow this feature introduces
   that `architecture/usecases/` already holds. The merge is a whole-file copy, so it would replace
   an authored hop sequence wholesale; the same shape and the same severity as `glossary.term-exists`,
@@ -1604,7 +2704,10 @@ ready. Several useful product shapes remain outside that boundary on purpose:
   a third thing to keep truthful.
 - **Authored `tasks.md` as authoritative state** — loam derives its actionable checklist (`loam
   delta`, `loam verify`), so it cannot drift from the delta. Imported task lists are preserved as
-  non-authoritative migration evidence until a human chooses their disposition.
+  non-authoritative migration evidence until a human chooses their disposition. The refusal stands,
+  and the derived projection now exists as `loam tasks`, which answers the same question the file
+  would have — recomputed from the delta, the generated suite and the verification record on every
+  run, so there is nothing to tick and nothing to go stale.
 - **Per-tool workflow forks** — `AGENTS.md` is the tool-agnostic contract. Generated adapters wrap
   shared bodies and are never independent process definitions.
 
@@ -1675,7 +2778,7 @@ the merge wrote, and `before`, of the pre-image sitting beside the manifest (nul
 created the file). That directory travels with the feature into `features/archive/`, and
 `loam unarchive` puts it back.
 
-The manifest is **version 3**. Version 2 added `before`: a version-1 snapshot described only what
+The manifest is **version 4**. Version 2 added `before`: a version-1 snapshot described only what
 archive *wrote*; nothing described the bytes it would *restore*, so a pre-image altered inside the
 archived feature directory — a bad merge, a rebase, a stray editor — was written back verbatim and
 every loam surface certified the result as "the living docs are back to what they said before the
@@ -1688,12 +2791,42 @@ naming the pre-image under `.loam-before/files/`. At restore time the write targ
 the **current services enumeration**: the bytes land wherever the service lives *today*, not
 wherever it lived on the day of the archive, and an id the enumeration no longer answers falls back
 to the literal path (an absent service restores as a create, exactly as before). Entries under
-`architecture/` and `features/` stay literal-path-only — they do not move. Version-2 manifests are
-still read, forever, under their own literal-path rules: they already sit inside archived features,
-which carry them across loam upgrades. Correspondingly, `archive` refuses to replace a
-`.loam-before/` whose pre-images no longer match the living bytes — version 2 or 3 alike, with a
-version-3 claim graded at its service's current directory: the previous archive's writes are still
-in the docs and those files are the only way back.
+`architecture/` stay literal-path-only — they do not move. Entries for the feature's own documents
+(the ones the archive relinks for its move, Conventions above) are literal too, recorded where the
+move leaves them — `features/archive/<FEAT>/…`, which is where `unarchive` restores them before it
+moves the directory back — so they needed no layout version of their own; the two readers that meet
+a snapshot before its feature moved, the clobber guard below and the crash repair, look for them
+across the move. The documents outside the feature whose links into it the archive rewrites are
+ordinary rows: a service's keyed by `(service, artifact)` like every `services/` entry, the rest — a
+fleet ADR, a glossary term, another in-flight feature's intent — by their literal path. Version 4 stores each
+pre-image as **`files/<path>.before`** rather than under its living name. A pre-image kept as
+`files/architecture/landscape.likec4` was a second copy of the map inside the archived feature, and
+every tool that reads by extension took it for a document: a feature with its own
+`likec4.config.json`, or one rendered alone (`likec4 start features/archive/<FEAT>`), loaded the map
+twice beside the delta and failed on duplicate elements, as did a fleet project that did not
+exclude `features/`. With the suffix no pre-image is a `.likec4`, `.md` or `.yaml` to anything.
+Version-2 and version-3 manifests are still read, forever, each under its own rules — version 2 by
+literal path, version 3 keyed, both with pre-images under their living names: they already sit
+inside archived features, which carry them across loam upgrades, and a snapshot is restored from
+where it was written, never migrated. An older loam reads a version-4 snapshot as one it cannot
+honour (`snapshot-missing` from `unarchive`), which is the refusal it owes a layout it would have to
+guess at. Correspondingly, `archive` refuses to replace a `.loam-before/` whose pre-images no longer
+match the living bytes — version 2, 3 or 4 alike, with a keyed claim graded at its service's
+current directory: the previous archive's writes are still in the docs and those files are the only
+way back.
+
+The manifest also carries one key that is not about bytes, added without a version bump because
+nothing that restores reads it: **`checklist`**, the digest of the checklist a fresh `loam verify`
+derived for the feature just before the merge — written when the feature carried a readable
+verification record then, absent otherwise and in every manifest an older loam wrote. It is the
+question the feature asked as it shipped. Once archived, a record is frozen history and the checklist
+cannot be re-derived (the merge moved the feature's operations into the living contract, so a
+derivation after it can only mismatch), so this is the one thing an archived record can still be
+held to: `loam gate --since` grades the record against it, and a record that answered an older
+checklist reads `stale`. `unarchive` takes the snapshot away with the rest of it, so a feature
+archived again gets a fresh capture. `list`, `status` and `verify` keep reading an archived record as
+frozen history; a manifest with no `checklist` leaves the gate reading it that way too, and saying
+so.
 
 Some checks run at plan time rather than in the gate, because only the computed merge can see them.
 A **living** requirement sitting outside `## Requirements` refuses the whole archive
@@ -1702,15 +2835,63 @@ requirement would land in the file twice — and `--approve` does not override i
 duplication is mechanical, not a judgment call; re-home the requirement first. A delta that
 redefines a path+method the living OpenAPI already has (`openapi.op-modified`, warning) merges
 anyway, but the plan says so — the overwrite is wholesale, and the living definition it replaces
-deserved an eye. An unparseable `delta.likec4` fails the archive at plan time regardless of
+deserved an eye. One that defines a different operationId there, leaving a consumed operation
+defined nowhere, never reaches the plan without `--approve`: the gate refuses it first
+(`openapi.remove-op-consumed`, the overwrite shape). An unparseable `delta.likec4` fails the archive at plan time regardless of
 `--approve`: the alternative was archiving with the architecture axis silently dropped, which is the
 data loss this tool exists to prevent.
 
+**What a replacement takes away is named, not just counted.** A MODIFIED requirement carries its
+full new text and replaces the living one whole, so every living scenario and every join-line entry
+(`Operations:`, `Covers:`, `Requires:`, `Capability:`, `Realizes:`, `Publishes:`, `Consumes:`) it
+does not restate is gone after the merge. Under each `← +A ~M -R` line the plan now prints one line
+per replaced or removed requirement saying what goes — the scenarios by name, the entries verbatim —
+and `archive --json` carries the same rows as `dropped`
+(`[{ path, kind, requirement, id?, scenarios, directives: { covers?: […], … } }]`: `path` the living
+document; `kind` `MODIFIED`, `REMOVED`, or `ADDED` for an ADDED that lands on a living requirement
+of the same id or name; `requirement` and `id` the LIVING requirement's heading and id, `id` absent
+when it has none; `directives` keyed by field — `operations`, `covers`, `requires`,
+`capabilities`, `realizes`, `publishes`, `consumes` — each present only for a line that loses an
+entry, and a `Realizes:` entry compared by its target so a `@<digest>` pin is never a drop). `loam delta --json` carries the identical rows as its own `dropped` key, and its human view
+prints them under *Taken out of the living docs by the merge*, so the brief says before the archive
+what the plan says during it. Read verbatim and by name, deliberately: a renamed scenario or a
+`Covers:` entry respelled from an element id to the service name is listed, because what is listed
+is what the living text says and the merged text does not — the author decides whether it meant the
+same. Never a warning and never a gate: rewriting a requirement smaller is legitimate; what was
+missing was being told. The one drop that IS graded is the health signal's, as before
+(`health.uncovered` at feature scope).
+
+**The contract merges write over the living text, not out of a printer.** Both the OpenAPI and the
+AsyncAPI merge used to hand the living contract back through the `yaml` library's printer, which
+re-folds every plain scalar at 80 columns, re-pads every flow sequence (`[a, b]` → `[ a, b ]`) and
+turns CRLF into LF — so a delta adding one channel rewrote a long `description` three sections away.
+`lineWidth: 0` is not the fix (measured: it joins every scalar the author folded by hand onto one
+line). The merge now SPLICES: the living and merged trees are walked block map by block map, every
+entry whose resolved value is unchanged keeps its bytes, a changed entry is descended into or
+replaced, a new one is printed after the entry the merge placed it behind, a removed one is cut with
+the comment lines directly above it, and new lines take the file's own line ending. Only those
+entries are printed by the library. The spliced text is parsed back and must equal the merged tree
+value for value; a shape the walk does not understand (a non-scalar key, a key spelled twice, a
+reorder, an alias it cannot print alone) or a mismatch falls back to the whole-document write, so
+the splice can narrow a diff and can never change what a contract says. `loam rebase` writes its
+`x-loam-based-on` pins and `x-loam-baselines` record into a FEATURE's contract the same way, so a
+rebase changes those lines and no others in the author's file.
+
+**The delta's `info` is not merged, and the plan says so.** Neither merge carries `info` (nor any
+root key outside the sections it merges) — a delta is a diff of operations and slots, and its `info`
+is most often a copy. But a delta that DID move it lost the change at exit 0 with nothing in the
+plan. Now every `info` key the delta declares with a value different from the living contract's is
+reported — `openapi.info-not-merged` / `asyncapi.info-not-merged`, a warning naming the keys
+(`info.version`, `info.description`) — including for a delta whose only change is its `info`, which
+merges nothing at all. Keys the delta leaves out are not compared. If the `info` should move, edit
+the living contract in the same change.
+
 The landscape merge **splices authored source, it does not re-serialize**. Each new element and
 relationship is copied into the living landscape byte-for-byte from `delta.likec4` — technology,
 style, icons, links, metadata, nested children, every tag — with exactly one edit: the feature's own
 tag is stripped (the additions are baseline now — the drop above is why unarchive restores bytes),
-and a construct the strip empties goes with it (`x = kind 'y' { #FEAT-1 }` lands as `x = kind 'y'`).
+together with the `,` or `;` that set it apart in a tag list (`#FEAT-1, #x` lands as `#x`), and a
+construct the strip empties goes with it (`x = kind 'y' { #FEAT-1 }` lands as `x = kind 'y'`).
 Placement is deterministic and **service-grouped**, and never moves an authored byte — it only
 chooses where the new blocks go. A top-level element whose service the model already draws (the
 `metadata { service }` binding first, the title as fallback) lands immediately after the last
@@ -1725,18 +2906,129 @@ its leading statement (an anchored join sits where its anchor is, wherever its o
 sort, so comparing per statement would make placement depend on which archive ran first). That is
 what makes the scheme **order-independent**: archiving feature A then feature B (touching different
 services) yields the byte-identical landscape to B then A, so concurrent archive PRs usually splice
-different lines and git merges them without help. The insertions carry no marker comment — which
+different lines and git merges them without help. The relationship walk sorts **only within the
+region's ascending tail** — the run of cluster heads that already reads in key order from the end,
+which loam's own insertions keep that way — and stops where the existing order descends. A
+hand-written relationship region is sorted by nobody, and walking into it made the landing spot a
+function of unrelated edges: turning one hand-drawn edge round (`svc -> broker` to
+`broker -[delivers]-> svc`) changed the head key the walk compared and moved an addition sixty lines
+away. On a region loam wrote the bound changes nothing, and it keeps the scheme order-independent:
+the statements before the tail never change, so every archive inserts into the same sorted run. (The
+element walk keeps its plain insertion sort over the few top-level elements, as before.) Wherever a
+walk stops **before** a statement, or at the closing brace, the addition lands **above the comment
+written directly over it** — a comment is about what follows it, or heads the section it opens, and
+an addition spliced at the statement's own line sat between a six-line explanation and the edge it
+explained. "Directly" is literal: a blank line ends the comment run, so a comment separated from
+the statement below it by a blank line stands alone and stays where it is, and the tail of a block
+comment opened on an earlier line is never split. The same rule at both stopping points is what
+keeps two additions landing in one gap order-free. The insertions carry no marker comment — which
 archive added what is the git history's to say. A **nested** element lands inside its parent's block
 — inside the living parent when the landscape already has it, riding verbatim inside the spliced
-parent when the parent is new — never as a flat dotted id, which LikeC4 rejects at top level. LikeC4
+parent when the parent is new — never as a flat dotted id, which LikeC4 rejects at top level. A
+landscape may be written in **several top-level `model { }` blocks**, which LikeC4 reads as one
+model, and the merge reads all of them: an ANCHORED addition — nested in a parent, joining its
+service's neighborhood, or joining its source's edges — lands in its anchor's block, and an
+unanchored one lands in the trailing region of the **first** block, the one every addition went to
+before a second block was readable. The walks never cross a block boundary, so the scheme stays
+order-independent, and a one-block map places exactly as before. LikeC4
 reference resolution is not order-dependent, so a relationship placed before an element it names
 still parses — and because splicing is text surgery, the computed landscape is **parsed in memory
 before anything is written**: a result LikeC4 rejects — a splice bug, or legal inputs the living
 document cannot absorb, like an element kind or tag its `specification` block never declares —
 refuses the archive at plan time (`merge-failed`, nothing written), the same discipline as the
-unparseable delta. A living declaration sharing its line with another statement (legal LikeC4 the
-splice map cannot see around — its statement scan runs to the end of the line) refuses the same way:
-give each top-level declaration its own line, then re-run.
+unparseable delta. A living declaration the splice map cannot locate refuses the same way rather
+than be spliced around blind — most often one sharing its line with another statement, which is
+legal LikeC4 the splice map cannot see around, since it reads one statement per line. The refusal
+names the line LikeC4 parsed the declaration on and what the splice map read there instead, and
+says "shares that line" only when the line shows it: give each top-level declaration its own line,
+then re-run.
+
+**Which document an addition lands in.** The C4 merge asks it per declaration, not per feature. An
+element whose PARENT resolves to a service whose `model.likec4` extends the map is spliced into that
+model — and so is the interior a delta writes inside a service element the same archive introduces,
+since those containers carry no feature tag and would otherwise ride onto the map inside their
+parent's bytes. The parent chain has to be spelled in the map's own ids for either to happen. The
+splice goes inside the `extend <fqn> { … }` block for the parent — in whichever `model { }` block
+holds it, and appended to the first one when the model has none, as
+the `model { }` block itself is appended to a model that has none (an empty file, a `views { }`-only
+file and a tags-only `specification { }` are all extending models, and all three are legal to
+archive into). A
+relationship goes to the model of the service owning its SOURCE when the source is interior to such
+a service, else to the model owning its TARGET, else to the map: a service-level edge stays where
+every fleet check reads it. A service with a STANDALONE model, or none yet, owns nothing — the map
+draws its containers, which is legal and is what every repository did before the extending shape.
+The merged model is proved the way the grader reads it (the `architecture/` documents with this
+archive's own merged landscape in place, plus the model) before anything is written, and it appears
+in the `--json` plan as an ordinary write, so `loam unarchive` restores it from the same
+`.loam-before` snapshot as any other overwritten file. Two limits are deliberate and each refuses at
+plan time with nothing written: a merged model that does not parse beside the map (`merge-failed`),
+and a container-level edge whose other end lives in a THIRD document — another service's interior
+resolves in neither this model nor the map, so that call is drawn service to service on the map. One
+more is silent: a delta that spells the parent under its own name rather than the map's (the legacy
+title-join) keeps landing on the map, because splicing its bytes into a document that shares the
+map's id namespace would carry ids nothing there resolves. It is the WHOLE chain that decides, not
+the outermost box — `marketplace.orderSvc.cache` under a map that spells the service
+`marketplace.orderService` is a title join and stays on the map, even though the group
+`marketplace` is the map's own. A block a delta writes for a NEW service is split — the box to the
+map, its containers to the model — unless the block also draws a relationship between those
+containers. Such an edge names its endpoints by their local names inside the block, so splitting it
+would leave the map naming children it no longer declares; the block rides whole instead, as it did
+before routing existed. The block decides once for everything written inside it: a container or an
+edge the delta tags with the feature follows its block rather than its own tag, so it is placed
+exactly once whichever way the block goes. Re-archiving is idempotent in the models
+too: an addition whose id, or whose title inside the same bound service, an extending model already
+declares is skipped exactly as one the map declares is. The title half is service-scoped in a model
+and global on the map — the map's global join is the fallback for documents written before
+`metadata { service }` existed, and a service's interior is where two boxes called `api` would
+collide.
+
+**A service the archive creates gets its model, empty.** A service the feature carries
+`specs/<svc>/` for and the fleet does not enumerate is one whose directory the archive creates; when
+the map the merge leaves also DRAWS it — the living map, or an element the delta adds, bound to it or
+titled with its name; a context element the delta only quotes is merged nowhere — the archive writes its
+`model.likec4` beside its first documents: a header comment and an empty
+`model { }`, extending the map, with whatever the delta draws inside the service routed into it
+like any extending model's interior (FEAT-101's `api` container lands there, not on the map). It is
+a `create` in the plan, so `loam unarchive` deletes it. Two alternatives were rejected. Leaving the
+file out was the old behaviour: `service.no-model` on the next `validate --all` after an archive
+that exited 0, and the new service's containers riding onto the map because no model existed to own
+them. Writing a container model would be inventing one. An EMPTY extending model invents nothing —
+LikeC4 reads it as the map's box with nothing drawn inside, and an empty file is already a legal
+extending model — while it lets the service's first `validate --all` grade it rather than stop at a
+missing file. A team that pre-placed an empty extending model got exactly this result; nobody has to
+know to now. The feature gate's merge preview routes the same way, so a feature flow hopping into
+the new service's container is `usecase.flow-invalid` before the archive, as it would be
+`landscape.invalid` after it — and a feature deployment document naming it
+`deployment.doc-invalid`. A service whose directory already exists is enumerated and left alone.
+`service.no-model` is still owed — at error severity, never gating — in two shapes: a service the
+map gains with no `specs/<svc>/` behind it (there is no directory, `landscape.binding-unknown`
+follows, and a model would be the one document in a directory the archive invented), and a
+`specs/<svc>/` the merged map never draws, which the gate already calls an unknown service and only
+`--approve` brings to the merge — a model there would fabricate a service out of what is usually a
+typo, which is also why the spec merge creates no empty living spec.
+
+**Where it lands is the tree's to say, never the map's.** The directory is always the unfiled
+`services/<svc>/`. The archive does not read a subsystem off the delta's group nesting — the map's
+grouping and the tree are independent (Subsystems, above), and a map edit must never decide a
+directory — and it takes no `metadata { subsystem }` hint either: that key would be spliced into the
+authored landscape, writing tree placement into the one document the tree is never mirrored into.
+The tree is placement's only input. To file a new service at archive time, create its directory
+first — an empty `model.likec4` at `services/<subsystem>/<svc>/` does it, and the archive then writes
+the specs there and routes the interior into that model — or move it afterwards with
+`loam subsystem move <svc> --into <subsystem>`, which the archive prints when the tree has a
+subsystem.
+
+**What the splice reads off kinds.** An extending model declares no kinds, so the archive scans it
+with the map's: without them its `kind name` declarations and its `a .kind b` edges read as property
+lines, an edge routed into the model landed above a dotted edge, a delta restating a dotted edge
+added a second copy, and a child of a kind-first container was refused as nesting under nothing.
+Kinds declared in an `architecture/` document other than the landscape are not borrowed — the
+landscape is the extending shape's one `specification`. And a relationship kind may carry tags
+(`relationship publishes { #async }`, LikeC4 1.59.0+): the parse hands every edge of the kind those
+tags, the delta's statement shows only what is written in it, so the splice matches a parsed addition
+to its statement with the kind's tags added to the written ones. Matched as written, every edge of a
+tagged kind found no statement — `merge-failed` from an archive `validate --feature` had called ready,
+or `usecase.flow-invalid` when the feature had flows.
 
 The OpenAPI merge carries components along with operations, and since the path-item/component
 baselines it decides each one **by verdict rather than by reachability**: a component the feature
@@ -1753,6 +3045,14 @@ the written content and copied components that resolves in **neither** document
 overrides it — unlike the mechanical refusals, this one is a judgment call. External references —
 URLs, file paths, anything not starting `#/` — are out of scope: left untouched, never gated.
 
+A service with no living contract gets the feature's `openapi.yaml`, stripped of removal markers —
+unless that document describes nothing: no path, no webhook and no component in any section. Then no
+living `openapi.yaml` is created and the plan says `nothing to merge`, the spec axis's rule for a
+delta that leaves no requirements. A `paths: {}` stub published as a living contract says "this
+service exposes nothing" to every consumer that joins against it; with no file the service reads as
+one with no HTTP surface, which `service.no-openapi` already grades on evidence — silent while
+nothing calls it, an error once something does.
+
 `loam archive --json` speaks the same machine contract as everything else: on success (or
 `--dry-run`) the plan (`{path, action, to?}` per file), the non-blocking warnings, and whatever
 `--approve` overrode; on refusal a stable `error.code` — `not-coherent` and
@@ -1779,6 +3079,16 @@ lists the files that need a hand.
 - `commit-interrupted` — a previous `archive`/`unarchive` was killed mid-commit and this run cannot
   repair it on its own.
 
+What `unarchive` restores is what the archive WROTE, and the two generated views files were never
+among it: `loam subsystem sync` owns them, and a sync run between the archive and the undo rewrote
+them against the merged map. So after the restore `unarchive` asks the question archive asks after
+its merge — through `validate`'s own staleness grade — and when `architecture/subsystems.likec4` or
+`architecture/services.likec4` no longer matches the restored tree and map it names each one
+(`⚠ <path> no longer matches the tree and this map — run \`loam subsystem sync\``) instead of
+closing on "the living docs are back to what they said before the archive", and `--json` carries
+them as `staleViews` — the same key, with the same meaning, as `archive --json`'s; absent when
+nothing is stale.
+
 Rules (`loam validate`): every requirement has ≥1 scenario; every C4 edge `op` resolves to an
 OpenAPI operation governed by a requirement; and **the diff applies** — a `MODIFIED`/`REMOVED`
 requirement exists in the living spec, an `ADDED` one does not, and a section heading matches
@@ -1808,12 +3118,14 @@ design. The heading must be reachable, too — a leading UTF-8 BOM used to hide
 
 ## The verification record
 
-`features/<FEAT>/verification.yaml` is the done-check written down. `loam verify <FEAT>` derives a
+The done-check is written down inside the feature: one `features/<FEAT>/verification/<svc>.yaml` per
+attesting service, or — for the all-at-once form, and every record written before the directory —
+the one file `features/<FEAT>/verification.yaml`. `loam verify <FEAT>` derives a
 **checklist** from the feature's own artifacts — the same files `validate` reads, never the code:
 
 | kind | one claim per | reads |
 |---|---|---|
-| `service.exists` | tagged top-level element the delta introduces | `delta.likec4` |
+| `service.exists` | tagged element the delta draws as a service of ours: at top level or only inside groupings the delta declares (elements that stand for no service and contain one — any other level owns what is drawn inside it), and not a person, `#external`, unbound infrastructure or a grouping itself. The stub of a living element is read with the living element's tags, and the stub of a service that already has a `services/<id>/` is asked about only when tagged at top level | `delta.likec4` |
 | `api.exposes` | operationId the feature's openapi delta adds that the living one lacks | `specs/<svc>/openapi.yaml` |
 | `event.declares` | (direction, message) the feature's asyncapi delta declares that the living contract's send/receive sets lack — quotes and removals are never questions | `specs/<svc>/asyncapi.yaml` |
 | `c4.calls` | tagged edge carrying `metadata { op }` | `delta.likec4` |
@@ -1832,18 +3144,26 @@ nobody wrote must not carry over as if it still applied.
 anything that does not answer the *current* checklist, each under its own `--json` `error.code`:
 `answers-unreadable` (not JSON, or a verdict outside `confirmed` / `unconfirmed`),
 `answers-mismatch` (an id nobody asked about, a claim with no answer, or one answered twice),
-`answers-unevidenced` (a `confirmed` with no `file:line` behind it). An unchecked claim must never
-be able to masquerade as checked.
+`answers-unevidenced` (a `confirmed` with no `file:line` behind it, or one citing a file or a line
+that does not exist in the repository the record is written from — the all-at-once form included,
+which binds to no commit but no longer takes a citation on trust). The all-at-once form checks what
+is shaped like a citation and only that: an evidence entry that is one token ending in `:<digits>`
+and is not a URL must name a regular file inside the repository with that line, while prose ("manual
+QA by Alice"), a URL or a path with no line is recorded as it always was. The federated form keeps
+its stricter contract — every agent entry a `file:line` bound to the attested commit. An unchecked
+claim must never be able to masquerade as checked.
 
 **`--results <report.json>` answers the `scenario.tested` claims mechanically, from a cucumber JSON
-test report** — the format `cucumber-js --format json` emits, and cucumber-jvm, behave and SpecFlow
-speak too. The contract is exactly this and nothing more: a top-level array of features, each
+test report** — the format `cucumber-js --format json` emits, and cucumber-jvm, behave,
+SpecFlow/Reqnroll, pytest-bdd (`--cucumberjson`) and godog's cucumber formatter speak too. The contract is exactly this and nothing more: a top-level array of features, each
 `elements[]` (scenarios) with `name`, `tags[] {name}` and `steps[] {result {status}}` — plus the two
 places those dialects put a failure the steps never see: cucumber-jvm's per-element
 `before[]`/`after[]` hook results and behave's element-level `status`. Every other field is ignored,
 tagless elements (backgrounds, hand-written scenarios) are invisible, and a file that is not that
 array at all refuses under `answers-unreadable` rather than quietly answering every claim "not
-found".
+found". A file that is not JSON at all — a JUnit XML report is the usual one — refuses the same way,
+and the refusal names both shapes `--results` reads, because the second one exists for exactly that
+runner.
 
 Matching is by digest and nothing else: a claim is answered by the report scenarios carrying its
 `@loam-digest-<16hex>` tag — the tag `loam gherkin` stamped, the same 16 hex of the same body hash
@@ -1852,12 +3172,21 @@ name), so a business run can never answer an arch claim however identically the
 worded. Names never match anything: a reworded spec scenario matches nothing until the suite is
 regenerated and re-run — an agent must not be able to SAY a scenario is tested; only a green run
 may. The verdicts: every matching occurrence (a digest the report holds twice is a re-run, and all
-occurrences count) ran at least one step, every step `passed`, every before/after hook `passed`, and
-the element-level status (when the dialect carries one) is `passed` → `confirmed`, with evidence
+occurrences count) ran at least one step, every step `passed`, every before/after hook `passed`, the
+element-level status (when the dialect carries one) is `passed`, and **it ran exactly as many steps
+as the stamped scenario has** — the count `loam gherkin` emits for it, `And`/`But` included →
+`confirmed`, with evidence
 `<report-path>: <feature uri or name> › <scenario name>` per occurrence; a failed / undefined /
 pending / ambiguous step (`failed at step N`), a failing hook (`failed in a before/after hook`), a
 failed element status, a skipped-only run (`skipped`), or no match at all (`not found in report`) →
-`unconfirmed` with the reason as the note.
+`unconfirmed` with the reason as the note — and a run whose step count differs from the stamped
+scenario's is `unconfirmed` too (`ran N step(s) where the stamped scenario has M`). The digest is
+only a tag, and a tag is text: a one-step stub carrying the right digest used to confirm five-step
+scenarios, because nothing compared what ran with what was stamped. The count is what every dialect
+can be held to; the step TEXT is not compared, because an outline's steps reach the report with
+their placeholders filled in and dialects disagree about keyword spacing and localisation. The hook
+entries cucumber-js lists among `steps[]` (marked `hidden`, keyword `Before`/`After`) are read as
+hooks, never counted as steps — and a failing one still sinks the run.
 
 `--results` OWNS every `scenario.tested` claim **in the same run**: an answers-file entry for one is
 refused (`answers-mismatch` — the runner owns it), `--record` alongside must answer exactly the
@@ -1889,6 +3218,8 @@ own runner-neutral shape, chosen by its marker key:
 ```
 
 `digest` is the 16 lowercase hex of the `@loam-digest-…` tag `loam gherkin` stamped on the scenario.
+An entry carries no steps, so it is held to its `status` alone — the step-count check above is a
+property of the cucumber shape.
 `status` is `passed` or `failed` — nothing else. `test` is optional free text: the runner's own name
 for the run, used as the evidence string a reader follows. `loamScenarioReport: 1` is the format
 version this loam reads; any other value refuses rather than being partly understood.
@@ -1914,12 +3245,18 @@ carrying the marker is always graded as this shape, even when malformed: falling
 cucumber parser would tell an author their report is not a cucumber array, which is true, useless,
 and hides the real mistake.
 
-**Two services wording a scenario identically share one digest**, and a single report then cannot
-say whose suite ran it. Those claims are left `unconfirmed` with `verify.digest-contested` (warn)
-naming both services and the affected claim ids, rather than confirming both from one run. Record
-each service's claims from its own repository with `--service`, which narrows the checklist before
-matching. Scenario digests are salted by *axis* (business versus arch) but **not** by service, so a
-digest identifies scenario words; `--service` is what gives a report an owner.
+**Scenario digests are salted by both the owning service and the axis** (business versus arch), so
+two services wording a scenario identically do not share one: the hash folds in the service the
+claim is filed under. The service salt is what makes ordinary repeated wording CORRECT rather than
+merely refused — "the service returns 404 for an unknown id" is a sentence a fleet writes many
+times, and before the salt those scenarios shared a digest, so one repository's green run could
+appear to confirm claims from suites that never ran each other's tests, and the only defence was to
+decline to answer. `verify.digest-contested` (warn) survives as the guard on that invariant rather
+than as a diagnosis of ordinary authoring: if a digest is ever claimed by two services it is a
+truncated-hash collision, a single report still cannot say whose suite ran it, and those claims are
+left `unconfirmed` naming both services and the affected claim ids rather than confirmed from one
+run. Record each service's claims from its own repository with `--service`, which narrows the
+checklist before matching.
 
 ### Contract-test reports answer the `api.exposes` claims
 
@@ -2013,7 +3350,7 @@ service's as a pure lens — no repository binding, usable from the docs repo, r
 `unknown-service` when the checklist has no claims owned by that id — and both agents must have
 answered the same scope. Combining the flag with `--record`, `--results` or `--contract-results`
 refuses `invalid-option`, as does any arity other than exactly two files and an archived feature
-(frozen history has no current checklist to answer). A `verification.yaml` too damaged to read does
+(frozen history has no current checklist to answer). A verification record too damaged to read does
 **not** block the diff — the lens never reads the record, and the moment a cross-examination is most
 needed is before re-recording over a broken one.
 
@@ -2033,7 +3370,7 @@ block pins each file's path and the sha256 of the exact bytes read.
 confirmed/unconfirmed/unanswered. The payload also deliberately carries **no `verified`, `verdict`
 or `attested` key at all**: two answer sets agreeing — usually two contexts of the same model, so
 correlated — ranks where a reviewer reads first; it is not verification, it upgrades nothing, and it
-leaves `verification.yaml` byte-identical (no docs lock is taken, and the diff runs while a writer
+leaves the verification record byte-identical (no docs lock is taken, and the diff runs while a writer
 holds one).
 
 ### Attested is not verified
@@ -2068,28 +3405,79 @@ the decision:
 So "a green run is the only thing that confirms a scenario" is a claim about the **record**, not
 about the CLI's flags: the short path still works, and it is legible afterwards as the short path.
 
-### The record is federated: one file, one attestation per service
+### The record is federated: one attestation per service, one file each
 
 A cross-service feature's claims belong to several services, and each service's code lives in its
 own repository — so no single place can honestly answer all of them.
 `loam verify <FEAT> --service <id> --record answers.json`, run **in that service's own repo**,
 narrows the checklist to that service's claims and binds the answers to this repository's commit.
-The result is one `schema: 2` `verification.yaml` holding a list of **`attestations`**, one per
-service: the service id, the commit the answers were bound to, and that service's answered claims.
-
-The merge semantics are additive and non-destructive. Recording for service B keeps service A's
-attestation exactly as it stood — the new record is the old attestations minus B's previous one,
-plus B's new one. Answers the new record does *not* carry are reported in `discarded`, tagged
-`unattested` (a schema-1 answer, or one whose attestation is gone) or `off-checklist` (a claim the
-current checklist no longer asks). Nothing is dropped silently.
-
-The write behind that merge holds the same advisory lock archive does, and holds it from before the
-feature is resolved to after the record lands — two `--record` runs for different services serialize
-(the later one waits briefly, then merges over what the first left, so **both** attestations
-survive), and a record can no longer be written into a path an `archive` is renaming out from under
-it. The commit itself is staged beside the target and swapped in by one rename over the exact bytes
-the merge was computed from, so a kill mid-record leaves the previous record whole — never truncated
-YAML — and an edit that landed in between refuses instead of being buried:
+The result is that service's **attestation**, written to a file of its own:
+`features/<FEAT>/verification/<id>.yaml` — a `schema: 2` record holding exactly that service's
+attestation (the service id, the commit the answers were bound to, the checklist digest it answered,
+and its answered claims) and nothing of anybody else's. **The directory is the record**, the rule
+`glossary/` and `capabilities/` already follow: loam reads every file in it and adds them up, and
+the verdict and the counts are computed from the union at read time — exactly as they always were,
+since nothing ever trusted a stored `summary`. Each file's own `summary` counts the whole checklist,
+with the claims other services own honestly `unanswered` in it.
+
+**Why one file per service.** The record used to be ONE `verification.yaml` for every service, and
+every attestation rewrote its `summary`, its `recorded` date and its checklist-ordered `claims`. Two
+teams recording two different services on two docs-repo branches therefore always conflicted when
+the PRs merged — add/add from an empty start, content conflicts on the summary, the claims and the
+attestations once one had landed — and sorting the attestations did not help, because two
+insertions at one anchor are a conflict whatever the order. The advisory lock below serializes
+writers on one checkout only; a fleet records from many. With a file per service, two teams' records
+touch two different paths and merge cleanly. Recording a service again replaces that service's file
+and nothing else; another service's file is never rewritten, and its pins never touched.
+
+The record answers **one version of the checklist**: the one the feature asks now — `loam verify`
+(read and record alike), `tasks`, and `status`, `list` and `gate` for an in-flight feature all
+derive it, and the files that answered it are the ones that count. Only where no reader knows the
+current version (the frozen view of an archived feature) or no file answered it does the newest
+file decide (by `recorded`, a later service id breaking a same-day tie). Newest-by-date used to
+decide always, and `recorded` is a date: a service that recorded the current checklist lost a
+same-day tie to a service with a later id that had recorded an older one, so the current answers
+were dropped and every reader called the record stale. A file that answered a different version
+keeps its attestation in the list — `verify.checklist-forked` names it, on the recording run's
+output as well as the read view — but its answers do not count until that service records again.
+The one shared file used to settle this by rewriting: the last writer pruned everybody's answers to
+its own checklist. Per-service files are never rewritten by anyone else, so nothing can prune them,
+and counting an answer filed against another question set would let an id the feature no longer
+asks fill the slot of the question that replaced it.
+
+**`features/<FEAT>/verification/` is loam's.** Every non-dot `*.yaml` in it is read as one
+service's attestation file — the file name is the claim about whose word it holds — so a file there
+that is not one (a hand-made `k6.yaml`, say) makes the record `record-unreadable`, exactly like a
+damaged attestation. Keep anything else beside the feature, not inside that directory.
+
+**The one-file record is read forever.** A `verification.yaml` written before the directory existed
+— a federated record with several attestations in it, active or archived — reads exactly as it
+always did while no service has a file of its own. Once services do, it is read beside them: a
+service that records again supersedes its share of the one-file record (that attestation and its
+answers drop out of the union; the file itself is not rewritten), and the write that leaves nothing
+in it counting removes it. An all-at-once record (no `schema`, no attestations) never counts once a
+service has a file — its answers carry no commit attestation — so the first `--service` write
+removes it in the same commit and lists its answers in `discarded`. Answers a write takes off the
+disk that its new file does not carry are reported in `discarded`, tagged `unattested` (an
+all-at-once answer) or `off-checklist` (a claim the current checklist no longer asks). Nothing is
+dropped silently.
+
+**The all-at-once form keeps the one file, by decision.** `--record` without `--service` answers the
+whole checklist from one place on one word, with no commit and no service — so there is no second
+writer for it to collide with and no service to name a file after, and every record it ever wrote
+(the example fleet's included) stays byte-for-byte what it is. There is one reader either way:
+`loam verify`, `status`, `list`, `tasks`, `gate` and `validate` all read the record through the same
+union, whichever files it is made of.
+
+The write holds the same advisory lock archive does, and holds it from before the feature is
+resolved to after the record lands — two `--record` runs for different services serialize (the
+later one waits briefly, then writes its own file, so **both** attestations survive), and a record
+can no longer be written into a path an `archive` is renaming out from under it. The commit itself
+is staged beside the target and swapped in by one rename over the exact bytes the read found, so a
+kill mid-record leaves the previous record whole — never truncated YAML — and an edit that landed in
+between refuses instead of being buried. A write that also removes a superseded one-file record
+holds that removal to the same compare, and lands the service's own file first, so a kill between
+the two leaves a record that still reads whole:
 
 - `docs-busy` — another writer held the lock longer than the record was willing to wait (5 s).
   Nothing was read or written; re-run once it finishes. The contention runs both ways: `archive`,
@@ -2110,9 +3498,10 @@ Recording refuses rather than guesses, each under its own `--json` `error.code`:
 - `repository-unavailable` — `--service` from a repo that declares none, or one whose commit cannot
   be read. An attestation with nothing to bind to is not an attestation.
 - **`record-federated`** — the legacy all-at-once form (`--record` with **no** `--service`) over a
-  record that already carries attestations. That form writes the whole file from one place, so it
-  would erase every other repository's evidence; loam refuses outright and names the attestors, and
-  never silently migrates or merges. Re-run with `--service`.
+  record that already carries attestations, in per-service files or in a one-file record. That form
+  writes the whole record from one place, so it would put one unattested answer set over every
+  other repository's evidence; loam refuses outright and names the attestors, and never silently
+  migrates or merges. Re-run with `--service`.
 - `record-unreadable` — see below.
 
 Reading is unrestricted: `loam verify <FEAT> --service <id>` **without** `--record` is a pure lens
@@ -2121,12 +3510,26 @@ in `services`, which is how you find out which repositories still owe an attesta
 
 The record is YAML, like the other data artifacts, and holds the claim text next to each verdict so
 it reads without loam. Because it has to survive without loam, human edits are expected — and read
-back defensively. A file that exists but does not read as a record (broken YAML, or a shape missing
+back defensively. A record file that exists but does not read as a record (git conflict markers a
+merge left in it — named before the YAML parser sees them, since the parser either fails on a line
+that is not the problem or reads both sides as one plausible document; broken YAML; a shape missing
 what the readers use — `summary` with its counts, `recorded`, `checklist`, claims each with an `id`
-and a known `verdict`) is **`record-unreadable`**: reported with the YAML line, and **never
+and a known `verdict`; or a `verification/<svc>.yaml` holding anything but that one service's
+attestation and answers) is **`record-unreadable`**: reported with the file and the line, and **never
 overwritten**. It used to count as *no record at all*, which was the wrong direction on the one
 artifact loam cannot reconstruct — "no record" invites writing a fresh one over evidence somebody's
-edit merely broke. Only a genuinely absent file is "no verification record". Extra keys a human adds
+edit merely broke. Only a genuinely absent file is "no verification record".
+
+The refusal names the ONE file that failed and the repair that is safe for it, because the two kinds
+of file call for opposite advice. A service's own `verification/<svc>.yaml` holds that service's
+word and nobody else's — after a merge, both sides of a conflict in it are that service's own
+attestations — so repairing it by hand, or deleting it and recording that service again from its
+repository, loses no other team's evidence. The one-file `verification.yaml` may hold every other
+service's attestation, so its advice is to repair it or **restore it from version control** (after a
+merge, the copy on the branch you merged into) and then record again — **never to delete it**. The
+old one-size advice, "delete it and record again", erased other teams' attestations when followed on
+a shared record, and the miscount advice, "record the answers again", sent the reader straight back
+into this refusal: `--record` will not write over a file it could not read. Both now end in a record. Extra keys a human adds
 still pass through untouched. Every verdict names who answered it — `answered_by: runner` (a
 cucumber report's green run, mechanical), `answered_by: external-runner` (a contract-test report's
 operationId-matched green entry, mechanical too), or `answered_by: agent` (somebody's word about the
@@ -2196,7 +3599,7 @@ next `--record` makes it drift-checkable), warn `evidence.unresolved` (the cited
 unsafe, not a regular file, or the cited line is past its end), `evidence.moved` (the file's digest
 differs while the cited line still reads as pinned), `evidence.line-changed` (the cited line no
 longer says what was recorded), `evidence.token-missing` (the file contained the token at the
-attested commit and no longer does) and `evidence.record-unreadable` (a verification.yaml that
+attested commit and no longer does) and `evidence.record-unreadable` (a verification record file that
 exists but cannot be read — none of its evidence was checked, and a silent skip would read as clean,
 on the very file a hand edit to the pins most plausibly breaks). Archived records are deliberately
 not linted — frozen history, and post-ship code drift is normal evolution. From the docs repo the
@@ -2206,13 +3609,18 @@ verdict in either direction, `attested` never silently becomes `verified`, and t
 fail `validate`; `--strict` remains the CI lever it always was.
 
 It lives inside the feature, so `archive` carries it into `features/archive/<FEAT>/` with everything
-else. `loam verify` re-run later compares `checklist` against the current digest and reports the
+else — the `verification/` directory moves with the feature it sits in, and `unarchive` brings it
+back the same way; the frozen view reads it through the same union. `loam verify` re-run later compares `checklist` against the current digest and reports the
 record as **stale** if the feature moved under it — while the feature is active. Once archived there
 is no current checklist to be stale against (the merge itself moved the feature's operations into
 the living OpenAPI, so a re-derived checklist could only disagree): `loam verify` on an archived
 feature renders the record verbatim as **frozen history** (`frozen: true` under `--json`, no
 staleness judgment), and `--record` refuses (`invalid-option` — there is no current checklist for
-the answers to answer): the record is about the words that shipped, and it stays that way.
+the answers to answer): the record is about the words that shipped, and it stays that way. One
+reader holds it to something all the same: `loam gate --since <ref>` grades an archived record
+against the checklist digest `archive` captured as the feature merged (the snapshot manifest's
+`checklist`, above), because the deploy question is whether what shipped was what was checked — a
+record that had gone stale before the archive is `stale` there, never `verified` again.
 
 **Verification does not gate `archive`.** Coherence gates because loam computed it from the
 documents; a verdict is an agent's word about code loam never read, and a gate in front of shipping
@@ -2221,6 +3629,76 @@ comes later, and an `unconfirmed` claim with a note is worth more there than a `
 can back up. `loam verify` exits 0 either way; branch on `verified` in the `--json` payload, or on
 `verdict` when you need to tell `attested` from `unverified`.
 
+### The same checklist read forwards (`loam tasks`)
+
+`loam verify` answers *answered, and by whom*. `loam tasks <FEAT> [--service <id>] [--next]
+[--json]` answers the other half of the same question — *still open, at which step, and what fact
+closes it* — and it is the identical checklist read in the other direction. It is derived on every
+run from the feature's deltas, the generated suite and the verification record; it writes nothing,
+anywhere, ever, and it adds no artifact for a later run to disagree with.
+
+**One unit per promise, and a unit's id is the claim's id.** Every claim the checklist derives is
+one work unit, under the same identity on both commands, so the thing to do and the answer that
+closes it can never be two different objects. One kind of unit has no claim behind it: an ADDED or
+MODIFIED requirement with no scenario under it asks the checklist nothing — there is no scenario to
+test — so `loam tasks` mints a unit of its own for it, of the kind requirement.described. That is
+the promise nobody has written acceptance criteria for yet, and it is where the loop starts.
+
+**Where a unit stands** is its `at` field, and the four values are the steps of the loop this
+document already describes rather than a percentage: `describe` (the requirement carries no scenario
+at all, so there is nothing to generate a test from), `generate` (the scenario exists and this
+repository's generated suite does not carry its stamp yet), `implement` (everything else still
+open), `attested` (an agent's word confirmed the claim and no run has). It is spelled `at`
+deliberately, and not `stage` or `verdict`: both of those already mean something else on payloads an
+agent reads beside this one, and a third meaning for either word is how a consumer comes to branch
+on the wrong field.
+
+**Done is a fact, not a tick.** A closed unit simply stops appearing, and exactly one thing closes
+one: a claim recorded `confirmed` in a verification record that is **not stale** against the current
+checklist. A stale record closes nothing — the words moved under the answers, which is the state
+`loam verify` already reports. An agent-attested scenario never vanishes either: it stays visible at
+`attested`, because attested is not verified, and a work list that hid the difference would be
+exactly the gate that teaches everyone the cheapest way past it is to say yes.
+
+**The frontier** is the first ten open units in derived order, providers before consumers — ordered
+on the exact token join `c4.calls.token == api.exposes.operation`, never on a reading of prose.
+**The order is advice and never a lock**: nothing is assigned, nothing is reserved, and working out
+of order is legal and invisible to every other command.
+
+**`--next` is the leaf**: the same packet with `units` narrowed to the frontier head, which is what
+an orchestrator hands a coding agent. Everything else — the counts, the frontier, the review
+notes — is left whole on purpose, so a cheap model handed one unit cannot read it as the whole job.
+The text view prints that leaf in full: the scenario's body verbatim and never reflowed (the bytes
+the digest was taken over), the digest itself — the same `@loam-digest-<16hex>` join key
+`loam gherkin` stamps and `loam verify --results` matches on — the `done` block whose `check` is the
+fact that closes the unit, and the literal follow-up command to run next, spelled out rather than
+left as a shape to fill in.
+
+**`--service <id>` is a pure lens.** It narrows the units to one service's without binding a
+repository, and adds `waitingOn[]`: the open units in OTHER services that this service's units
+depend on. A team learns what it is blocked by from the same run that tells it what to do. In a
+service repository (`loam.json` names a `service`) the lens defaults to that service when the
+feature touches it, because the generated-suite stamps that tell `generate` from `implement` are
+read from that repository alone; the docs repo, and a feature that does not touch the bound
+service, get the whole feature.
+
+**What the payload says about what it could not see.** `stamps` is `read` or `unknown`, and
+`unknown` means the bound service repo's generated suite could not be read — could-not-look, never
+nothing-wrong, because a question loam was unable to ask must not read as one that came back clean.
+Beside it the payload carries `checklist` (the digest of the question set these units derive from),
+`record` (`absent`, `recorded`, `stale` or `unreadable`), `intent`, `services[]`,
+`size{requirements,scenarios,operations,messages,calls}` — the size of the DELTA and never of the
+open work, so that "this feature is small" and "this feature is nearly done" cannot become one
+sentence — `contracts{expose[],call[]}`, `counts{open,done,attested}` and `review[]`, the four
+instructions for re-deriving this answer and reviewing it, because a projection that says what to do
+must also say how to check it was read correctly. A broken `delta.likec4` or contract axis names
+what it could not read in `unreadable` and exits 1 with `ok: true` — `loam delta`'s own rule rather
+than a new one: a feeder nothing could read empties the packet, an empty packet reads as "nothing to
+do", so the envelope stays true while the exit code stops a pipeline building on it.
+
+The command mints no finding or refusal code of its own, and `loam_tasks` serves the same projection
+read-only over MCP.
+
 ## Operating at fleet scale
 
 One docs repo, a hundred services, many teams. The repo scales the way any shared codebase does —
@@ -2263,14 +3741,28 @@ through the forge, not through loam features:
   **parsed** model and never computes a view — it reads what a view **declares** (a `dynamic view`'s
   tags and ordered steps, already materialized by the parse loam pays for) and never what a view
   **shows**. It renders nothing, and view *computation* is what is superlinear in edges. (If you
-  want diagrams, add a `views` block and render it with LikeC4's own tooling — `npx likec4 start` in
-  the docs repo for the fleet map, `npx likec4 start services/<id>` for one service model — and
-  scope the views, because an `include *` over a fleet-sized landscape takes minutes. `loam init`
+  want diagrams, add a `views` block and render it with LikeC4's own tooling — `npx likec4 start`
+  at the docs root, which renders the fleet map AND every adopted service's model: an extending
+  model is part of the root `fleet` project, beside the map, and a standalone one is the project its
+  own `services/<svc>/likec4.config.json` declares (written by `loam subsystem sync`; the Layout
+  section, "Two shapes of a service model", has the rule), and `npx likec4 start features/<FEAT>`
+  for a delta, which is
+  transient and gets no project — and scope the views, because an `include *` over a fleet-sized
+  landscape takes minutes. Two costs arrive with the first STANDALONE service project, and only
+  with it. Measured at the
+  pinned likec4: with more than one project, `likec4 validate` at the docs root refuses without
+  `--project <name>`, so a CI step that ran it bare changes (`likec4 build` and `likec4 export` take
+  every project and need no flag). And the renderer's project list grows by one per such service
+  beside `fleet` — LikeC4 projects are separate models, so a box on the fleet map is not a link into
+  that service's project. A fleet whose models all extend the map pays neither: one project, one
+  picker entry, and the containers of every adopted service reachable from the map's own boxes.
+  `loam init`
   scaffolds the landscape with no `views` block for that reason: loam should not plant a diagram it
   never draws **— and never asks for one: a fleet that draws nothing owes no views block.** It also
-  scaffolds a `likec4.config.json` that scopes the root LikeC4 project to `architecture/`: loam
-  parses every `.likec4` file **alone**, so each one declares its own `specification` block, and a
-  renderer given the whole tree at once merges them and reports every declaration as a duplicate.)
+  scaffolds a `likec4.config.json` whose `exclude` is `["**/node_modules/**", "features/**"]`: a
+  feature's `delta.likec4` re-declares the landscape's own identifiers and carries a `specification`
+  block of its own, so it is read alone, and `services/` is deliberately NOT excluded — the models a
+  fresh repository writes extend the map and the root project is the only place they parse.)
   `loam validate --all --json` over the same 120 services used to be the outlier at ~13–14 s — one
   fresh LikeC4 workspace per service; since the batched loader it parses the run's C4 documents in
   one shared workspace and answers in **~0.7 s median** on the committed 120-service benchmark
@@ -2308,8 +3800,15 @@ repairing anything:
   `needs` and (for authored files) the grading command in `after`. It is a **projection over the gates, never
   a second opinion**: `stage` is taken from the union of what `validate --feature` errors on and
   what `archive` refuses to merge (severity *or* `gates`), so status may be more pessimistic than
-  either and is never greener than both — an invariant with a test behind it. The fleet form is
-  capped at ten substantive steps plus a `next.elided` notice saying how many were left out, and
+  either and is never greener than both — an invariant with a test behind it. The stage values are
+  for branching, not progress words: `ready` means the documents are written and clean, nothing
+  about code or evidence, and an archived feature is `done` whatever its record says — so the human
+  view prints the stage as a sentence with the claims counted, and the payload carries
+  `feature.title` (intent.md's title) and `checklist.claims` (what the checklist asks now; null once
+  archived). The fleet form lists every feature in flight before any service's adoption rung — and
+  carries every rung uncapped in `serviceSteps[]` (`{code, services, command}` per code), which the
+  human view folds into one counted line per code. It is
+  capped at ten substantive steps plus a `next.elided` notice saying how many of which codes were left out, and
   whenever anything is outstanding its **last** entry is `next.fleet-gate` →
   `loam validate --all --json` (a repository with work in it must never get a list that omits the
   command CI runs; a fleet whose services exist and owe nothing says so instead, with
@@ -2358,11 +3857,14 @@ repairing anything:
 
   And it reports the **agent surface**: which tool and profile the repo is wired for, how many command and skill
   files it holds, how many a newer loam would lay down (`doctor.agent-files-missing`), and how many
-  have fallen behind (`doctor.agent-files-stale`). The staleness check reads exactly one thing — the
-  `<!-- generated by loam vX.Y.Z -->` line every generated body opens with — and nothing else.
+  have fallen behind (`doctor.agent-files-stale`). A file has fallen behind when BOTH hold: its
+  bytes, the `<!-- generated by loam vX.Y.Z -->` line every generated body opens with set aside, are
+  not what this binary writes; and that stamp is missing or older than this binary. A stamp-only
+  difference is not staleness — the stamp moves in every file at every release, and a warning that
+  fires on every upgrade hides the release where a pointer's body really changed. A customized body
+  under a current stamp is not staleness either: the stamp is the record that somebody reviewed it.
   The digest manifest is what authorizes `init` to refresh an unchanged pointer; a different body is
-  treated as human-owned and never overwritten. A stamp is a separate claim and can be stale while
-  every edit around it is legitimate. Which deliveries a repo holds is asked of the files rather
+  treated as human-owned and never overwritten. Which deliveries a repo holds is asked of the files rather
   than of a record: `loam.json` stores tools and profile, not deliveries, and a repo initialized
   `--no-skills` is not reported as missing the selected skills.
 
@@ -2376,7 +3878,28 @@ repairing anything:
 
   `loam-report` is a separate support protocol, generated as a command and skill in every profile
   but never appended to the lifecycle. It writes
-  `loam-reports/YYYY-MM-DD-<short-slug>.md` in the current repository with expected/actual behavior,
+  `loam-reports/NNN-YYYY-MM-DD-<short-slug>.md` — `NNN` an ORDINAL of at least three digits,
+  zero-padded, one more
+  than the highest already in the directory (`001` when it is empty or absent, and widening past
+  three digits rather than reusing a number once a corpus gets there), so a report has a
+  short handle a commit message, an issue or the next report can cite. The document carries a
+  `- Status: open` line beside its classification, whose vocabulary is `open` / `sent` (handed to
+  the author, set by whoever forwards it) / `fixed in <version>` / `superseded by <NNN>`, and
+  `loam doctor` reads the directory: how many reports it holds, how many stand at each status, and
+  which ordinal comes next. `doctor --json` carries that as the `reports` object — `reports.dir`
+  (the ABSOLUTE path of the directory, `loam-reports/` included, so an agent writes inside it rather
+  than joining the name on a second time), resolved beside the `loam.json` that parsed, or beside
+  the one loam FOUND when it did not parse, and only beside the run directory when there is no
+  config file at or above it — `doctor` is the preflight that runs precisely when the config may not
+  resolve, so it counts the corpus that is there rather than handing out an ordinal five existing
+  reports already used — `reports.present`, `reports.total`, `reports.next`, and
+  `reports.entries[]` with a `file`, an `ordinal` (`null` for a name written before the numbering)
+  and a `status`, in ordinal order, numerically, with unnumbered names last (byte order stopped
+  being report order at exactly the width the ordinal widens to: `1000-…` sorts before `998-…`). The status is read from the report's HEADER FIELD BLOCK alone — the lines above
+  the first `##` heading, quoted code skipped in both markdown spellings (a fence, closed only by a
+  run of the same character at least as long as the one that opened it, and an indented block,
+  which is how the protocol prints its own template) — so a report quoting this protocol's own
+  template still counts as whatever its own header says. The body carries expected/actual behavior,
   version, stable envelope and finding codes, relevant locations, write state, a minimal safe
   reproduction, classification and missing evidence. Before writing, the agent redacts secrets and
   home paths and reduces command output to the excerpt that proves the symptom. It never retries a
@@ -2444,6 +3967,7 @@ and publishes it wherever the fleet view reads:
   "errors": 0,
   "warnings": 2,
   "sources": { "current": 1, "stale": 0, "unvouched": 0, "absent": 0 },
+  "contentStale": 0,
   "generatedAt": "2026-08-03T12:00:00Z"
 }
 ```
@@ -2462,10 +3986,16 @@ loam validate --service "$SVC" --json | jq '{
     unvouched: [.targets[0].findings[] | select(.code == "sources.unvouched")] | length,
     absent:    [.targets[0].findings[] | select(.code == "sources.absent")]    | length
   },
+  contentStale: [.targets[0].findings[] | select(.code == "content.stale")] | length,
   generatedAt: (now | todate)
 }'
 ```
 
+`contentStale` counts the spec documents whose words moved after their vouch — the doc-side half of
+staleness, beside the code-side `sources.stale`. Unlike that half it is not owed to the service repo
+alone (the docs repo's own `validate --all` scorecard counts it too), but a summary that left it out
+would publish "0 stale" over a document nobody re-read.
+
 `generatedAt` is the CI's clock, never loam's — loam output carries no timestamps, by design, so the
 same repo state always yields the same bytes. That is also what makes the timestamp the liveness
 signal: the rule is that every service repo's CI publishes this summary on every run, so a summary
@@ -2485,20 +4015,44 @@ hand-merges the block. That resolution has a documented cost, not a surprise: a
 landscape moves the file away from the bytes the archive's `.loam-before/` snapshot recorded, so a
 later `loam unarchive` of that feature refuses with `snapshot-stale` and needs `--force` — the
 resolver is trading undo precision for the merge, and should know it. The trigger for revisiting is
-written down so nobody relitigates it early: when landscape merge conflicts become routine — weekly,
-not monthly — move per-service internals fully into `services/<svc>/model.likec4` and thin the
-landscape down to top-level elements plus cross-service edges. Until then, one file keeps the fleet
-map one diffable document.
+written down so nobody relitigates it early — and half of what it once asked for has already
+arrived. Per-service internals now live in `services/<svc>/model.likec4` **by default**, and that is
+where a second team adopting a service writes, so it adds nothing to this file. It is a default and
+not a prohibition: the map MAY hold a service's interior, and sometimes must. A store a second
+service will reach has to be declared where that consumer's project can see it — a per-service
+project is `architecture/` plus one model — so it is drawn ON THE MAP, nested inside the owner's
+element or beside the services, whichever the team prefers. Which of the two is nobody's business
+but the team's: "Private stores" above leaves the placement open and loam grades neither, so nothing
+here says a store must move. A delta spelling a parent in the legacy
+title-join lands its container on the map too. What an extending model owns is what it DECLARES,
+not everything below the service's element. `loam archive` routes rather than forbids — a delta's
+additions nested under a service whose model extends the map, with the whole parent chain spelled
+in the map's own ids, are spliced into that model's `extend <fqn> { … }` block instead of this
+file, and the merged model is proved to parse beside the merged map before anything is written. What is left of the
+trigger is the CROSS-SERVICE EDGE, which still exists twice — container-level in the model, service
+level here — because the spine, the platform census and every other fleet check read this file
+alone. So: when landscape merge conflicts become routine — weekly, not monthly — thin the map to
+elements plus cross-service edges and teach the fleet checks to read the edges out of the models
+that attest them. Until then, one file keeps the fleet map one diffable document, and
+`landscape.service-isolated` remains the nudge that carries an attested call up into it.
 
 ## Two flows
 
 - **Bootstrap (reverse):** `loam adopt --service <id>` emits a **brief**, not an extraction — the
   target paths (and which already exist, to be diffed and never overwritten), the grammar of each
-  artifact, what the living landscape already says about the service, the frontmatter to write, the
+  artifact, what the living fleet map — the `architecture/` project, not the landscape file alone —
+  already says about the service, the frontmatter to write, the
   checks `loam validate --service <id>` will then run, and the ones that do not exist. One target is
   not under `services/<id>/`: `architecture/landscape.likec4`, carried with `action: "edit"` and a
-  `landscape.instruction` naming the block this service owes the fleet map, and present only while
-  nothing in the map resolves to the service. An agent reads the code and writes draft
+  `landscape.instruction` naming the write this service owes the fleet map — the element while
+  nothing in the map resolves to the service, the EDGES while an element does and no edge touches it
+  (`landscape.touched: false`, with `landscape.attested` listing the calls the service's own
+  model.likec4 declares across its boundary); absent, and the instruction `null`, only once an
+  element resolves and an edge touches it. `landscape.callersKnown` says whether loam could read WHO
+  CALLS this service — true when the `architecture/` project parses, and true when it does not but
+  `architecture/landscape.likec4` does. It is what an empty `landscape.expects` has to be read
+  against: only a readable landscape makes "nothing calls this service" evidence, and it is the one
+  fact `openapi.yaml`'s `required` is derived from. An agent reads the code and writes draft
   `model.likec4` + `spec.md` + `openapi.yaml` + `adrs/`, `runbook.md`, `health.yaml`, and makes that
   one addition to the shared map. A human promotes `draft` -> `verified` with `loam vouch`.
 - **Forward (generative):** author `features/<FEAT>/delta.likec4` -> `loam delta <FEAT>` projects it
@@ -2511,7 +4065,7 @@ says what its architecture means, and two generated models of the same code disa
 every run — a done-check built on diffing them would flap until somebody turned it off. What is
 deterministic is the **question**: which files, in which grammar, bound to which existing elements;
 which operations, which edges, which scenarios. loam owns the questions and the checking; an agent
-owns the reading. `sources` and `verification.yaml` are where the answers are written down.
+owns the reading. `sources` and the verification record are where the answers are written down.
 
 ## Status
 
@@ -2524,9 +4078,9 @@ component-surface pins), `verify`,
 transactional `archive` / `unarchive`, `vouch`, and the OpenSpec audit/migration on-ramp are
 implemented, each with a `--json` contract.
 
-Known and unclosed, so nobody has to discover them: the complete gate still needs repeatable CI and
-installed-package evidence observed from an actual push, even though behavior, coverage and the
-local stress runner pass. Both contract axes now merge a components-only delta: a feature
+Known and unclosed, so nobody has to discover them: the scheduled CI `stability` job has still to be
+observed green, even though behavior, coverage, the installed-package smoke and the local stress
+runner all pass. Both contract axes now merge a components-only delta: a feature
 asyncapi.yaml declaring no channel/operation/message slot (`components.schemas`-only, say) merges
 the component surfaces it declares, pinned by the root `x-loam-baselines` record, and they enter the
 ref sweep like anything else the merge wrote — so a `$ref` whose target the delta itself defines