RobLe3 · RobLe3 · Sep 25, 2026 · Sep 25, 2026 · Sep 25, 2026 · Sep 25, 2026
diff --git a/CONTINUATION.md b/CONTINUATION.md
@@ -18,9 +18,10 @@ private development methods or production systems.
 5. Use [`standards/REVIEWING.md`](standards/REVIEWING.md) for an independent
    standards review or Internet-Draft candidate review.
 6. Use [`standards/IICP_PROTOCOL_POSITIONING.md`](standards/IICP_PROTOCOL_POSITIONING.md)
-   and the dated [protocol comparison](standards/PROTOCOL_COMPARISON_2026-08-15.md)
+   as the current entry point to the dated
+   [September comparison](standards/PROTOCOL_COMPARISON_2026-09-25.md)
    before changing IICP's boundary with IAIP, AIDIP, MCP, A2A or discovery
-   protocols. The machine-readable facts live in
+   protocols. The machine-readable assessment lives in
    `standards/protocol-comparison-v1.json`.
 
 ## What an independent implementation needs

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -4,13 +4,23 @@ Start with a public issue that identifies an interoperability problem rather
 than a preferred implementation. Specification changes should include schemas,
 compatibility behavior and conformance vectors where applicable.
 
-Run the repository checks before proposing a change:
+From the repository root, use an isolated Python environment with the
+requirements in `tools/requirements.txt` and the local conformance runner
+(`python3 -m pip install './conformance-runner[signing]'`). Run the checks
+relevant to the files changed before proposing a pull request:
 
 ```bash
 python3 tools/generate_implementations.py --check
+tools/run_profile_fixture_contract.sh
 python3 tools/check_public_prose.py --strict README.md GOVERNANCE.md CONTRIBUTING.md
+python3 tools/check_public_artifact_closure.py --all-public
 ```
 
+`ecosystem.yml` contains the required pull-request `validate` job.
+`profile-fixtures.yml` is a manual diagnostic workflow, not an additional
+qualification pass. Do not interpret a skipped, unrun or dependency-failed
+check as passing evidence. Run locally first to conserve hosted CI minutes.
+
 The prose check blocks objective citation artifacts and reports stylistic or
 substance heuristics for human review. It checks writing quality, not whether a
 person or a model wrote the text. Do not replace flagged words mechanically;
@@ -27,6 +37,11 @@ Implementation bugs belong in the owning repository listed in
 `IMPLEMENTATIONS.md`. Never include production credentials, private topology or
 real task data.
 
+An implementation result may expose a discrepancy in the specification, but
+it cannot silently change released semantics. Record the applicable release,
+Profile and binding; propose any interoperable correction with compatibility
+behavior and fixtures. Preserve immutable tags and release assets.
+
 ## Where to open an issue
 
 - Use this repository for normative protocol semantics, registries,

diff --git a/README.md b/README.md
diff --git a/SPEC_RELEASE_PROCESS.md b/SPEC_RELEASE_PROCESS.md
@@ -48,9 +48,9 @@ implementation worktree.
 
 ## Boundaries
 
-- Current executable behavior takes precedence over contradictory historical
-  prose; record the discrepancy and correction rather than retroactively
-  reinterpreting wire behavior.
+- Current executable behavior can expose a contradiction in historical prose;
+  record it and propose the correction. It cannot override a released
+  normative contract or retroactively reinterpret wire behavior.
 - Registry entries require implementation evidence and payload/schema review.
 - Base-frame changes require an independent compatibility, malformed-input,
   and cross-implementation evidence package. Semantic profiles are preferred.

diff --git a/TERMINOLOGY_AND_DISCOVERABILITY.md b/TERMINOLOGY_AND_DISCOVERABILITY.md
@@ -14,8 +14,8 @@ The subtitle describes the control-plane role. It does not mean that IICP
 defines every agent task format, identity system, transport, or runtime.
 The current mechanism-level boundary is recorded in
 [`standards/IICP_PROTOCOL_POSITIONING.md`](standards/IICP_PROTOCOL_POSITIONING.md)
-and the dated
-[`standards/PROTOCOL_COMPARISON_2026-08-15.md`](standards/PROTOCOL_COMPARISON_2026-08-15.md).
+with its dated
+[`September assessment`](standards/PROTOCOL_COMPARISON_2026-09-25.md).
 
 ## Term map
 

