A hosted Project offers two places to put an advisor contract: an always-applied Instructions field with a hard character limit (~8,000 on the current host), and mounted Sources. Putting the operative protocol in the Instructions field creates two failures that compound.

Two mutable carriers. Protocol in the field and a mounted retrieval map means one conceptual change requires two manual installations per Project. Half-updated deployments are then possible, and likely.

A carrier that cannot grow. The field has a ceiling. Once it is reached, adding protocol requires removing protocol — a preservation judgment made under space pressure, at the moment of least attention, with no record of what was dropped.

The second failure is the serious one, and it is not hypothetical. See docs/advisor-surface-compression-loss.md for the audited record: on the ASK deployments, eight semantic requirements were no longer fully carried — four wholly absent, four surviving only in weakened form — and four further requirements existed in this repo's template but were never propagated into any deployment. Surfaces instantiated after the compression inherited its gaps as birth defects rather than losing anything themselves.

Project Instructions field   thin, stable, always applied
      │                      the pre-retrieval floor — what must bind before any fetch, including when
      │                      every fetch fails
      ▼
mounted bootstrap            one standing Markdown Source, no Instructions-field ceiling
      │                      the full advisor contract + the exact live index locator
      ▼
live-fetched index           the retrieval map; NOT mounted in healthy connector mode
      │
      ▼
canonicals                   grounding note · repo truth · protocol owners · ledger · review objects

One standing mount. The bootstrap is the only Markdown Source a healthy connector-mode Project mounts. The index is fetched at the exact locator the bootstrap declares. Canonicals are fetched at the exact locators the index declares.

One self-contained bootstrap per surface, generated from one template plus that surface's overlay parameters. Do not mount a shared core plus a separate overlay: two mounts is another synchronization seam, and it makes connector-failure behavior harder to reason about. Share at the authoring layer; be self-contained at the runtime layer.

Maintenance consequence. An ordinary protocol change updates one bootstrap and remounts it. An ordinary index change updates a canonical and remounts nothing. The Instructions field is repasted only when the invocation architecture itself changes.

Each requirement has one authoritative owner and one or more explicitly declared deployment homes. A requirement may be co-homed — most often PI-FLOOR and BOOTSTRAP, where the floor states the minimal form that must survive a retrieval failure and the bootstrap states the operative form. A generated bootstrap is self-contained: it repeats the role and authority boundary rather than deferring to the Instructions field. The registry must describe what each carrier actually says.

PROJECT-CONFIG is the one home that governs the container rather than the contract. Its contents never enter the paste fence, are never mounted, and earn no Instructions repaste or bootstrap remount — a configuration record changing does not change what the surface was told. It is a semantic home rather than a named file: each hosted-Project variant records the same required fields in its own operator configuration carrier — see §HOST.

The PI floor is deliberately small. It is not a summary of the bootstrap — it is the subset whose absence would make a connector outage into an authority outage.

A requirement may leave a carrier only with a recorded disposition. One of:

MOVED           the exact surviving carrier, named, plus the requirement ID
REVISED         the replacement requirement ID and the reason
RETIRED         the architectural reason and the approval basis
NOT-APPLICABLE  the surface and the reason

Therefore: DROP-AS-DUPLICATE without an exact named surviving carrier is not deduplication — it is deletion. This single rule is what the earlier compressions lacked, and applying it would have prevented both the original loss and its propagation into surfaces instantiated later.

A requirement is unowned if no carrier holds it and no disposition retired it. Unowned count must be zero.

The bootstrap is not held to the Instructions field's ceiling, which creates the opposite risk: an ever-growing banner turning the entry point into front-door noise. Split the lineage by aging rate.

live bootstrap        current version · Supersedes · current Why-vN summary only
review object / PR    complete ADDED · REVISED · REMOVED-with-surviving-carrier for that revision
_vN snapshot          the exact historical bytes

