@@ -0,0 +1,66 @@
+name: Independent adoption pilot
+description: Report a documentation-only pilot in a new domain
+title: "Pilot: "
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for testing the public golden path. Do not include secrets or proprietary source material.
+  - type: input
+    id: domain
+    attributes:
+      label: Domain
+      description: What kind of reference did you build?
+    validations:
+      required: true
+  - type: input
+    id: environment
+    attributes:
+      label: Environment
+      description: Operating system and Node.js version
+    validations:
+      required: true
+  - type: input
+    id: elapsed
+    attributes:
+      label: Hands-on time
+      description: Exclude domain research and DNS work.
+    validations:
+      required: true
+  - type: checkboxes
+    id: tasks
+    attributes:
+      label: Completed tasks
+      options:
+        - label: Initialized a clean project
+        - label: Replaced the example with a new domain
+        - label: Validation passed
+        - label: Build passed
+        - label: Verification passed
+        - label: Link checking passed
+        - label: Inspected the site and JSON API
+        - label: Deployed or documented why deployment was not applicable
+  - type: textarea
+    id: blockers
+    attributes:
+      label: Blockers and misleading instructions
+      description: Include the command, observed result, and what you expected.
+    validations:
+      required: true
+  - type: textarea
+    id: understanding
+    attributes:
+      label: What does this project do?
+      description: Explain it in your own words, including what it does not do.
+    validations:
+      required: true
+  - type: dropdown
+    id: reuse
+    attributes:
+      label: Would you use the result again?
+      options:
+        - "Yes"
+        - "Maybe"
+        - "No"
+    validations:
+      required: true
@@ -0,0 +1,57 @@
+# Independent Adoption Pilot
+
+## Purpose
+
+The adoption gate measures whether Knowledge-as-Code transfers to a new maintainer and domain without live interpretation from its author. It is a usability and product-fit test, not a promotion exercise.
+
+Internal portfolio deployments, copied demos, repository stars, page views, and maintainer-led walkthroughs do not pass this gate.
+
+## Pilot participant
+
+The participant should be technically comfortable with Git, Markdown, YAML, and Node.js but should not have previously worked in this repository. They should bring a real reference domain with at least two stable concepts, one grouping or framework, one source authority, and one mapping.
+
+## Rules
+
+- Start from the public README and a clean checkout.
+- Do not receive live setup help from the maintainer.
+- Record questions and blockers as they occur instead of working around them silently.
+- Do not use the canonical security example as the pilot domain.
+- Stop if the process would require publishing confidential or regulated information.
+
+## Tasks
+
+1. Decide from the README whether the tool fits the domain.
+2. Create a clean project with `scripts/init.js`.
+3. Rename the four entity roles in plain domain language.
+4. Replace the example with at least two primaries, one container, one authority, and one secondary mapping.
+5. Attach an HTTPS evidence source and a truthful `last_verified` date.
+6. Run validation, build, verification, and internal link checking.
+7. Inspect the generated site and JSON API.
+8. Deploy to a temporary static URL or document why deployment is out of scope.
+9. File a pilot report using the GitHub issue template.
+
+## Pass criteria
+
+A pilot passes when:
+
+- the participant correctly explains what the generator does and does not do
+- the initialized repository contains no canonical landing-site material
+- all required commands exit zero without source-code changes
+- the participant can trace a generated page and JSON record back to its source file and evidence
+- no live maintainer intervention is needed
+- setup through local inspection takes no more than 90 minutes, excluding domain research and DNS
+- every blocker and misleading instruction is captured
+
+Deployment may be marked not applicable when organizational policy prevents it. All other criteria remain required.
+
+## Decision rules
+
+- One passing pilot establishes basic external transferability.
+- Three passing pilots in distinct domains establish a repeatable supported path.
+- A failure changes documentation or the golden path before another outreach attempt.
+- Repeated requests from three independent pilots may justify a core feature. One-off needs remain extensions.
+- Results are reported as pilots, not generalized adoption claims.
+
+## Pilot report
+
+Record the domain, environment, elapsed hands-on time, completed tasks, command output, blockers, unexpected concepts, and whether the participant would use the result again. Do not include secrets or proprietary source material.
@@ -25,6 +25,8 @@ pattern.
 - Expanded deterministic verification to fail on missing reviews, invalid or future dates, mapping gaps, and required evidence metadata.
 - Added a provider-independent external verifier contract using an explicit executable and JSONL input/output, with no shell or source-file mutation.
 - Re-verified the worked example against current ISO and NIST primary sources, corrected unsupported claims, and replaced the ambiguous data-quality mapping with information integrity.
+- Documented the internal-first operating model, bounded maintenance policy, security scope, viable open-repository end state, and independent adoption pilot gate.
+- Added a structured GitHub issue form for independent pilot reports.
 
 ## [1.0.2] — 2026-06-12
 
 