diff --git a/VERSIONING.md b/VERSIONING.md
@@ -8,7 +8,9 @@
 
 **Format**: `MAJOR.MINOR.PATCH` (semver)  
 **Source of truth**: `spec/v1.9/VERSION` in the [`RobLe3/IICP`](https://github.com/RobLe3/IICP) spec repo  
-**Displayed as**: `IICP v1.9.0` or `IICP Protocol v1.9.0`  
+**Displayed as**: `IICP Protocol Suite v<release>`; read the generated
+[`ecosystem/CURRENT_VERSIONS.md`](ecosystem/CURRENT_VERSIONS.md) before citing
+the latest published release.
 **Changelog**: `CHANGELOG.md` in the IICP spec repo
 
 This is the version that external implementers, operators, and IETF reviewers see. It covers
@@ -24,7 +26,7 @@ the entire IICP specification suite (core, CIP, framing, identity, telemetry, et
 | v1.9.0 | 2026-05-30 | RT-01/RT-05 reputation caps and directory drift closeout |
 | v1.9.1 | 2026-07-30 | Status/version governance and transport/IANA errata; superseded because its bundled implementation index was stale |
 | v1.9.2 | 2026-07-30 | Corrective immutable release with synchronized implementation/package references and a version-truth gate |
-| **v1.10.17** | **2026-08-25** | **Current candidate** — binds existing pre-normative compatibility and security evidence without ratifying a Profile or changing the base wire |
+| v1.10.17 | 2026-08-25 | Published suite release; binds existing pre-normative compatibility and security evidence without ratifying every Profile or changing the base wire |
 | v1.10.16 | 2026-08-20 | Outcome-v2 reputation semantics and retry-safe metrics acknowledgement; no base-wire change |
 | v1.10.15 | 2026-08-20 | Restricted trust-domain semantic vectors and security-profile evidence; no base-wire change |
 | v1.10.14 | 2026-08-15 | Compatible chat helpers default to the bounded runtime-identity context; raw submit and non-chat operations remain unchanged; no base-wire change |
@@ -69,7 +71,9 @@ which version of a sub-document contains which normative text.
 
 **Rules:**
 - Sub-spec versions are for editors. End users see the Protocol Suite version.
-- When displaying both: `IICP v1.10.17 · S.12 CIP v0.6.13` (suite first, sub-spec second)
+- When displaying both: name the published suite release and the applicable
+  sub-spec revision separately; do not present a working-main revision as a
+  published release.
 - Never use a sub-spec version alone as "the" IICP version on public-facing surfaces
 
 ---
@@ -87,7 +91,8 @@ releases MAY implement the same OpenAPI version.
 
 **Format**: `vMAJOR.MINOR.PATCH`  
 **Scope**: Each software component has its own version  
-**Source**: `directory/config/app.php iicp_version` (directory service)
+**Source**: the owning component repository and its immutable package or
+release metadata; runtime self-reporting is separate deployment evidence.
 
 The reference implementation version tracks software releases, not protocol releases.
 A software version can be ahead of or behind the spec version (e.g., directory v1.10.x
@@ -97,9 +102,8 @@ implements Protocol Suite v1.9.0).
 |-----------|----------------|----------|
 | Directory (PHP Genesis) | Check `IMPLEMENTATIONS.md` and the release registry | Current Genesis implementation |
 | Directory (Rust preview) | Check `IMPLEMENTATIONS.md` and the release registry | Official second flavour; operator preview |
-| Adapter (Python) | v1.x — check adapter/VERSION or pyproject.toml | |
-| Proxy (Python) | v1.x | |
-| Rust node | v0.x | `iicp-node/Cargo.toml` |
+| Consumer/provider SDKs | Check `IMPLEMENTATIONS.md` and each owning repository | Independently versioned Python, TypeScript and Rust releases |
+| Browser node and Management | Check `IMPLEMENTATIONS.md` | Experimental and developer-preview lines, respectively |
 
 **Rules:**
 - Never use the directory software version as "the" IICP version on public surfaces
@@ -128,10 +132,10 @@ be displayed as the Protocol Suite, OpenAPI or package version.
 
 | Surface | What to display | Example |
 |---------|----------------|---------|
-| Research page badge | Protocol Suite version | Use `spec/v1.9/VERSION` and label the axis |
-| Spec references in page body | Suite + sub-spec | `IICP v1.10.17 · S.12 v0.6.13` |
-| Implementation evidence | Software version | `directory v1.9.19` |
-| PR commit messages | Component + software version | `[directory] v1.9.19` |
+| Research page badge | Published Protocol Suite version | Use the generated release projection and label the axis |
+| Spec references in page body | Suite + sub-spec | Name each applicable release or revision separately |
+| Implementation evidence | Software version | Name the component, immutable release or commit and evidence date |
+| PR commit messages | Component + software version | Name the component and intended release only if one is actually being prepared |
 | IICP repo CHANGELOG | Protocol Suite version | `## v1.7.0 — 2026-05-24` |
 | Spec file headers | Sub-spec version | `**Version**: 0.6.13` |
 
@@ -145,29 +149,17 @@ be displayed as the Protocol Suite, OpenAPI or package version.
 
 ## 8. Version Update Procedure
 
-When making spec changes that warrant a version bump:
-
-```bash
-# 1. Update the IICP spec repo (via GitHub API or clone)
-#    - Update spec/v1.9/VERSION
-#    - Add entry to CHANGELOG.md
-
-# 2. Update the sub-spec document version header
-#    - File: spec/iicp-cooperative-inference.md (or other sub-spec)
-#    - Field: **Version**: x.x.x
-#    - Add changelog entry in the document's own changelog table
-
-# 3. Update website badge
-#    - File: website/app/research/page.tsx
-#    - Badge: "IICP vX.Y.Z · Updated YYYY-MM-DD"
-#    - Footer: "Spec: S.12 vA.B.C"
-
-# 4. Update directory software version (only when shipping directory changes)
-#    - File: directory/config/app.php
-#    - Field: iicp_version
-
-# 5. Update website asset version (only when doing a full website deploy)
-#    - File: website/public/assets/json/version-info.json
-```
-
-The IICP spec repo version and the directory software version update on independent schedules.
+For a reviewed Protocol Suite release, update this specification repository's
+`spec/v1.9/VERSION`, `CHANGELOG.md`, applicable specification documents and
+release metadata through [`SPEC_RELEASE_PROCESS.md`](SPEC_RELEASE_PROCESS.md).
+Change a sub-spec revision only in the document that owns it; the `spec/v1.9/`
+directory name is the wire-compatibility lineage, not the suite version.
+
+Implementation, SDK package, browser-node, Management, directory and website
+versions are updated in their **owning repositories**, on their own release
+schedules. Use [`IMPLEMENTATIONS.md`](IMPLEMENTATIONS.md), the
+[`ecosystem` registry](ecosystem/repositories.json) and the owning repository's
+release procedure to locate those sources. Update this repository's generated
+ecosystem projection from its authoritative catalogue; do not edit copied
+component paths or imply a package or deployment changed because the suite
+version changed.
diff --git a/docs/agent-bootstrap.md b/docs/agent-bootstrap.md
@@ -6,8 +6,7 @@ registration, health and discovery; the selected agents exchange the task
 directly.
 
 For the boundary with IAIP, AIDIP, MCP, A2A and DNS-based discovery, read the
-[protocol positioning](../standards/IICP_PROTOCOL_POSITIONING.md) and
-[source-backed comparison](../standards/PROTOCOL_COMPARISON_2026-08-15.md).
+[current positioning and comparison entry point](../standards/IICP_PROTOCOL_POSITIONING.md).
 The short version is that IICP selects an eligible provider; the selected
 execution protocol defines how that provider performs the task.
 
@@ -30,12 +29,15 @@ rather than treating this protocol overview as an installation runbook.
    `https://iicp.network`.
 3. Express the requested capability as an intent URN, for example
    `urn:iicp:intent:llm:chat:v1`.
-4. Discover eligible providers and apply the SDK's health, policy and
-   confidentiality checks.
+4. Discover candidates and apply the SDK's non-overridable capability,
+   security, policy, health and confidentiality eligibility checks. Default
+   selection preserves directory recommendation order unless a declared
+   supported selection Profile permits reordering within the eligible set.
 5. Obtain dispatch authorization when the directory requires it.
 6. Send the task to the selected provider endpoint, not to the directory.
 7. Validate the response or receipt. If the provider fails, rediscover or try
-   another eligible result within the task's retry policy.
+   another eligible result only within the task's retry and route-authority
+   rules. A single-route ticket does not permit provider substitution.
 
 Installation:
 
@@ -57,8 +59,9 @@ the specification.
    source control.
 3. Declare only the intents, models, limits and policy that the runtime can
    serve.
-4. Register a routable endpoint, then send heartbeats at the required
-   interval.
+4. Register a routable endpoint, then send heartbeats at the applicable
+   interval. Registration credentials authorize provider-directory control
+   operations; they are not arbitrary consumer execution credentials.
 5. Keep health output consistent with registered capabilities. Remove a model
    from registration when the runtime no longer exposes it.
 6. Authenticate incoming tasks, enforce local policy and return structured

diff --git a/docs/architecture/decision-documentation-map.md b/docs/architecture/decision-documentation-map.md
@@ -31,6 +31,14 @@ operations, credentials, raw logs, and agent tooling do not.
 | Identifiers and registry governance | [Identifier and registry architecture](identifier-and-registry-architecture.md) | Treat released identifiers as opaque, stable project identifiers without implying IANA assignment |
 | Portability and independent continuation | [Portability and non-capture](portability-and-non-capture.md) | Explain how users can choose implementations and operate without a mandatory commercial control plane |
 | Node health and third-party operator tooling | [Node observability interfaces](node-observability-interfaces.md) | Distinguish authoritative health, directory-reported state, local observation, and inference |
+| Management, policy and restricted domains | [Pre-1.0 feature boundary](../../pre1/README.md) and the [Management implementation](https://github.com/RobLe3/iicp-management) | Distinguish desired, accepted, observed and effective state; policy constrains eligibility but does not grant execution or override domain-local authority |
+
+Closed User Groups apply domain-local policy and eligibility; optional
+Management contracts coordinate desired and observed state above the protocol
+execution boundary. Local enforcement evidence must not be described as a
+deployed remote-administration service. Future Software Defined Intelligence
+proposals are research, not an additional released Core contract. For exact
+Management APIs or installation, use its owning repository.
 
 ## Publication rule
 
@@ -56,4 +64,3 @@ For each accepted or superseded decision, reviewers should ask:
 - Does the guide link to the authority instead of copying unstable details?
 - Are published, deployed, adopted, and experimental states kept separate?
 - If a later decision replaced this one, are stale examples removed or clearly historical?
-