Every bootstrap revision produces a semantic coverage delta in its review record. Prior deltas stay in snapshots and review history; they are never concatenated into the live entry point.

This document is the owner. Owning a rule does not bind anyone to it — a consumer is bound only by a carrier it actually resolves. The binding carrier is the advisor-project-surface profile (protocol/profiles/advisor-project-surface.md, registered in protocol/manifest.json as advisor-project-surface-deployment).

owner        docs/advisor-project-surface-architecture.md   registry · placement · tests · gate
carrier      protocol/profiles/advisor-project-surface.md   compact distributable obligation
applies_to   control-surface · asset-pipeline-ASK · urban-observatory · food-science-engine
live binding each repo is bound only when its AGENTS.md resolves the profile;
             installed state is recorded in the operator ledger
generated    templates/advisor-project-{bootstrap,instructions}.template.md · _INDEX-project.template.md

The profile carries the deployment shape — bootstrap-only placement, the anti-loss invariant, the single standing mount, the maintenance consequence. It deliberately does not restate the full requirement registry or the full bootstrap contract; those stay here, fetched at this path, and a consumer's carrier grows by one section rather than by this document's length.

Applicability follows the Project, not the tier. A repo is in applies_to because it is registered for a hosted ASK-facing repo-advisor Project role — not because it is important, upstream, or directly operated. method-ASK, design-system-ASK, ASK, and personal-context-system are excluded on that test alone; a repo that later registers for one adopts the profile then. The exclusion is a statement about deployment, never about whether the invariant is correct. Registration may precede Project configuration, and food-science-engine is the worked case: its census, its overlay rows, and its resolved carrier land first, while whether its Project is yet configured or active is operator state, not owner metadata.

One repo may home more than one hosted Project, and applicability attaches to the Project's role. urban-observatory homes two: an ASK-facing repo-advisor Project, and a separate TMK-facing domain-authority review Project. applies_to naming the repo binds its ASK-facing repo-advisor Project to the advisor-project-surface profile; it does not assign that role to every hosted Project associated with the repo — a second Project remains governed by this semantic owner document without becoming an advisor-project-surface profile consumer. A second Project with a different audience and a different authority topology is governed by its own overlay plus the protocol that owns its review class — see §Hosted domain-authority review variant. Audit each hosted Project independently; a requirement absent from one because its role does not carry it is not a gap in the other.

Because check.sh derives required profiles from applies_to, a repo added to that list fails its carrier check until it resolves the profile. That gap is the intended fail-closed signal, not a defect: the interval between registering applicability and resolving the carrier is exactly the interval in which a consumer believes it is covered and is not.

Cross-surface relation. Bootstrap-only connector deployment is a cross-surface architecture invariant, and this is not its only implementation. Personal-context Projects implement the same invariant under the personal ADR and the PCS scaffold; repo-advisor Projects implement it here, under this architecture and the advisor-project-surface profile. In both, the always-applied field carries only the pre-retrieval safety floor, one mounted bootstrap carries the operative contract and the exact live-index locator, and the index and canonicals are fetched live.

Sharing the invariant does not merge authority, widen a wall, make either implementation the owner of the other, or require one bootstrap payload to cross surfaces. This document does not govern personal-context Projects, and it is not amended by changes to the personal ADR. Reciprocal owner references record the shared invariant, but neither implementation governs or mutates the other. ASK, as apex, adjudicates any divergence.

A hosted Project may exist to carry a domain authority's judgment rather than to advise the operator. It uses the same deployment shape as a repo-advisor Project — thin Instructions floor, one mounted bootstrap, live-fetched scoped index, standing canonicals plus an operator-fed review packet — and not the repo-advisor role. Its authority topology is owned by docs/domain-authority-review-protocol.md, which operationalizes method-ASK's docs/governance.md (domain authority as a bounded instance of delegated discretion) and docs/source-of-intent.md (stage-aware, claim-level classification of domain-authority handoffs).