@@ -2,6 +2,8 @@
 
 This project follows a zero-dependency, config-driven approach. All domain-specific settings live in `project.yml`, and all scripts use only Node.js built-ins.
 
+Read [MAINTENANCE.md](MAINTENANCE.md) before proposing a feature. Reproducible defects in the supported golden path take priority over maintenance-surface expansion. New adopters can report a documentation-only trial through [ADOPTION.md](ADOPTION.md).
+
 ## Adding Entities
 
 ### 1. Create the Markdown File
 
@@ -0,0 +1,76 @@
+# Intent
+
+## Status
+
+Knowledge-as-Code is an internal-first open utility maintained by PAICE.work PBC. It is used inside the PAICE and Snap Synapse portfolios and published under MIT so others can inspect, reuse, and improve it.
+
+The project is not pursuing broad developer mindshare as an end in itself. Public adoption is useful when it demonstrates that the generator transfers to a new domain without maintainer interpretation.
+
+## Purpose
+
+Maintain a small, portable generator for evidence-backed structured references that need:
+
+- Git-tracked source files readable without proprietary tooling
+- a configurable Primary, Container, Authority, and Secondary entity model
+- deterministic validation, drift detection, and reproducible output
+- a static human-readable site and JSON API from the same source
+- an optional local MCP interface
+
+## Intended users
+
+The narrow primary audience is a technically capable maintainer who owns a reference dataset, needs evidence and review dates to remain visible, and wants to publish without a database or hosted application runtime.
+
+The project is a poor fit for collaborative editing by nontechnical teams, transactional applications, high-volume ingestion, or knowledge domains without a stable ontology.
+
+## Operating model
+
+- Internal portfolio use funds the maintenance floor.
+- The clean initializer is the supported adoption path.
+- The example is a testable teaching fixture, not an authoritative security reference.
+- Public support is best effort with no response-time commitment.
+- Correctness, security, portability, and the supported golden path take priority over feature breadth.
+- Integrations belong behind documented provider-independent contracts.
+
+## Viable open-repository end state
+
+The repository is sustainable when it remains useful internally even if external adoption is zero, while an independent user can still understand, initialize, verify, build, and deploy it from public documentation alone.
+
+A mature end state has:
+
+- one stable 1.x generator and initializer
+- zero required runtime dependencies beyond supported Node.js
+- a bounded compatibility and security policy
+- reproducible tests for the public golden path
+- a small release surface driven by internal needs, security findings, and independently reproduced user problems
+- documented extension contracts instead of bundled vendor integrations
+- no implied service-level agreement, community roadmap, or obligation to accept features
+
+## Adoption evidence
+
+Repository traffic, stars, social engagement, and maintainer-assisted demos are weak signals. The meaningful gate is an external pilot completed without live maintainer help. See `ADOPTION.md`.
+
+Until that gate is passed, claims should say the project is used internally and available for external reuse. They should not imply independent adoption.
+
+## Recalibration gates
+
+- If the initializer cannot create a working project from a clean checkout, stop feature work and restore the golden path.
+- If internal users stop using the generator, reassess whether the repository should enter maintenance-only status.
+- If three independent pilots complete the golden path and request the same extension, consider it for the core.
+- If an extension benefits only one deployment, keep it outside the core behind a documented contract.
+- If maintenance cost exceeds internal value, preserve the last working release and archive the repository transparently.
+
+## Non-goals
+
+- Becoming a general-purpose knowledge-management platform
+- Bundling an AI provider or hosted verification service
+- Maintaining domain data on behalf of downstream users
+- Optimizing for stars, launch traffic, or speculative integrations
+- Promising a fixed release cadence
+
+## Exceptions to Repo Standards
+
+None currently recorded.
+
+## Changelog
+
+- 2026-07-21: Recalibrated the project from adoption-seeking template to internal-first open utility; made independent transfer the public adoption gate.
@@ -0,0 +1,51 @@
+# Maintenance
+
+## Support status
+
+Knowledge-as-Code is actively used internally and maintained as an open utility. Public support is best effort. There is no guaranteed response time, release schedule, or commitment to implement requested features.
+
+## Supported path
+
+The maintained public path is:
+
+1. Run the initializer from a clean checkout.
+2. Edit `project.yml` and the generated `data/` tree.
+3. Run validation, build, verification, evals where included, and link checking.
+4. Deploy the generated `docs/` artifact with the included GitHub Pages workflow or another static host.
+5. Optionally run the local MCP server over standard input and output.
+
+The current supported runtime is Node.js 18 or later on macOS and Linux. Windows may work but is not part of the tested support promise.
+
+## Maintenance priorities
+
+Work is prioritized in this order:
+
+1. Security vulnerabilities and unsafe generated output
+2. Incorrect validation or evidence results
+3. Breakage in the initializer, build, or deployment golden path
+4. Reproducibility and portability defects
+5. Documentation failures reproduced by an independent user
+6. Features needed by active internal deployments
+7. Other enhancements when maintainer capacity permits
+
+## Compatibility
+
+Patch releases may fix correctness, security, documentation, and generated output. Minor releases may add backward-compatible configuration or output. Breaking configuration, API, route, or MCP changes require a major version or a documented migration path.
+
+Generated HTML appearance is not a stable API. JSON API fields, entity IDs, routes, configuration keys, and MCP tool contracts are compatibility surfaces.
+
+## Contributions
+
+Bug reports with a minimal reproduction are the most useful public contribution. Small fixes that preserve the zero-dependency core and supported path are welcome. A pull request may be correct and still remain unmerged if it expands the permanent maintenance surface beyond current capacity.
+
+Domain-specific adapters and model integrations should generally live outside this repository and use the external verifier contract.
+
+## Releases and deprecation
+
+There is no fixed release cadence. Releases are cut when a coherent set of tested changes is ready. A deprecated compatibility surface should remain available for at least one minor release when practical and be called out in the changelog.
+
+If the project becomes maintenance-only or archived, the README will say so plainly. The last working release and MIT license will remain available.
+
+## Security
+
+See `SECURITY.md` for private reporting and the supported security scope.
@@ -47,7 +47,7 @@ files:
 
   - path: README.md
     role: protocol
