docs: make public artifacts independently reviewable

CONTINUATION.md

@@ -0,0 +1,70 @@
+# Continuing IICP development
+
+IICP is licensed and documented so that independent parties can review,
+implement and continue the protocol without access to the original maintainer's
+private development methods or production systems.
+
+## Start here
+
+1. Read [`GOVERNANCE.md`](GOVERNANCE.md), [`SPEC_STATUS.md`](SPEC_STATUS.md) and
+   [`VERSIONING.md`](VERSIONING.md).
+2. Use [`ecosystem/public-repositories.json`](ecosystem/public-repositories.json)
+   to locate the authoritative specification and maintained implementations.
+3. Reproduce the checks in [`CONTRIBUTING.md`](CONTRIBUTING.md) and
+   [`SPEC_RELEASE_PROCESS.md`](SPEC_RELEASE_PROCESS.md).
+4. Use [`research/RESEARCH.md`](research/RESEARCH.md) for product decisions,
+   rejected alternatives and open evidence gaps. Research is informative unless
+   a specification explicitly makes it normative.
+5. Use [`standards/REVIEWING.md`](standards/REVIEWING.md) for an independent
+   standards review or Internet-Draft candidate review.
+
+## What an independent implementation needs
+
+The versioned specifications, registries, JSON schemas, fixtures and
+conformance runner are the interoperability contract. The Rust, Python and
+TypeScript SDKs are useful implementation evidence, but no one implementation
+may silently redefine the protocol. The PHP and Rust directory repositories
+implement the control plane and have separate release lifecycles.
+
+An implementation should declare the protocol and profile versions it supports,
+fail safely on unsupported required behavior and preserve the documented
+privacy and security boundaries. Cross-language agreement within this project
+is parity evidence, not independent adoption.
+
+## Forks and stewardship
+
+The Apache-2.0 license permits independent use and forks under its terms. A fork
+does not automatically become the canonical IICP specification, inherit the
+IICP name, control existing package registries or gain access to production
+credentials. Those are distinct technical, governance, trademark and account
+questions.
+
+While the current repository remains maintained, propose protocol changes in a
+public issue and pull request. If it becomes unavailable, a successor effort
+should preserve immutable release history, publish its governance and security
+contacts, document the divergence point, retain compatibility fixtures and
+avoid reusing released version numbers for different semantics. Competing forks
+should use explicit implementation or profile identifiers until governance and
+interoperability converge.
+
+Maintainer or standards-editor authority should be based on sustained public
+review and implementation work, not access to private tools. A governance
+transition must identify the repositories, release-signing authority, registry
+accounts and security-reporting channel being transferred. No protocol artifact
+should contain the credentials or recovery secrets needed for that transfer.
+
+## Standards work
+
+An Internet-Draft contribution is governed by the IETF process and IETF Trust
+terms in addition to this repository's license. Building a review bundle or
+discussing the protocol does not authorize a submission, create IETF consensus
+or request an IANA registration. Any future registration request must identify
+the responsible public specification, change controller and review policy.
+
+## Public/private boundary
+
+Technical research that led to a product or protocol decision belongs in the
+public record with enough method and evidence to reproduce the conclusion.
+Private prompts, orchestration, work-selection systems and personal meta-tools
+are not implementation dependencies. The complete boundary is documented in
+[`docs/governance/public-artifact-boundary.md`](docs/governance/public-artifact-boundary.md).

CONTRIBUTING.md

@@ -18,9 +18,10 @@ remove unsupported claims, add the concrete evidence, or keep clear wording
 when the warning does not apply in context.
 
 Coordinated releases must update `ecosystem/releases.json` with their wire,
-conformance, compatibility, upgrade, migration and rollback semantics. The
-private integration repository validates that record against component
-manifests, tags and public registries.
+conformance, compatibility, upgrade, migration and rollback semantics. Public
+release evidence must be reproducible from component manifests, immutable tags
+and public package registries. Private project tooling may run additional
+checks, but it is not part of the public acceptance contract.
 
 Implementation bugs belong in the owning repository listed in
 `IMPLEMENTATIONS.md`. Never include production credentials, private topology or