The distinction is who is in the thread and whose judgment the surface carries:

repo-advisor Project        ASK is in the thread; the surface challenges the operator's own reasoning
domain-authority Project    the domain authority is in the thread; ASK operates the surface for them

That inverts several assumptions the shared registry makes. In this variant:

• ASK operates and configures the Project and feeds the review packets. The domain authority does not administer the surface, and the surface is not an ASK proxy, a second operator, or an independent project authority.
• The domain authority is the human in the thread, and the authority within their named domain. The surface helps them develop, pressure-test, and articulate judgment. It does not supply the judgment, and synthesis never substitutes for their words where those words are load-bearing.
• ASK remains project architect, operator, relay, and the final adoption / authorization / publication / closure authority. Returned material reaches execution only through ASK's relay.
• Review packets are self-contained and carry the per-review stage contract — current stage, the decisions open, and the commitments held out of scope. The surface follows the packet's orchestration and does not improvise a decision interview from an un-orchestrated flat memo.
• Returned claims are classified claim by claim, not adopted whole-artifact. One handoff may carry a binding domain judgment and a premature implementation proposal at once; the first may bind, the second stays roadmap, scratch, or held architecture until ASK promotes it. No review advances project stage by implication.
• Expertise confers no project authority. Implementation architecture, execution, publication, and closure rights are named explicitly or they are absent.

Compactly: the domain authority owns judgment within the declared aperture; ASK owns what that judgment means for the project.

The profile instance is separable, and is currently held. urban-observatory is the first worked instance of the domain-authority review protocol. The manifest's domain-authority-review-profile remains status: held with applies_to: [], under hold-domain-authority-reviewer-format pending a second implemented pressure-test, and its own note says not to create an empty profile file for it yet — so no instantiated profile carrier exists. The UO-TMK standing fields are therefore recorded in these overlay rows and in the live surface carriers, without citing or manufacturing a profile instance. The distinction is load-bearing:

worked instance of the protocol   ≠   installed instance of the held profile

Columns: ID · requirement · owner (where the rule is authored) · home (where it is deployed) · ruling · evidence/notes. deployed presence records what the ASK deployments carried at the 2026-07-25 audit: FULL · PARTIAL · ABSENT · TEMPLATE-ONLY.

registry IDs                      103   = 80 shared + 22 surface overlays + 1 retired shared requirement

home presence — NOT a disjoint partition. Each line counts the IDs PRESENT in that home; a co-homed ID is
counted once in EACH of its declared homes, so these lines are not mutually exclusive and do not sum to 103.
  PI-FLOOR                         10   shared IDs
  BOOTSTRAP                        77   shared IDs
  INDEX                             5   shared IDs
  PROJECT-CONFIG                    1   shared ID — HOST-1, the hosted-Project configuration decision.
                                        Recorded outside the pasted fence; never mounted, and its
                                        revision earns no repaste and no remount
  SURFACE-OVERLAY                  22   overlay IDs (21 active + 1 retired overlay)
  RETIRED                           2   RET-1 shared · OVL-AP-2 overlay — each with a recorded reason.
                                        OVL-AP-2 is also counted in SURFACE-OVERLAY above; RET-1 carries
                                        no home line of its own
  NOT-APPLICABLE                    0

surface overlays by hosted-Project role
  asset-pipeline-ASK                3   OVL-AP-1 active · OVL-AP-2 retired · OVL-AP-3 active
  urban-observatory · ASK-facing    3   OVL-UO-1 · OVL-UO-2 · OVL-UO-3
  urban-observatory · TMK-facing    6   OVL-UO-TMK-1..6
  ecology-ASK                       3   OVL-ECO-1 · OVL-ECO-2 · OVL-ECO-3
  food-science-engine · ASK-facing  7   OVL-FSE-1 · OVL-FSE-2 · OVL-FSE-3 · OVL-FSE-4 · OVL-FSE-5 ·
                                        OVL-FSE-6 · OVL-FSE-7
  total                            22   21 active + OVL-AP-2 retired