-    hash: sha256:5058024954c44dc3ea425f43ee3957ef5f7264f9357cb10808a512979e54cca5
+    hash: sha256:f47e4560f3e9f15a7d6d9f934040bb597d662caeace3324f78768a7717e2ffd8
     note: Template overview
 
   - path: assistant-guide.txt
@@ -77,7 +77,7 @@ files:
 
   - path: scripts/init.js
     role: tooling
-    hash: sha256:fd643cf6081cc4aaebf1d3ce6d673a0582de1f74cbf7f6222cd8a811f39bc9da
+    hash: sha256:ad1fa4e19c0b6bf480b3d6782265268f4a70a00c84a50108c99576d39d3e7a65
     note: Clean-project initializer
 
   - path: scripts/validate.js
 
@@ -4,6 +4,13 @@ A zero-dependency generator for evidence-backed reference sites. Keep structured
 
 This repository is an internal-first open utility maintained by [PAICE.work](https://paice.work/) PBC. It supports active reference projects inside the PAICE and Snap Synapse portfolios. Public issues and contributions are welcome on a best-effort basis.
 
+## Project status
+
+- [Intent and viable end state](INTENT.md)
+- [Maintenance and compatibility](MAINTENANCE.md)
+- [Independent adoption pilot](ADOPTION.md)
+- [Security policy](SECURITY.md)
+
 ## Who this is for
 
 Maintainers of public registries, comparison databases, compliance maps, and other structured references where claims need sources, review dates, and machine-readable output.
@@ -194,7 +201,7 @@ node scripts/eval.js       # Run smoke, link, API, parser, MCP, and docs evals (
 ## Architecture
 
 - **File-over-App** — data in markdown files, not a database
-- **Zero dependencies** — no npm install, no supply chain risk
+- **Zero dependencies** — no npm install and no third-party runtime packages in the core
 - **Bespoke static generation** — the build script _is_ the specification
 - **GitOps** — Git is the single source of truth
 - **Defensive output encoding** — data is treated as untrusted when emitted into HTML, CSS, URLs, or inline scripts
@@ -277,6 +284,8 @@ Two fixed tools are always present regardless of config: `get_matrix` and `get_m
 
 See [VERIFICATION.md](VERIFICATION.md) for the deterministic checks, CI integration, and extension contract.
 
+External transferability has a documented evidence gate. If you are evaluating the generator for a real new domain, follow [ADOPTION.md](ADOPTION.md) and submit the included pilot report instead of treating repository traffic or a maintainer-led demo as proof of adoption.
+
 ## Ecosystem
 
 Knowledge as Code is part of a broader set of open standards:
 
@@ -0,0 +1,19 @@
+# Security Policy
+
+## Supported versions
+
+Security fixes target the latest tagged release and the `main` branch. Older releases may receive guidance but are not guaranteed patches.
+
+## Reporting a vulnerability
+
+Report vulnerabilities privately through [GitHub Security Advisories](https://github.com/snapsynapse/knowledge-as-code-template/security/advisories/new). Do not open a public issue for an unpatched vulnerability.
+
+Include the affected commit or version, reproduction steps, impact, and any proposed mitigation. Do not include real secrets or sensitive third-party data.
+
+There is no guaranteed response-time SLA. The maintainer will assess credible reports as capacity permits and will prioritize issues that can execute code, escape intended output boundaries, expose secrets, or produce unsafe generated content.
+
+## Scope
+
+The security scope includes the initializer, parsers, validator, generator, verifier, link checker, MCP server, and included GitHub Actions workflows.
+
+Domain accuracy, third-party source availability, downstream hosting configuration, external verifier implementations, and content added by forks are outside the repository's security guarantee.