@@ -35,11 +36,29 @@ real task data.
   operator preview until its separate cutover gates pass.
 - Use the owning SDK or browser-node repository for language- or
   runtime-specific defects.
-- Use `iicp.network` for cross-component integration, adoption, governance,
-  production evidence and private website or operations work.
+- Use this repository for cross-component interoperability questions that
+  cannot be assigned to one implementation. Send private deployment or account
+  matters to `community@iicp.network`, without credentials or task content.
 
 When responsibility moves between repositories, create one sanitized canonical
 successor, link both issues and close the old issue as moved. Do not transfer a
 private issue directly into a public repository: its comments may contain
 private operational context. Closing preserves the historical record and does
 not mean that the successor work is complete.
+
+## Standards contributions and intellectual property
+
+Specification contributions remain subject to the repository license. Text
+prepared for an Internet-Draft may also be submitted under the current IETF
+Trust Legal Provisions and IETF Note Well. A contribution does not authorize a
+standards submission. Contributors must disclose known intellectual-property
+claims that would affect implementation or standardization and must not submit
+text they are not entitled to license.
+
+The public record preserves technical evidence, alternatives and decisions.
+Private development prompts, orchestration, work-selection systems and
+meta-tools are not contribution requirements and must not be copied into this
+repository. See
+[`docs/governance/public-artifact-boundary.md`](docs/governance/public-artifact-boundary.md).
+Independent implementers and successor maintainers should also read
+[`CONTINUATION.md`](CONTINUATION.md).

IMPLEMENTATIONS.md

@@ -2,15 +2,12 @@
 
 This index is generated from `ecosystem/repositories.json`. Repositories are
 independently versioned; they are logical members of the IICP ecosystem, not