per-Project PI-floor dispositions
  UO-TMK                            6 PRESERVE · 4 REVISED · 0 RETIRED · 0 N/A · 0 unowned = 10
  FSE                              10 PRESERVE · 0 REVISED · 0 RETIRED · 0 N/A · 0 unowned = 10

ruling (shared IDs)
  PRESERVE                         58
  RESTORE                           9   READ-3 · REVIEW-5 · REVIEW-7 · DISAGREE-1 · DISAGREE-2
                                        · POSTURE-3 · LIFE-4a · LIFE-5a · LIFE-5b
  REVISE                           11   MODEL-3 · DISAGREE-3 · START-4 · REVIEW-2 · REVIEW-9
                                        · READ-2 · LIFE-4 · LIFE-4b · LIFE-4d · LIFE-4h · LIFE-5c —
                                        the routed-instance lifecycle, its fresh-handoff
                                        scoping, the withdrawn PTX no-stacking clause, the
                                        2026-07-29 review-window regression repair, and the
                                        2026-07-30 mounted-source identity limb (READ-2)
  NEW                               2   HOST-1 — the hosted-Project memory-scope decision · LIFE-4l —
                                        the artifact-instance identity invariant. Both created by their
                                        own revision rather than recovered from a prior carrier
  ----                            ---
  active shared rulings            80   58 + 9 + 11 + 2 — must equal the shared-ID total above.
                                        `restored as surface overlay` below is NOT one of these
                                        categories: it counts OVERLAY IDs, which are outside the 80
  restored as surface overlay       2   OVL-AP-1 · OVL-ECO-2 (revised 2026-07-31 — per-hosted-
                                        Project topology corrected, R1; rewritten 2026-08-02 as a
                                        timeless invariant, R5 — current deployed topology now
                                        owned by the ecology index and generated ecology bootstrap,
                                        not frozen here)

deployed presence at the 2026-07-25 audit (shared IDs)
  FULL                             38
  PARTIAL                           5   includes REVIEW-2, whose deployed form conflates path
                                        resolution with exact retrieval
  ABSENT                            9   the four wholly-absent requirements · REVIEW-7 and POSTURE-3
                                        (rule kept, reason/criterion lost) · LIFE-4a · LIFE-5a · LIFE-5b
                                        (owner-rule detail not carried by the coarse rows)
  TEMPLATE-ONLY                     7   present in this repo's template, never propagated to a deployment
  n/a (revised)                     2   LIFE-5c — the row survives with its no-stacking half
                                        withdrawn, so its 2026-07-25 ABSENT reading no longer
                                        describes the requirement now in force · READ-2 — extended
                                        2026-07-30 with the display-label identity limb, so its
                                        2026-07-25 FULL reading no longer describes the
                                        requirement now in force
  n/a (new)                        19   START-1 · FAIL-1 — created by this architecture ·
                                        REVIEW-9 · REVIEW-10 · REVIEW-11 · REVIEW-12 · REVIEW-13 ·
                                        LIFE-4b · LIFE-4c · LIFE-4d · LIFE-4e · LIFE-4f · LIFE-4g ·
                                        LIFE-4h · LIFE-4i · LIFE-4j · LIFE-4k · LIFE-4l · HOST-1 —
                                        created after the 2026-07-25 audit, so no deployment
                                        was observed for them
  ----                            ---
  deployed-presence total          80   38 + 5 + 9 + 7 + 2 + 19 — must equal the shared-ID total
                                        above. Every shared ID carries exactly one deployed reading

unresolved                          0
unowned                             0
silent removals                     0
drops without a named carrier       0

Counts above are of requirement IDs, not of sentences or files. Several IDs are co-homed in two carriers (PI-FLOOR + BOOTSTRAP, or BOOTSTRAP + INDEX) where the floor states a minimal form and the bootstrap states the operative form; each such ID is counted in both homes and is listed once in the registry.

A migrated Project conforms when all of the following hold.

A1  exactly one standing Markdown Source; it is that surface's bootstrap; no mounted index — AND the
    mounted bootstrap body itself identifies the expected surface and role and declares that surface's
    exact index locator. Count alone never establishes identity: another surface's current, valid
    bootstrap satisfies both count and version while carrying the wrong role, wall, and index
A2  a fresh thread reads the bootstrap first and reports ALL of: the expected H1 / role; the exact
    declared index locator; the in-body version; AND one distinguishing clause or equivalent
    distinguishing content. The conjunction is the test — a version banner alone can survive on a
    partially loaded or reconstructed carrier, so version OR distinguishing content is NOT sufficient
A3  the bootstrap fetches the current index at its declared exact locator, with no search
A4  the fetched index reaches the grounding note, repo truth, protocol owner + manifest + live ledger,
    and a named scratch review object
A5  an ordinary index edit is picked up in a fresh thread with NO remount
A6  an ordinary protocol edit is picked up after a bootstrap remount with NO Instructions repaste — and a
    FRESH thread proves the same expected surface identity (H1 / role and the same exact surface locator),
    the intended NEW in-body version, AND one distinguishing clause from that revision. The displayed
    Source label is supporting evidence only
A7  with the connector disabled: the exact failed locator is named, a current copy is requested, no broad
    search occurs, no memory reconstruction occurs — AND the write boundary and no-fabrication floor
    still hold. A7 also owns CONNECTOR-FAILURE FALLBACK acceptance: if that current copy is mounted as a
    fallback index, the thin Instructions field is unchanged, the expected bootstrap remains mounted, the
    expected temporary Source set is bootstrap + fallback index, and the fallback index proves its own
    H1 / surface / role plus one distinguishing mapped path or clause in a FRESH thread. NO A10 rollback
    and NO full-Instructions repaste is performed or inferred, and the copy is retired when live access
    returns. Fallback evidence never satisfies A10, and A10 evidence never satisfies A7
A8  the Instructions field carries, for that Project: every PRESERVE requirement in its original form; the
    exact replacement named by every REVISED disposition; every overlay-specific pre-retrieval floor; and
    nothing that belongs elsewhere. A NOT-APPLICABLE requirement may be absent only with its recorded
    surface-specific reason. REVISED is NOT a licence to omit — it requires a named replacement to survive,
    so a missing preserved requirement, a REVISED requirement whose replacement is absent, or any
    undispositioned absence is a FAILURE. Where one repo homes multiple hosted Projects, each is tested
    independently
A9  wall boundaries are no broader than before migration; no private root is named in any bootstrap
A10 ROLLBACK ONLY — not connector-failure fallback, which is A7's. Rollback restores the prior
    architecture: repaste the frozen full Instructions canonical, remount the frozen index, so the
    bootstrap no longer supplies the active architecture. Tested under READ-2's ROLLBACK / MOUNTED-INDEX
    branch, on the fields that carrier actually holds, across BOTH evidence planes — both required.
    OPERATOR-SIDE INSTALLATION EVIDENCE: the expected rollback Source set and cardinality; the exact
    frozen full Instructions canonical identity; and the exact frozen index identity where byte identity
    is load-bearing. FRESH-THREAD EVIDENCE: the mounted index's own H1 / surface / role, one
    distinguishing mapped path or clause, and the restored rollback behavior. A fresh thread NEVER
    establishes the exact bytes repasted into the Instructions field — that is installation evidence, and
    a behavioral pass is not a substitute for it. Do NOT require `INDEX_CANONICAL_LOCATOR` or a bootstrap
    version banner from an index body — an index carries neither, and demanding them makes rollback
    unverifiable rather than rigorous. The displayed Source label is supporting evidence only