-Git submodules. Visibility describes source access, not protocol maturity.
+Git submodules. Private operations, website and development-method sources are
+not public build, conformance or governance dependencies.
 
 | Component | Authority | Language | Visibility | Lifecycle | Release |
 |---|---|---|---|---|---|
 | [IICP](https://github.com/RobLe3/IICP) | normative protocol, registries and reviewed research | specification | public | active | 1.10.13 |
-| iicp.network (source private) | cross-component issues, integration, conformance and project history | mixed | private | restructuring | — |
-| iicp-network-ops (source private) | reviewed deployment, rollback, REACH and community operational source; no live credentials or production data | mixed | private | active | — |
-| iicp-network-internal (source private) | FORGE, agent, project-management and reviewed private-history material; never a public build dependency | mixed | private | active | — |
-| iicp-website (source private) | private iicp.network website source and static-build contracts; not planned for publication | typescript | private | active | 0.1.0 |
 | [iicp-directory-php](https://github.com/RobLe3/iicp-directory-php) | PHP reference directory implementation and current Genesis Seed code line | php | public | active | 1.10.91 |
 | [iicp-directory-rust](https://github.com/RobLe3/iicp-directory-rust) | pre-1.0 Rust directory operator preview; not the production Genesis authority | rust | public | operator-preview | 0.1.12 |
 | [iicp-client-python](https://github.com/RobLe3/iicp-client-python) | Python consumer and provider SDK | python | public | active | 0.7.104 |

README.md

@@ -357,6 +357,15 @@ than inferred from source metadata.
 
 All normative language follows RFC 2119 / BCP 14.
 
+For an independent protocol or standards review, start with
+[`standards/REVIEWING.md`](standards/REVIEWING.md). The public
+[`ecosystem/public-repositories.json`](ecosystem/public-repositories.json)
+identifies the repositories and roles needed to continue implementation work.
+The specification release and review-bundle procedures are reproducible from
+public inputs and do not depend on the project's private development methods.
+[`CONTINUATION.md`](CONTINUATION.md) explains how an independent implementation
+or successor effort can preserve compatibility and release history.
+
 ---
 
 ## Tools
@@ -365,3 +374,8 @@ All normative language follows RFC 2119 / BCP 14.
 |------|---------|
 | [tools/protocol_integrity_analysis.py](tools/protocol_integrity_analysis.py) | Analyses a spec file for internal consistency |
 | [tools/quick_validation.py](tools/quick_validation.py) | Quick syntax + field validation against v1.4.2 |
+
+The simulation-oriented tools use optional scientific dependencies. Install
+them in an isolated environment with
+`python3 -m pip install -r tools/research-requirements.txt`. They are historical
+research aids, not normative conformance or release gates.

SECURITY.md

@@ -1,8 +1,39 @@
 # Security policy
 
-Do not disclose vulnerabilities through public issues. Use GitHub private
-vulnerability reporting when available or contact community@iicp.network.
+## Reporting a vulnerability
+
+Do not disclose an unpatched vulnerability through a public issue. Use
+[GitHub private vulnerability reporting](https://github.com/RobLe3/IICP/security/advisories/new)
+or contact `community@iicp.network`. Include the affected protocol or component
+version, minimal synthetic reproduction, expected security boundary and
+observed impact.
 
 Do not submit credentials, task payloads, production database contents,
 operator records, private endpoints or personal data. Protocol reports should
 use minimal synthetic reproductions and identify the affected version/profile.
+
+## Scope and support
+
+Security corrections target the latest published protocol suite and maintained
+implementation release lines. Older releases may not receive backports. The
+machine-readable repository and lifecycle list is
+[`ecosystem/public-repositories.json`](ecosystem/public-repositories.json).
+
+Protocol requirements, implementation behavior and deployment state have
+separate version axes. A specification fix does not prove that every deployed
+node has adopted it, and an implementation fix does not silently redefine the
+normative protocol.
+
+## Shared boundaries
+
+The public [`privacy adversary and trust model`](docs/security/privacy-adversary-and-trust-model.md)
+states the common directory, relay, provider, identity and metadata boundaries.
+In particular, transport security does not hide plaintext from the selected
+execution provider, and a directory response alone is not provider
+authentication. Unsupported required security or confidentiality profiles must
+fail closed.
+
+After a correction can be disclosed safely, publish a sanitized issue,
+advisory, test or release note sufficient for independent implementers to
+understand the affected boundary and verify the fix. Do not publish private
+incident records, credentials or personal development-method material.

SPEC_RELEASE_PROCESS.md

@@ -24,6 +24,9 @@ implementation worktree.
    A draft profile or fixture update does not by itself ratify a suite release.
 7. Build the release archive from a clean detached tag. Publish only immutable
    assets with SHA-256 checksums; never rebuild or replace an existing tag.
+8. Run `tools/check_public_artifact_closure.py`. A release or standards-review
+   input that depends on a private repository, missing local file or
+   workstation path is not portable and MUST NOT be published.
 
 ## Promotion checklist
 
@@ -37,6 +40,11 @@ implementation worktree.
 - Verify that status terms follow `SPEC_STATUS.md` and version axes follow
   `VERSIONING.md`.
 - Recheck every external registry claim immediately before publishing.
+- Confirm that the archive contains its root license, governance, security,
+  contribution and continuation instructions.
+- Run `python3 tools/check_public_artifact_closure.py --all-public` to catch
+  stale private dependencies elsewhere in the tracked public research and
+  documentation corpus before tagging.
 
 ## Boundaries
 
@@ -48,3 +56,7 @@ implementation worktree.
   and cross-implementation evidence package. Semantic profiles are preferred.
 - Website and implementation-repository documentation are public references,
   not substitutes for this canonical source.
+- Public technical research records the evidence and reasoning behind product
+  decisions. Private development methodology is neither normative evidence nor
+  a release dependency. The boundary is defined in
+  `docs/governance/public-artifact-boundary.md`.

docs/external-evidence-participation.md

@@ -13,7 +13,7 @@ result independent.
 The machine-readable campaign index is
 [`external-participation-campaign-v1.json`](../evidence/external-participation-campaign-v1.json).
 It fixes the participant class, artifact versions, record, validation command
-and submission path for the six current lanes. Every repository-owned state is
+and submission path for the five public protocol and implementation lanes. Every repository-owned state is
 `awaiting-participant`; the project does not infer acceptance, consent, a
 result or a decision. Validate the index with:
 
@@ -29,14 +29,13 @@ python3 tools/check_external_participation_campaign.py
 | Newcomer usability | IICP #94 | At least one non-technical reader, one developer, and one prospective node operator | The script below and the published website/operator guide | Three consented, anonymized session records and a findings summary |
 | Linux watchdog | Rust SDK #66 | A representative Linux/systemd operator, preferably including ARM | Rust SDK `0.7.104` and its opt-in native watchdog | Slow-start, pressure, reboot/logout, linger, restart, and rollback record |
 | Relay eligibility | IICP #59 | An independent relay operator and topology measurement environment | Current pre-normative relay research | Stale, forged, replayed, overloaded and partial-evidence cases without topology leakage |
-| Qualified EU review | Root #768 and #801 | A qualified EU privacy and AI-law reviewer | The dated qualified-review packet | An attributable decision record and review memorandum |
 | Standards governance | IICP #47 | A consenting lead editor, backup editor, and change controller | The current draft candidate and governance decision contract | A non-sensitive governance decision with named stewardship roles |
 
-The qualified reviewer starts with the dated packet linked from root #768 and
-#801. The standards-governance lane starts from
+Website and operator legal review is managed separately because its source
+packet is not a protocol or implementation dependency. The standards-governance lane starts from
 [`submission-governance-decision-v1.json`](../standards/submission-governance-decision-v1.json)
-and requires a consenting backup editor before IICP #47 can close. Neither lane
-authorizes a deployment, publication or standards submission.
+and requires a consenting backup editor before IICP #47 can close. That lane
+does not authorize a deployment, publication or standards submission.
 
 Two related paths are documented below but are not campaign intake lanes.
 Public evidence access is a repeatable availability check for the evidence

docs/governance/public-artifact-boundary.md

@@ -0,0 +1,67 @@
+# Public artifact and private-method boundary
+
+## Purpose
+
+IICP's public repositories must be sufficient to review, implement, test and
+maintain the protocol. They do not need to disclose the private development
+system that produced the work.
+
+This boundary applies to specification releases, standards-review material,
+public research, implementation repositories and conformance evidence.
+
+## Public artifacts
+
+The public record includes:
+
+- normative specifications, registries, schemas and compatibility rules;
+- source code for public implementations;
+- technical research that affected a feature or protocol decision;
+- experimental methods, inputs and limitations needed to reproduce a result;
+- alternatives considered, rejected approaches and compatibility consequences;
+- public architecture and security decisions;
+- milestone definitions expressed as observable acceptance criteria;
+- conformance fixtures, tests and content-free evidence;
+- release, build, maintenance and contribution instructions.
+
+A future implementer should be able to determine what was decided, which
+evidence supported it, what remains uncertain and what would justify revisiting
+the decision.
+
+## Private material
+
+Private material includes development-loop implementation, agent prompts,
+orchestration, internal work selection, personal reasoning systems, private
+meta-tools, credentials, private topology and operational history. Public
+builds and protocol decisions must not depend on that material.
+
+Private tools may check public artifacts, but their names, scores or internal
+state are not public acceptance evidence. The public evidence must be
+reproducible with the commands and inputs shipped in the public repository.
+
+## Mixed-source treatment
+
+When private work produces a public product decision, publish a self-contained
+record containing the question, evidence, alternatives, decision,
+consequences, limitations and acceptance criteria. Do not publish the private
+workflow that generated or prioritized the work.
+
+When a public artifact refers to private material, use one of these treatments:
+
+1. state the required technical rule in the public specification;
+2. create a sanitized public decision or research record;
+3. cite public fixture, test or release evidence; or
+4. remove the reference when it is historical and unnecessary.
+
+Public issue summaries must not copy private comments, credentials, personal
+data or operational details.
+
+## Closure rule
+
+A normative or review-facing artifact is self-contained only when every local
+reference resolves within the public repository or release and every external
+reference is publicly retrievable. A private repository, internal project path
+or workstation-local path cannot be normative authority.
+
+The public-artifact closure checker enforces this mechanical boundary. Human
+review remains responsible for deciding whether the published rationale and
+evidence are sufficient.