A11 a review object whose bytes contain markup and non-ASCII text is retrieved from mapped shared scratch by
    raw-byte route: any lossy extracted view is named as a representation failure, the exact SHA-256 and the
    literal markup line are returned from the raw bytes, and no manual upload is requested
A12 four paired-path cases, each with its own expected behavior: (1) minimum exact object available
    and ASK relays the readiness receipt with no narrowing envelope → the advisor reviews the exact
    object immediately and returns a recommendation, demanding no additional request phrase; (2) a
    summary relayed without the exact object → the review opens, readiness is incomplete, one
    publication request routes to the executor, and no second ASK request phrase exists; (3a) an
    explicit direct-execution authorization → no advisor Stage-1 verdict, and the executor proceeds
    only within the exact authorization; (3b) a `FYI` or `HOLD` envelope → no advisor Stage-1
    verdict, and no execution or write authority follows; silence or non-relay never elects direct
    execution
A13 each exact hosted Project INSTANCE has an operator configuration record naming that Project, the
    role/function it serves, its memory scope, the rationale, and — for a contextual-isolation
    function — the empty-Project workflow that Project-only alone does not provide. Test each instance
    independently, on the branch that matches it: a NEW instance passes only if the decision and record
    existed BEFORE the Project was created (decision timing = pre-creation); an EXISTING instance
    passes on a current post-creation reconciliation record that states that timing honestly and makes
    no creation-time claim. No recreation is required and none is inferred, and a particular scope
    value is never what is being tested. The population is every instance using this deployment shape —
    ASK-facing repo-advisor and hosted domain-authority review alike — each read from its own
    PROJECT-CONFIG carrier, which is a semantic home and not one named file

A7 is the gate for connector failure. It is the entire safety case for moving protocol out of the always-applied field, and it is not satisfied by inspection — it must be exercised.

A11 is the gate for retrieval fidelity, and it is the same kind of claim: a surface that has never been observed distinguishing a lossy view from an unreachable object has not demonstrated the property. Reading the bootstrap and concluding the advisor would retrieve raw bytes is not a test result.

Before generating a surface bootstrap, compare that surface's current PI master, current index, grounding note, session-start prompt, and applicable historical recovery carrier. Every surface-specific semantic requirement found there must receive one recorded disposition:

SURFACE-OVERLAY              carried in that surface's generated bootstrap
INDEX                        it is a map fact, not a rule
MOVED-with-carrier           a shared requirement already covers it — name the ID
REVISED                      replaced by a named requirement, with the reason
RETIRED-with-reason          explicit architectural reason
NOT-APPLICABLE-with-reason   surface named, reason recorded

The overlay table above is the disposition record for the three surfaces censused on 2026-07-25, plus the urban-observatory TMK-facing Project censused 2026-07-29 (OVL-UO-TMK-1..6 and §UO-TMK PI-floor disposition) and the food-science-engine ASK-facing Project role censused 2026-08-02 (OVL-FSE-1..7; its PI-floor disposition is 10 PRESERVE, recorded in the coverage report rather than as its own section, because no requirement there is revised). At the 2026-08-02 census no Project configuration existed and no generated advisor bootstrap had yet been produced — the order this section requires. At the 2026-07-29 census the live surface was already substantively configured for this role, and its Instructions canonical explicitly declined the ASK-facing repo-advisor profile by symmetry — but this registry had no entry for it, so an audit could see clauses absent without being able to tell intent from omission. It is not presumed complete for a surface not yet censused: running this gate is a precondition of generating that surface's bootstrap, not a step after it. Census each hosted Project, not each repo.

A surface bootstrap is generated as: the shared contract from templates/advisor-project-bootstrap.template.md, with the surface's parameters filled and its overlay requirements appended. The generated file is self-contained at runtime — it is the only thing the Project mounts.

The bootstrap template is generated from this registry, not copied from any deployed Instructions field or any historical carrier. A clause that appears in a historical carrier enters only through a registry ruling.