diff --git a/ARCHITECTURE.adoc b/ARCHITECTURE.adoc
new file mode 100644
index 0000000..1c0a7a6
--- /dev/null
+++ b/ARCHITECTURE.adoc
@@ -0,0 +1,48 @@
+== Architecture
+
+=== Overview
+
+This repository follows a modular, maintainable architecture designed
+for clarity, scalability, and long-term sustainability.
+
+=== Directory Structure
+
+....
+.
+├── src/           # Source code
+├── tests/        # Test suites
+├── docs/         # Documentation
+├── scripts/      # Utility scripts
+├── config/       # Configuration files
+├── LICENSE       # License file
+├── LICENSES/     # Full license texts
+└── README.adoc   # Project documentation
+....
+
+=== Design Principles
+
+* *Separation of Concerns*: Each module has a single responsibility
+* *Testability*: Code is written to be easily testable
+* *Documentation*: All public APIs are documented
+* *Configuration*: Environment-specific settings are externalized
+
+=== Dependencies
+
+* External dependencies are minimized and clearly declared
+* Version pinning is used for reproducibility
+
+=== Security Considerations
+
+* Sensitive data is never committed to the repository
+* Secrets are managed through environment variables or secure vaults
+* Regular dependency audits are performed
+
+=== Maintainability
+
+* Code follows consistent style guidelines
+* Pull requests require review and CI checks
+* Issues and discussions are tracked transparently
+
+'''''
+
+_Last updated: 2026-07-18_
diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md
deleted file mode 100644
index 607e3d8..0000000
--- a/ARCHITECTURE.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Architecture
-
-## Overview
-
-This repository follows a modular, maintainable architecture designed for clarity, scalability, and long-term sustainability.
-
-## Directory Structure
-
-```
-.
-├── src/           # Source code
-├── tests/        # Test suites
-├── docs/         # Documentation
-├── scripts/      # Utility scripts
-├── config/       # Configuration files
-├── LICENSE       # License file
-├── LICENSES/     # Full license texts
-└── README.adoc   # Project documentation
-```
-
-## Design Principles
-
-- **Separation of Concerns**: Each module has a single responsibility
-- **Testability**: Code is written to be easily testable
-- **Documentation**: All public APIs are documented
-- **Configuration**: Environment-specific settings are externalized
-
-## Dependencies
-
-- External dependencies are minimized and clearly declared
-- Version pinning is used for reproducibility
-
-## Security Considerations
-
-- Sensitive data is never committed to the repository
-- Secrets are managed through environment variables or secure vaults
-- Regular dependency audits are performed
-
-## Maintainability
-
-- Code follows consistent style guidelines
-- Pull requests require review and CI checks
-- Issues and discussions are tracked transparently
-
----
-
-*Last updated: 2026-07-18*
diff --git a/CHANGELOG.adoc b/CHANGELOG.adoc
new file mode 100644
index 0000000..624d7bc
--- /dev/null
+++ b/CHANGELOG.adoc
@@ -0,0 +1,77 @@
+== Changelog
+
+All notable changes to `+nickel-augmentation+` will be documented in
+this file.
+
+This file is generated from conventional commits by the
+https://github.com/hyperpolymath/standards/blob/main/.github/workflows/changelog-reusable.yml[`+changelog-reusable.yml+`]
+workflow (`+hyperpolymath/standards#206+`). Adopt the workflow in this
+repo’s CI to keep this file in sync automatically — see
+https://github.com/hyperpolymath/standards/blob/main/templates/cliff.toml[`+templates/cliff.toml+`]
+for the canonical config.
+
+The format follows https://keepachangelog.com/en/1.1.0/[Keep a
+Changelog]; this project aims to follow
+https://semver.org/spec/v2.0.0.html[Semantic Versioning].
+
+=== [Unreleased]
+
+==== Added
+
+* feat(crg): add crg-grade and crg-badge justfile recipes
+* feat: nickel-augmentation 1.0.0 — proven bridge, K9 signatures, 48
+tests
+* feat: proven bridge — Nickel contracts backed by Idris2 formal proofs
+* feat: 7 new reporter rules, K9 runner, 29 integration tests
+* feat: add stapeln.toml container definition
+* feat: deploy UX Manifesto infrastructure
+* feat: add CLADE.a2ml — clade taxonomy declaration
+* feat: add Nickel contract library, config-reporter CLI, and wire
+Justfile
+* feat: add RSR template structure and project metadata
+* feat: consolidate nickel repos into nickel-augmentation monorepo
+
+==== Fixed
+
+* fix(ci): bump a2ml/k9-validate-action pins to canonical (standards#85)
+(#9)
+* fix(ci): sync hypatia-scan.yml to canonical (kill cd-scanner build
+drift) (#8)
+* fix(ci): build Hypatia escript from repo root (estate dogfood drift)
+* fix(ci): Phase-2 fleet submission must not fail the security gate (#5)
+* fix(ci): repair YAML block-scalar in workflow-linter Check Permissions
+step (#3)
+* fix(scorecard): enforce granular permissions and add fuzzing
+placeholder
+* fix(ci): Resolve workflow-linter self-matching and metadata issues
+* fix: correct email jonathan.jewell → j.d.a.jewell
+* fix: SPDX headers (AGPL→PMPL), email, author name
+
+==== Changed
+
+* refactor: migrate 6SCM → 6A2 (.scm → .a2ml format)
+
+==== Documentation
+
+* docs: substantive CRG C annotation (EXPLAINME.adoc)
+* docs: add TEST-NEEDS.md and/or PROOF-NEEDS.md from audit
+* docs: add EXPLAINME.adoc — prove-it file backing README claims
+
+==== CI
+
+* ci: redistribute concurrency-cancel guard to read-only check workflows
+(#12)
+* ci: fix nonexistent actions/upload-artifact SHA pin (#7)
+* ci: bump actions/upload-artifact SHA to current v4 (#2)
+* ci: SHA-pin hyperpolymath validate-actions in dogfood-gate
+* ci: restore Dependabot security path + wire auto-merge
+
+=== Pre-history
+
+Prior commits to this file’s introduction are recorded in git history
+but not formally classified into Keep-a-Changelog sections. To backfill,
+run `+git cliff -o CHANGELOG.md+` locally using the canonical
+https://github.com/hyperpolymath/standards/blob/main/templates/cliff.toml[`+cliff.toml+`]
+— this is one-shot mechanical work.
+
+'''''
diff --git a/CHANGELOG.md b/CHANGELOG.md
deleted file mode 100644
index 9310f7d..0000000
--- a/CHANGELOG.md
+++ /dev/null
@@ -1,70 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
--->
-
-# Changelog
-
-All notable changes to `nickel-augmentation` will be documented in this file.
-
-This file is generated from conventional commits by the
-[`changelog-reusable.yml`](https://github.com/hyperpolymath/standards/blob/main/.github/workflows/changelog-reusable.yml)
-workflow (`hyperpolymath/standards#206`). Adopt the workflow in this repo's CI to keep this file in sync automatically — see
-[`templates/cliff.toml`](https://github.com/hyperpolymath/standards/blob/main/templates/cliff.toml)
-for the canonical config.
-
-The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/);
-this project aims to follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
-
-## [Unreleased]
-
-### Added
-
-- feat(crg): add crg-grade and crg-badge justfile recipes
-- feat: nickel-augmentation 1.0.0 — proven bridge, K9 signatures, 48 tests
-- feat: proven bridge — Nickel contracts backed by Idris2 formal proofs
-- feat: 7 new reporter rules, K9 runner, 29 integration tests
-- feat: add stapeln.toml container definition
-- feat: deploy UX Manifesto infrastructure
-- feat: add CLADE.a2ml — clade taxonomy declaration
-- feat: add Nickel contract library, config-reporter CLI, and wire Justfile
-- feat: add RSR template structure and project metadata
-- feat: consolidate nickel repos into nickel-augmentation monorepo
-
-### Fixed
-
-- fix(ci): bump a2ml/k9-validate-action pins to canonical (standards#85) (#9)
-- fix(ci): sync hypatia-scan.yml to canonical (kill cd-scanner build drift) (#8)
-- fix(ci): build Hypatia escript from repo root (estate dogfood drift)
-- fix(ci): Phase-2 fleet submission must not fail the security gate (#5)
-- fix(ci): repair YAML block-scalar in workflow-linter Check Permissions step (#3)
-- fix(scorecard): enforce granular permissions and add fuzzing placeholder
-- fix(ci): Resolve workflow-linter self-matching and metadata issues
-- fix: correct email jonathan.jewell → j.d.a.jewell
-- fix: SPDX headers (AGPL→PMPL), email, author name
-
-### Changed
-
-- refactor: migrate 6SCM → 6A2 (.scm → .a2ml format)
-
-### Documentation
-
-- docs: substantive CRG C annotation (EXPLAINME.adoc)
-- docs: add TEST-NEEDS.md and/or PROOF-NEEDS.md from audit
-- docs: add EXPLAINME.adoc — prove-it file backing README claims
-
-### CI
-
-- ci: redistribute concurrency-cancel guard to read-only check workflows (#12)
-- ci: fix nonexistent actions/upload-artifact SHA pin (#7)
-- ci: bump actions/upload-artifact SHA to current v4 (#2)
-- ci: SHA-pin hyperpolymath validate-actions in dogfood-gate
-- ci: restore Dependabot security path + wire auto-merge
-
-## Pre-history
-
-Prior commits to this file's introduction are recorded in git history but not formally classified into Keep-a-Changelog sections. To backfill, run `git cliff -o CHANGELOG.md` locally using the canonical [`cliff.toml`](https://github.com/hyperpolymath/standards/blob/main/templates/cliff.toml) — this is one-shot mechanical work.
-
----
-
-<!-- This file was seeded by the 2026-05-26 estate tech-debt audit follow-up (Row-2 Phase 3); see [`hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md`](https://github.com/hyperpolymath/standards/blob/main/docs/audits/2026-05-26-estate-documentation-debt.md). -->
diff --git a/CODE_OF_CONDUCT.adoc b/CODE_OF_CONDUCT.adoc
new file mode 100644
index 0000000..207a717
--- /dev/null
+++ b/CODE_OF_CONDUCT.adoc
@@ -0,0 +1,340 @@
+== Code of Conduct
+
+=== Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in
+nickel-augmentation a harassment-free experience for everyone,
+regardless of age, body size, visible or invisible disability,
+ethnicity, sex characteristics, gender identity and expression, level of
+experience, education, socio-economic status, nationality, personal
+appearance, race, caste, colour, religion, or sexual identity and
+orientation.
+
+We pledge to act and interact in ways that contribute to an open,
+welcoming, diverse, inclusive, and healthy community.
+
+We recognise that a thriving open source community requires
+*psychological safety* — an environment where people can contribute, ask
+questions, make mistakes, and learn without fear of ridicule or
+retaliation.
+
+'''''
+
+=== Our Standards
+
+==== Expected Behaviour
+
+The following behaviours contribute to a positive environment:
+
+*Communication* - Using welcoming and inclusive language - Being
+respectful of differing viewpoints and experiences - Giving and
+gracefully accepting constructive feedback - Assuming good intent while
+addressing impact - Communicating clearly and patiently, especially with
+newcomers
+
+*Collaboration* - Focusing on what is best for the community - Showing
+empathy and kindness toward other community members - Being
+collaborative rather than competitive - Mentoring and supporting less
+experienced contributors - Celebrating others’ contributions and
+successes
+
+*Professionalism* - Accepting responsibility and apologising to those
+affected by our mistakes - Learning from the experience and avoiding
+repetition - Respecting others’ time and attention - Staying on topic in
+project spaces - Following project guidelines and conventions
+
+*Accessibility* - Using plain language and avoiding unnecessary jargon -
+Providing alt text for images and transcripts for audio/video - Being
+patient with those using assistive technologies - Accommodating
+different communication styles and needs - Recognising that not everyone
+communicates the same way
+
+==== Unacceptable Behaviour
+
+The following behaviours are considered harassment and are unacceptable:
+
+*Harassment* - The use of sexualised language or imagery, and sexual
+attention or advances of any kind - Trolling, insulting or derogatory
+comments, and personal or political attacks - Public or private
+harassment - Deliberate intimidation, stalking, or following (online or
+in-person) - Unwelcome physical contact or simulated physical contact
+(e.g., emoji) - Sustained disruption of talks, events, or online
+discussions
+
+*Discrimination* - Discriminatory jokes and language - Posting or
+threatening to post others’ personally identifying information
+("`doxing`") - Advocating for, or encouraging, any of the above
+behaviour - Microaggressions — subtle, often unintentional,
+discriminatory comments or actions
+
+*Professional Misconduct* - Publishing others’ private information
+without explicit permission - Misrepresenting affiliation or
+contributions - Plagiarism or claiming credit for others’ work -
+Retaliating against anyone who reports a Code of Conduct violation -
+Other conduct which could reasonably be considered inappropriate in a
+professional setting
+
+==== Grey Areas
+
+Some situations require judgement. When uncertain:
+
+* *Intent vs Impact*: Good intentions do not excuse harmful impact.
+Focus on making things right.
+* *Power Dynamics*: Those with more power (maintainers, employers,
+experienced contributors) must be especially mindful of their impact.
+* *Cultural Differences*: What’s acceptable varies by culture. When in
+doubt, err on the side of caution and ask.
+* *Humour*: Jokes at others’ expense are rarely funny to everyone. Punch
+up, not down.
+
+'''''
+
+=== Scope
+
+This Code of Conduct applies within all community spaces, including:
+
+*Online Spaces* - Repository discussions, issues, and pull/merge
+requests - Project chat channels (Matrix, Discord, Slack, IRC) - Mailing
+lists and forums - Social media when representing the project - Video
+calls and virtual meetings
+
+*In-Person Spaces* - Conferences, meetups, and events - Workshops and
+training sessions - Any gathering where you represent the project
+
+*Representation* This Code of Conduct also applies when an individual is
+officially representing the community in public spaces. Examples
+include:
+
+* Using an official project email address
+* Posting via an official social media account
+* Acting as an appointed representative at an event
+* Speaking on behalf of the project
+
+'''''
+
+=== Enforcement
+
+==== Reporting
+
+If you experience or witness unacceptable behaviour, or have any other
+concerns, please report it as soon as possible.
+
+*How to Report*
+
+[width="99%",cols="30%,33%,37%",options="header",]
+|===
+|Method |Details |Best For
+|*Email* |\{\{CONDUCT_EMAIL}} |Detailed reports, sensitive matters
+
+|*Private Message* |Contact any maintainer directly |Quick questions,
+minor issues
+
+|*Anonymous Form* |[Link to form if available] |When you need anonymity
+|===
+
+*What to Include*
+
+* Your contact information (unless anonymous)
+* Names/usernames of those involved
+* Description of what happened
+* When and where it occurred
+* Any witnesses
+* Any supporting evidence (screenshots, links)
+* How you would like us to respond (if you have a preference)
+
+*What Happens Next*
+
+[arabic]
+. You will receive acknowledgment within *\{\{RESPONSE_TIME}}*
+. The \{\{CONDUCT_TEAM}} will review the report
+. We may ask for additional information
+. We will determine appropriate action
+. We will inform you of the outcome (respecting others’ privacy)
+
+==== Confidentiality
+
+All reports will be handled with discretion:
+
+* Reporter identity is protected by default
+* Details are shared only with those who need to know
+* We will ask before naming you in any communication
+* Anonymous reports are accepted and investigated
+
+==== Conflicts of Interest
+
+If a \{\{CONDUCT_TEAM}} member is involved in an incident:
+
+* They will recuse themselves from the process
+* Another maintainer or external party will handle the report
+* We will disclose any potential conflicts
+
+'''''
+
+=== Enforcement Guidelines
+
+The \{\{CONDUCT_TEAM}} will follow these guidelines in determining
+consequences:
+
+==== 1. Correction
+
+*Community Impact*: Use of inappropriate language or other behaviour
+deemed unprofessional or unwelcome.
+
+*Consequence*: A private, written warning providing clarity around the
+nature of the violation and an explanation of why the behaviour was
+inappropriate. A public apology may be requested.
+
+*Duration*: Immediate
+
+==== 2. Warning
+
+*Community Impact*: A violation through a single incident or series of
+actions.
+
+*Consequence*: A warning with consequences for continued behaviour. No
+interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, for a specified period. This
+includes avoiding interactions in community spaces as well as external
+channels like social media. Violating these terms may lead to a
+temporary or permanent ban.
+
+*Duration*: 1-4 weeks
+
+==== 3. Temporary Ban
+
+*Community Impact*: A serious violation of community standards,
+including sustained inappropriate behaviour.
+
+*Consequence*: A temporary ban from any sort of interaction or public
+communication with the community for a specified period. No public or
+private interaction with the people involved, including unsolicited
+interaction with those enforcing the Code of Conduct, is allowed during
+this period. Violating these terms may lead to a permanent ban.
+
+*Duration*: 1-6 months
+
+==== 4. Permanent Ban
+
+*Community Impact*: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behaviour, harassment of an
+individual, or aggression toward or disparagement of classes of
+individuals.
+
+*Consequence*: A permanent ban from any sort of public interaction
+within the community.
+
+*Duration*: Permanent (with appeal rights after 12 months)
+
+==== Enforcement Across Perimeters
+
+For contributors with elevated access (Perimeter 2 or 1):
+
+[cols=",",options="header",]
+|===
+|Level |Additional Consequence
+|Correction |Noted in contributor record
+|Warning |Access privileges may be temporarily reduced
+|Temporary Ban |Access reduced to Perimeter 3 for ban duration
+|Permanent Ban |All access revoked
+|===
+
+'''''
+
+=== Appeals
+
+If you believe an enforcement decision was made in error:
+
+[arabic]
+. *Wait 7 days* after the decision (cooling-off period)
+. *Email* \{\{CONDUCT_EMAIL}} with subject line "`Appeal: [Original
+Report ID]`"
+. *Explain* why you believe the decision should be reconsidered
+. *Provide* any new information not previously available
+
+*Appeals Process*
+
+* Appeals are reviewed by a different \{\{CONDUCT_TEAM}} member than the
+original
+* You will receive a response within 14 days
+* The appeals decision is final
+* You may only appeal once per incident
+
+*Grounds for Appeal*
+
+* Procedural errors in the original investigation
+* New evidence not previously available
+* Disproportionate response to the violation
+* Misunderstanding of facts
+
+'''''
+
+=== Supporting Those Who Report
+
+We are committed to supporting those who report violations:
+
+*We Will* - Believe and take all reports seriously - Respect your
+privacy and confidentiality preferences - Keep you informed of progress
+(if you wish) - Take steps to protect you from retaliation - Provide
+resources if you need support
+
+*We Will Not* - Require you to confront the person directly - Dismiss
+reports without investigation - Reveal your identity without consent -
+Tolerate retaliation against reporters - Rush you to make decisions
+
+'''''
+
+=== Prevention
+
+Beyond enforcement, we actively work to prevent issues:
+
+*Onboarding* - All contributors are expected to read this Code of
+Conduct - Perimeter 2 applicants must confirm they’ve read and
+understood it - Maintainers receive additional training on enforcement
+
+*Culture* - We model the behaviour we expect - We intervene early when
+we see potential issues - We thank people for positive contributions -
+We create opportunities for diverse voices
+
+*Review* - This Code of Conduct is reviewed annually - Community
+feedback is welcomed - Changes are communicated clearly
+
+'''''
+
+=== Acknowledgments
+
+This Code of Conduct is adapted from:
+
+* https://www.contributor-covenant.org/[Contributor Covenant], version
+2.1
+* https://www.djangoproject.com/conduct/[Django Code of Conduct]
+* https://www.rust-lang.org/policies/code-of-conduct[Rust Code of
+Conduct]
+* https://www.python.org/psf/conduct/[Python Community Code of Conduct]
+
+We thank these communities for their leadership in creating welcoming
+spaces.
+
+'''''
+
+=== Questions?
+
+If you have questions about this Code of Conduct:
+
+* Open a
+https://github.com/hyperpolymath/nickel-augmentation/discussions[Discussion]
+(for general questions)
+* Email \{\{CONDUCT_EMAIL}} (for private questions)
+* Contact any maintainer directly
+
+'''''
+
+=== Summary
+
+*Be kind. Be respectful. Be collaborative.*
+
+We’re all here because we care about this project. Let’s make it a place
+where everyone can do their best work.
+
+'''''
+
+Last updated: 2026 · Based on Contributor Covenant 2.1
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
deleted file mode 100644
index ec72789..0000000
--- a/CODE_OF_CONDUCT.md
+++ /dev/null
@@ -1,331 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Code of Conduct
-
-<!-- 
-============================================================================
-TEMPLATE INSTRUCTIONS (delete this block before publishing)
-============================================================================
-Replace all {{PLACEHOLDER}} values:
-  nickel-augmentation     - Your project name
-  hyperpolymath            - GitHub/GitLab username or org
-  nickel-augmentation             - Repository name
-  {{CONDUCT_EMAIL}}    - Email for conduct reports
-  {{CONDUCT_TEAM}}     - Name of conduct team/committee
-  {{RESPONSE_TIME}}    - Initial response SLA (e.g., 48 hours)
-  2026     - Current year
-
-Review and customise:
-- Adjust enforcement ladder for your community size
-- Add/remove examples based on your context
-- Ensure contact methods work for your team
-============================================================================
--->
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in nickel-augmentation a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, colour, religion, or sexual identity and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
-
-We recognise that a thriving open source community requires **psychological safety** — an environment where people can contribute, ask questions, make mistakes, and learn without fear of ridicule or retaliation.
-
----
-
-## Our Standards
-
-### Expected Behaviour
-
-The following behaviours contribute to a positive environment:
-
-**Communication**
-- Using welcoming and inclusive language
-- Being respectful of differing viewpoints and experiences
-- Giving and gracefully accepting constructive feedback
-- Assuming good intent while addressing impact
-- Communicating clearly and patiently, especially with newcomers
-
-**Collaboration**
-- Focusing on what is best for the community
-- Showing empathy and kindness toward other community members
-- Being collaborative rather than competitive
-- Mentoring and supporting less experienced contributors
-- Celebrating others' contributions and successes
-
-**Professionalism**
-- Accepting responsibility and apologising to those affected by our mistakes
-- Learning from the experience and avoiding repetition
-- Respecting others' time and attention
-- Staying on topic in project spaces
-- Following project guidelines and conventions
-
-**Accessibility**
-- Using plain language and avoiding unnecessary jargon
-- Providing alt text for images and transcripts for audio/video
-- Being patient with those using assistive technologies
-- Accommodating different communication styles and needs
-- Recognising that not everyone communicates the same way
-
-### Unacceptable Behaviour
-
-The following behaviours are considered harassment and are unacceptable:
-
-**Harassment**
-- The use of sexualised language or imagery, and sexual attention or advances of any kind
-- Trolling, insulting or derogatory comments, and personal or political attacks
-- Public or private harassment
-- Deliberate intimidation, stalking, or following (online or in-person)
-- Unwelcome physical contact or simulated physical contact (e.g., emoji)
-- Sustained disruption of talks, events, or online discussions
-
-**Discrimination**
-- Discriminatory jokes and language
-- Posting or threatening to post others' personally identifying information ("doxing")
-- Advocating for, or encouraging, any of the above behaviour
-- Microaggressions — subtle, often unintentional, discriminatory comments or actions
-
-**Professional Misconduct**
-- Publishing others' private information without explicit permission
-- Misrepresenting affiliation or contributions
-- Plagiarism or claiming credit for others' work
-- Retaliating against anyone who reports a Code of Conduct violation
-- Other conduct which could reasonably be considered inappropriate in a professional setting
-
-### Grey Areas
-
-Some situations require judgement. When uncertain:
-
-- **Intent vs Impact**: Good intentions do not excuse harmful impact. Focus on making things right.
-- **Power Dynamics**: Those with more power (maintainers, employers, experienced contributors) must be especially mindful of their impact.
-- **Cultural Differences**: What's acceptable varies by culture. When in doubt, err on the side of caution and ask.
-- **Humour**: Jokes at others' expense are rarely funny to everyone. Punch up, not down.
-
----
-
-## Scope
-
-This Code of Conduct applies within all community spaces, including:
-
-**Online Spaces**
-- Repository discussions, issues, and pull/merge requests
-- Project chat channels (Matrix, Discord, Slack, IRC)
-- Mailing lists and forums
-- Social media when representing the project
-- Video calls and virtual meetings
-
-**In-Person Spaces**
-- Conferences, meetups, and events
-- Workshops and training sessions
-- Any gathering where you represent the project
-
-**Representation**
-This Code of Conduct also applies when an individual is officially representing the community in public spaces. Examples include:
-
-- Using an official project email address
-- Posting via an official social media account
-- Acting as an appointed representative at an event
-- Speaking on behalf of the project
-
----
-
-## Enforcement
-
-### Reporting
-
-If you experience or witness unacceptable behaviour, or have any other concerns, please report it as soon as possible.
-
-**How to Report**
-
-| Method | Details | Best For |
-|--------|---------|----------|
-| **Email** | {{CONDUCT_EMAIL}} | Detailed reports, sensitive matters |
-| **Private Message** | Contact any maintainer directly | Quick questions, minor issues |
-| **Anonymous Form** | [Link to form if available] | When you need anonymity |
-
-**What to Include**
-
-- Your contact information (unless anonymous)
-- Names/usernames of those involved
-- Description of what happened
-- When and where it occurred
-- Any witnesses
-- Any supporting evidence (screenshots, links)
-- How you would like us to respond (if you have a preference)
-
-**What Happens Next**
-
-1. You will receive acknowledgment within **{{RESPONSE_TIME}}**
-2. The {{CONDUCT_TEAM}} will review the report
-3. We may ask for additional information
-4. We will determine appropriate action
-5. We will inform you of the outcome (respecting others' privacy)
-
-### Confidentiality
-
-All reports will be handled with discretion:
-
-- Reporter identity is protected by default
-- Details are shared only with those who need to know
-- We will ask before naming you in any communication
-- Anonymous reports are accepted and investigated
-
-### Conflicts of Interest
-
-If a {{CONDUCT_TEAM}} member is involved in an incident:
-
-- They will recuse themselves from the process
-- Another maintainer or external party will handle the report
-- We will disclose any potential conflicts
-
----
-
-## Enforcement Guidelines
-
-The {{CONDUCT_TEAM}} will follow these guidelines in determining consequences:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome.
-
-**Consequence**: A private, written warning providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested.
-
-**Duration**: Immediate
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series of actions.
-
-**Consequence**: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
-
-**Duration**: 1-4 weeks
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including sustained inappropriate behaviour.
-
-**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
-
-**Duration**: 1-6 months
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within the community.
-
-**Duration**: Permanent (with appeal rights after 12 months)
-
-### Enforcement Across Perimeters
-
-For contributors with elevated access (Perimeter 2 or 1):
-
-| Level | Additional Consequence |
-|-------|----------------------|
-| Correction | Noted in contributor record |
-| Warning | Access privileges may be temporarily reduced |
-| Temporary Ban | Access reduced to Perimeter 3 for ban duration |
-| Permanent Ban | All access revoked |
-
----
-
-## Appeals
-
-If you believe an enforcement decision was made in error:
-
-1. **Wait 7 days** after the decision (cooling-off period)
-2. **Email** {{CONDUCT_EMAIL}} with subject line "Appeal: [Original Report ID]"
-3. **Explain** why you believe the decision should be reconsidered
-4. **Provide** any new information not previously available
-
-**Appeals Process**
-
-- Appeals are reviewed by a different {{CONDUCT_TEAM}} member than the original
-- You will receive a response within 14 days
-- The appeals decision is final
-- You may only appeal once per incident
-
-**Grounds for Appeal**
-
-- Procedural errors in the original investigation
-- New evidence not previously available
-- Disproportionate response to the violation
-- Misunderstanding of facts
-
----
-
-## Supporting Those Who Report
-
-We are committed to supporting those who report violations:
-
-**We Will**
-- Believe and take all reports seriously
-- Respect your privacy and confidentiality preferences
-- Keep you informed of progress (if you wish)
-- Take steps to protect you from retaliation
-- Provide resources if you need support
-
-**We Will Not**
-- Require you to confront the person directly
-- Dismiss reports without investigation
-- Reveal your identity without consent
-- Tolerate retaliation against reporters
-- Rush you to make decisions
-
----
-
-## Prevention
-
-Beyond enforcement, we actively work to prevent issues:
-
-**Onboarding**
-- All contributors are expected to read this Code of Conduct
-- Perimeter 2 applicants must confirm they've read and understood it
-- Maintainers receive additional training on enforcement
-
-**Culture**
-- We model the behaviour we expect
-- We intervene early when we see potential issues
-- We thank people for positive contributions
-- We create opportunities for diverse voices
-
-**Review**
-- This Code of Conduct is reviewed annually
-- Community feedback is welcomed
-- Changes are communicated clearly
-
----
-
-## Acknowledgments
-
-This Code of Conduct is adapted from:
-
-- [Contributor Covenant](https://www.contributor-covenant.org/), version 2.1
-- [Django Code of Conduct](https://www.djangoproject.com/conduct/)
-- [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct)
-- [Python Community Code of Conduct](https://www.python.org/psf/conduct/)
-
-We thank these communities for their leadership in creating welcoming spaces.
-
----
-
-## Questions?
-
-If you have questions about this Code of Conduct:
-
-- Open a [Discussion](https://github.com/hyperpolymath/nickel-augmentation/discussions) (for general questions)
-- Email {{CONDUCT_EMAIL}} (for private questions)
-- Contact any maintainer directly
-
----
-
-## Summary
-
-**Be kind. Be respectful. Be collaborative.**
-
-We're all here because we care about this project. Let's make it a place where everyone can do their best work.
-
----
-
-<sub>Last updated: 2026 · Based on Contributor Covenant 2.1</sub>
diff --git a/CONTRIBUTING.adoc b/CONTRIBUTING.adoc
new file mode 100644
index 0000000..610ec53
--- /dev/null
+++ b/CONTRIBUTING.adoc
@@ -0,0 +1,109 @@
+== Clone the repository
+
+git clone https://github.com/hyperpolymath/nickel-augmentation.git cd
+nickel-augmentation
+
+== Using Nix (recommended for reproducibility)
+
+nix develop
+
+== Or using toolbox/distrobox
+
+toolbox create nickel-augmentation-dev toolbox enter
+nickel-augmentation-dev # Install dependencies manually
+
+== Verify setup
+
+just check # or: cargo check / mix compile / etc. just test # Run test
+suite
+
+....
+
+### Repository Structure
+....
+
+nickel-augmentation/ ├── src/ # Source code (Perimeter 1-2) ├── lib/ #
+Library code (Perimeter 1-2) ├── extensions/ # Extensions (Perimeter 2)
+├── plugins/ # Plugins (Perimeter 2) ├── tools/ # Tooling (Perimeter 2)
+├── docs/ # Documentation (Perimeter 3) │ ├── architecture/ # ADRs,
+specs (Perimeter 2) │ └── proposals/ # RFCs (Perimeter 3) ├── examples/
+# Examples (Perimeter 3) ├── spec/ # Spec tests (Perimeter 3) ├── tests/
+# Test suite (Perimeter 2-3) ├── .well-known/ # Protocol files
+(Perimeter 1-3) ├── .github/ # GitHub config (Perimeter 1) │ ├──
+ISSUE_TEMPLATE/ │ └── workflows/ ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md
+├── CONTRIBUTING.md # This file ├── GOVERNANCE.md ├── LICENSE ├──
+MAINTAINERS.md ├── README.adoc ├── SECURITY.md ├── flake.nix # Nix flake
+(Perimeter 1) └── Justfile # Task runner (Perimeter 1)
+
+....
+
+---
+
+## How to Contribute
+
+### Reporting Bugs
+
+**Before reporting**:
+1. Search existing issues
+2. Check if it's already fixed in `main`
+3. Determine which perimeter the bug affects
+
+**When reporting**:
+
+Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
+
+- Clear, descriptive title
+- Environment details (OS, versions, toolchain)
+- Steps to reproduce
+- Expected vs actual behaviour
+- Logs, screenshots, or minimal reproduction
+
+### Suggesting Features
+
+**Before suggesting**:
+1. Check the [roadmap](ROADMAP.md) if available
+2. Search existing issues and discussions
+3. Consider which perimeter the feature belongs to
+
+**When suggesting**:
+
+Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
+
+- Problem statement (what pain point does this solve?)
+- Proposed solution
+- Alternatives considered
+- Which perimeter this affects
+
+### Your First Contribution
+
+Look for issues labelled:
+
+- [`good first issue`](https://github.com/hyperpolymath/nickel-augmentation/labels/good%20first%20issue) — Simple Perimeter 3 tasks
+- [`help wanted`](https://github.com/hyperpolymath/nickel-augmentation/labels/help%20wanted) — Community help needed
+- [`documentation`](https://github.com/hyperpolymath/nickel-augmentation/labels/documentation) — Docs improvements
+- [`perimeter-3`](https://github.com/hyperpolymath/nickel-augmentation/labels/perimeter-3) — Community sandbox scope
+
+---
+
+## Development Workflow
+
+### Branch Naming
+....
+
+docs/short-description # Documentation (P3) test/what-added # Test
+additions (P3) feat/short-description # New features (P2)
+fix/issue-number-description # Bug fixes (P2) refactor/what-changed #
+Code improvements (P2) security/what-fixed # Security fixes (P1-2)
+
+....
+
+### Commit Messages
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/):
+....
+
+():
+
+{empty}[optional body]
+
+{empty}[optional footer]
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index e220e66..0000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,120 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Clone the repository
-git clone https://github.com/hyperpolymath/nickel-augmentation.git
-cd nickel-augmentation
-
-# Using Nix (recommended for reproducibility)
-nix develop
-
-# Or using toolbox/distrobox
-toolbox create nickel-augmentation-dev
-toolbox enter nickel-augmentation-dev
-# Install dependencies manually
-
-# Verify setup
-just check   # or: cargo check / mix compile / etc.
-just test    # Run test suite
-```
-
-### Repository Structure
-```
-nickel-augmentation/
-├── src/                 # Source code (Perimeter 1-2)
-├── lib/                 # Library code (Perimeter 1-2)
-├── extensions/          # Extensions (Perimeter 2)
-├── plugins/             # Plugins (Perimeter 2)
-├── tools/               # Tooling (Perimeter 2)
-├── docs/                # Documentation (Perimeter 3)
-│   ├── architecture/    # ADRs, specs (Perimeter 2)
-│   └── proposals/       # RFCs (Perimeter 3)
-├── examples/            # Examples (Perimeter 3)
-├── spec/                # Spec tests (Perimeter 3)
-├── tests/               # Test suite (Perimeter 2-3)
-├── .well-known/         # Protocol files (Perimeter 1-3)
-├── .github/             # GitHub config (Perimeter 1)
-│   ├── ISSUE_TEMPLATE/
-│   └── workflows/
-├── CHANGELOG.md
-├── CODE_OF_CONDUCT.md
-├── CONTRIBUTING.md      # This file
-├── GOVERNANCE.md
-├── LICENSE
-├── MAINTAINERS.md
-├── README.adoc
-├── SECURITY.md
-├── flake.nix            # Nix flake (Perimeter 1)
-└── Justfile             # Task runner (Perimeter 1)
-```
-
----
-
-## How to Contribute
-
-### Reporting Bugs
-
-**Before reporting**:
-1. Search existing issues
-2. Check if it's already fixed in `main`
-3. Determine which perimeter the bug affects
-
-**When reporting**:
-
-Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
-
-- Clear, descriptive title
-- Environment details (OS, versions, toolchain)
-- Steps to reproduce
-- Expected vs actual behaviour
-- Logs, screenshots, or minimal reproduction
-
-### Suggesting Features
-
-**Before suggesting**:
-1. Check the [roadmap](ROADMAP.md) if available
-2. Search existing issues and discussions
-3. Consider which perimeter the feature belongs to
-
-**When suggesting**:
-
-Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
-
-- Problem statement (what pain point does this solve?)
-- Proposed solution
-- Alternatives considered
-- Which perimeter this affects
-
-### Your First Contribution
-
-Look for issues labelled:
-
-- [`good first issue`](https://github.com/hyperpolymath/nickel-augmentation/labels/good%20first%20issue) — Simple Perimeter 3 tasks
-- [`help wanted`](https://github.com/hyperpolymath/nickel-augmentation/labels/help%20wanted) — Community help needed
-- [`documentation`](https://github.com/hyperpolymath/nickel-augmentation/labels/documentation) — Docs improvements
-- [`perimeter-3`](https://github.com/hyperpolymath/nickel-augmentation/labels/perimeter-3) — Community sandbox scope
-
----
-
-## Development Workflow
-
-### Branch Naming
-```
-docs/short-description       # Documentation (P3)
-test/what-added              # Test additions (P3)
-feat/short-description       # New features (P2)
-fix/issue-number-description # Bug fixes (P2)
-refactor/what-changed        # Code improvements (P2)
-security/what-fixed          # Security fixes (P1-2)
-```
-
-### Commit Messages
-
-We follow [Conventional Commits](https://www.conventionalcommits.org/):
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer]
diff --git a/GOVERNANCE.adoc b/GOVERNANCE.adoc
new file mode 100644
index 0000000..9b836fb
--- /dev/null
+++ b/GOVERNANCE.adoc
@@ -0,0 +1,60 @@
+== Governance
+
+=== Overview
+
+This project is governed by the following principles and structures to
+ensure transparent, inclusive, and effective decision-making.
+
+=== Roles and Responsibilities
+
+==== Maintainers
+
+Maintainers are responsible for: - Reviewing and merging pull requests -
+Managing releases and versioning - Ensuring code quality and standards -
+Triaging issues and bug reports - Community engagement and support
+
+==== Contributors
+
+Contributors are expected to: - Follow the code of conduct - Submit
+well-documented pull requests - Write tests for new functionality -
+Maintain existing tests - Update documentation as needed
+
+=== Decision Making
+
+==== Minor Changes
+
+* Can be made by any maintainer
+* Include bug fixes, documentation updates, dependency updates
+
+==== Major Changes
+
+* Require discussion in issues or pull requests
+* Include new features, architectural changes, API changes
+* Need approval from at least 2 maintainers
+
+==== Breaking Changes
+
+* Require RFC (Request for Comments) process
+* Need approval from majority of maintainers
+* Must include migration guide
+
+=== Code of Conduct
+
+All participants are expected to follow our Code of Conduct. Violations
+can be reported to the maintainers.
+
+=== Communication
+
+* *Issues*: For bug reports and feature requests
+* *Discussions*: For questions and general discussion
+* *Pull Requests*: For code contributions
+
+=== Licensing
+
+All contributions are made under the terms of the repository’s LICENSE
+file. By submitting a pull request, you agree to license your
+contributions accordingly.
+
+'''''
+
+_Last updated: 2026-07-18_
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
deleted file mode 100644
index e27364c..0000000
--- a/GOVERNANCE.md
+++ /dev/null
@@ -1,60 +0,0 @@
-# Governance
-
-## Overview
-
-This project is governed by the following principles and structures to ensure transparent, inclusive, and effective decision-making.
-
-## Roles and Responsibilities
-
-### Maintainers
-
-Maintainers are responsible for:
-- Reviewing and merging pull requests
-- Managing releases and versioning
-- Ensuring code quality and standards
-- Triaging issues and bug reports
-- Community engagement and support
-
-### Contributors
-
-Contributors are expected to:
-- Follow the code of conduct
-- Submit well-documented pull requests
-- Write tests for new functionality
-- Maintain existing tests
-- Update documentation as needed
-
-## Decision Making
-
-### Minor Changes
-- Can be made by any maintainer
-- Include bug fixes, documentation updates, dependency updates
-
-### Major Changes
-- Require discussion in issues or pull requests
-- Include new features, architectural changes, API changes
-- Need approval from at least 2 maintainers
-
-### Breaking Changes
-- Require RFC (Request for Comments) process
-- Need approval from majority of maintainers
-- Must include migration guide
-
-## Code of Conduct
-
-All participants are expected to follow our Code of Conduct. Violations can be reported to the maintainers.
-
-## Communication
-
-- **Issues**: For bug reports and feature requests
-- **Discussions**: For questions and general discussion
-- **Pull Requests**: For code contributions
-
-## Licensing
-
-All contributions are made under the terms of the repository's LICENSE file.
-By submitting a pull request, you agree to license your contributions accordingly.
-
----
-
-*Last updated: 2026-07-18*
diff --git a/MAINTAINERS.adoc b/MAINTAINERS.adoc
index daf8a78..59ca2fd 100644
--- a/MAINTAINERS.adoc
+++ b/MAINTAINERS.adoc
@@ -1,65 +1,52 @@
-// SPDX-License-Identifier: CC-BY-SA-4.0
-// SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
-= Maintainers
-:toc: preamble
+// SPDX-License-Identifier: CC-BY-SA-4.0 = Maintainers :toc: preamble
+
+This document lists the maintainers of this project and their
+responsibilities.
 
 == Current Maintainers
 
-[cols="2,3,2",options="header"]
-|===
-| Name | Role | Contact
+[cols="`2,3,2`",options="`header`"] |=== | Name | Role | Contact
+
+[verse]
+--
+Jonathan D.A. Jewell
+Lead Maintainer
+https://github.com/hyperpolymath[@hyperpolymath]
+--
 
-| Jonathan D.A. Jewell | Sole Maintainer | https://github.com/hyperpolymath[@hyperpolymath]
 |===
 
-== Maintainer Responsibilities
+== Responsibilities
 
-As the sole maintainer, all responsibilities apply to @hyperpolymath:
+Maintainers are responsible for:
 
 * Reviewing and merging pull requests
 * Triaging issues and feature requests
 * Ensuring code quality and security standards
 * Managing releases and versioning
-* Upholding the project's Code of Conduct
-* Maintaining documentation and examples
-* Responding to security vulnerabilities
+* Upholding the project’s code of conduct
 
-== Contribution Process
+== Becoming a Maintainer
 
-This is a sole-maintainer project. All contributions are welcome via:
+Contributors who demonstrate:
 
-1. **Issues**: Report bugs, request features, ask questions
-2. **Pull Requests**: Submit improvements for review
-3. **Discussions**: Engage in community discussions
+* Consistent, high-quality contributions
+* Understanding of the project’s goals and standards
+* Constructive participation in discussions
+* Commitment to the project’s long-term health
 
-All contributions will be reviewed by the maintainer.
+May be invited to become maintainers at the discretion of existing
+maintainers.
 
 == Decision Making
 
-* Routine decisions (bug fixes, minor improvements): Made by maintainer
-* Significant changes: Discussed in issues before implementation
-* Breaking changes: Announced in advance with migration path
-
-== Becoming a Maintainer
-
-This project currently has a single maintainer. If you're interested in becoming a co-maintainer:
-
-1. Demonstrate consistent, high-quality contributions
-2. Show understanding of project goals and standards
-3. Participate constructively in discussions
-4. Express interest to the current maintainer
-
-Co-maintainers may be added at the discretion of the current maintainer.
+* Routine decisions (bug fixes, minor improvements) can be made by any
+maintainer
+* Significant changes require discussion and consensus among maintainers
+* Breaking changes or major features should be discussed in issues
+before implementation
 
 == Contact
 
-For questions about project governance:
-
-* Open a GitHub issue in this repository
-* Contact: https://github.com/hyperpolymath
-
-== See Also
-
-* link:GOVERNANCE.adoc[Governance Model]
-* link:CODE_OF_CONDUCT.md[Code of Conduct]
-* link:CONTRIBUTING.adoc[Contributing Guide]
+For questions about project governance, open an issue or contact the
+maintainers listed above.
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
deleted file mode 100644
index ab5b55b..0000000
--- a/MAINTAINERS.md
+++ /dev/null
@@ -1,51 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-// SPDX-License-Identifier: CC-BY-SA-4.0
-= Maintainers
-:toc: preamble
-
-This document lists the maintainers of this project and their responsibilities.
-
-== Current Maintainers
-
-[cols="2,3,2",options="header"]
-|===
-| Name | Role | Contact
-
-| Jonathan D.A. Jewell
-| Lead Maintainer
-| https://github.com/hyperpolymath[@hyperpolymath]
-|===
-
-== Responsibilities
-
-Maintainers are responsible for:
-
-* Reviewing and merging pull requests
-* Triaging issues and feature requests
-* Ensuring code quality and security standards
-* Managing releases and versioning
-* Upholding the project's code of conduct
-
-== Becoming a Maintainer
-
-Contributors who demonstrate:
-
-* Consistent, high-quality contributions
-* Understanding of the project's goals and standards
-* Constructive participation in discussions
-* Commitment to the project's long-term health
-
-May be invited to become maintainers at the discretion of existing maintainers.
-
-== Decision Making
-
-* Routine decisions (bug fixes, minor improvements) can be made by any maintainer
-* Significant changes require discussion and consensus among maintainers
-* Breaking changes or major features should be discussed in issues before implementation
-
-== Contact
-
-For questions about project governance, open an issue or contact the maintainers listed above.
diff --git a/PROOF-NEEDS.adoc b/PROOF-NEEDS.adoc
new file mode 100644
index 0000000..9513a5e
--- /dev/null
+++ b/PROOF-NEEDS.adoc
@@ -0,0 +1,39 @@
+== PROOF-NEEDS.md — nickel-augmentation
+
+=== Current State
+
+* **src/abi/*.idr**: NO
+* *Dangerous patterns*: 0 (2 references are in proven.ncl documenting
+the believe_me_count = 0 invariant)
+* *LOC*: ~5,900 (Nickel)
+* *ABI layer*: Missing
+
+=== What Needs Proving
+
+[width="100%",cols="51%,27%,22%",options="header",]
+|===
+|Component |What |Why
+|Contract validation |Nickel contracts correctly enforce RSR policies
+|Wrong contract validation passes non-compliant configs
+
+|Proven integration |proven.ncl accurately reflects proven library state
+|Stale proven metadata gives false confidence
+
+|Config reporter |Reporter correctly identifies all policy violations
+|Missed violations bypass security/language policy
+
+|Augmentation composition |Augmented configs compose correctly
+|Composition bugs produce invalid merged configs
+|===
+
+=== Recommended Prover
+
+*Idris2* — Create `+src/abi/+` with types for contract composition.
+Nickel’s own contract system provides some safety, but the RSR policy
+enforcement logic needs formal backing.
+
+=== Priority
+
+*LOW* — Configuration tooling. Nickel’s type system provides some
+guarantees already. The main gap is proving that RSR policy contracts
+are complete (no bypass paths).
diff --git a/PROOF-NEEDS.md b/PROOF-NEEDS.md
deleted file mode 100644
index 892f486..0000000
--- a/PROOF-NEEDS.md
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# PROOF-NEEDS.md — nickel-augmentation
-
-## Current State
-
-- **src/abi/*.idr**: NO
-- **Dangerous patterns**: 0 (2 references are in proven.ncl documenting the believe_me_count = 0 invariant)
-- **LOC**: ~5,900 (Nickel)
-- **ABI layer**: Missing
-
-## What Needs Proving
-
-| Component | What | Why |
-|-----------|------|-----|
-| Contract validation | Nickel contracts correctly enforce RSR policies | Wrong contract validation passes non-compliant configs |
-| Proven integration | proven.ncl accurately reflects proven library state | Stale proven metadata gives false confidence |
-| Config reporter | Reporter correctly identifies all policy violations | Missed violations bypass security/language policy |
-| Augmentation composition | Augmented configs compose correctly | Composition bugs produce invalid merged configs |
-
-## Recommended Prover
-
-**Idris2** — Create `src/abi/` with types for contract composition. Nickel's own contract system provides some safety, but the RSR policy enforcement logic needs formal backing.
-
-## Priority
-
-**LOW** — Configuration tooling. Nickel's type system provides some guarantees already. The main gap is proving that RSR policy contracts are complete (no bypass paths).
diff --git a/SECURITY.adoc b/SECURITY.adoc
new file mode 100644
index 0000000..59699d3
--- /dev/null
+++ b/SECURITY.adoc
@@ -0,0 +1,453 @@
+== Security Policy
+
+We take security seriously. We appreciate your efforts to responsibly
+disclose vulnerabilities and will make every effort to acknowledge your
+contributions.
+
+=== Table of Contents
+
+* link:#reporting-a-vulnerability[Reporting a Vulnerability]
+* link:#what-to-include[What to Include]
+* link:#response-timeline[Response Timeline]
+* link:#disclosure-policy[Disclosure Policy]
+* link:#scope[Scope]
+* link:#safe-harbour[Safe Harbour]
+* link:#recognition[Recognition]
+* link:#security-updates[Security Updates]
+* link:#security-best-practices[Security Best Practices]
+
+'''''
+
+=== Reporting a Vulnerability
+
+==== Preferred Method: GitHub Security Advisories
+
+The preferred method for reporting security vulnerabilities is through
+GitHub’s Security Advisory feature:
+
+[arabic]
+. Navigate to
+https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new[Report
+a Vulnerability]
+. Click *"`Report a vulnerability`"*
+. Complete the form with as much detail as possible
+. Submit — we’ll receive a private notification
+
+This method ensures:
+
+* End-to-end encryption of your report
+* Private discussion space for collaboration
+* Coordinated disclosure tooling
+* Automatic credit when the advisory is published
+
+==== Alternative: Encrypted Email
+
+If you cannot use GitHub Security Advisories, you may email us directly:
+
+[width="100%",cols="50%,50%",]
+|===
+|*Email* |j.d.a.jewell@open.ac.uk
+|*PGP Key* |https://hyperpolymath.github.io/pgp.asc[Download Public Key]
+|*Fingerprint* |`+TBD+`
+|===
+
+[source,bash]
+----
+# Import our PGP key
+curl -sSL https://hyperpolymath.github.io/pgp.asc | gpg --import
+
+# Verify fingerprint
+gpg --fingerprint j.d.a.jewell@open.ac.uk
+
+# Encrypt your report
+gpg --armor --encrypt --recipient j.d.a.jewell@open.ac.uk report.txt
+----
+
+____
+*⚠️ Important:* Do not report security vulnerabilities through public
+GitHub issues, pull requests, discussions, or social media.
+____
+
+'''''
+
+=== What to Include
+
+A good vulnerability report helps us understand and reproduce the issue
+quickly.
+
+==== Required Information
+
+* *Description*: Clear explanation of the vulnerability
+* *Impact*: What an attacker could achieve (confidentiality, integrity,
+availability)
+* *Affected versions*: Which versions/commits are affected
+* *Reproduction steps*: Detailed steps to reproduce the issue
+
+==== Helpful Additional Information
+
+* *Proof of concept*: Code, scripts, or screenshots demonstrating the
+vulnerability
+* *Attack scenario*: Realistic attack scenario showing exploitability
+* *CVSS score*: Your assessment of severity (use
+https://www.first.org/cvss/calculator/3.1[CVSS 3.1 Calculator])
+* *CWE ID*: Common Weakness Enumeration identifier if known
+* *Suggested fix*: If you have ideas for remediation
+* *References*: Links to related vulnerabilities, research, or
+advisories
+
+==== Example Report Structure
+
+[source,markdown]
+----
+## Summary
+[One-sentence description of the vulnerability]
+
+## Vulnerability Type
+[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
+
+## Affected Component
+[File path, function name, API endpoint, etc.]
+
+## Affected Versions
+[Version range or specific commits]
+
+## Severity Assessment
+- CVSS 3.1 Score: [X.X]
+- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
+
+## Description
+[Detailed technical description]
+
+## Steps to Reproduce
+1. [First step]
+2. [Second step]
+3. [...]
+
+## Proof of Concept
+[Code, curl commands, screenshots, etc.]
+
+## Impact
+[What can an attacker achieve?]
+
+## Suggested Remediation
+[Optional: your ideas for fixing]
+
+## References
+[Links to related issues, CVEs, research]
+----
+
+'''''
+
+=== Response Timeline
+
+We commit to the following response times:
+
+[width="100%",cols="24%,35%,41%",options="header",]
+|===
+|Stage |Timeframe |Description
+|*Initial Response* |48 hours |We acknowledge receipt and confirm we’re
+investigating
+
+|*Triage* |7 days |We assess severity, confirm the vulnerability, and
+estimate timeline
+
+|*Status Update* |Every 7 days |Regular updates on remediation progress
+
+|*Resolution* |90 days |Target for fix development and release (complex
+issues may take longer)
+
+|*Disclosure* |90 days |Public disclosure after fix is available
+(coordinated with you)
+|===
+
+____
+*Note:* These are targets, not guarantees. Complex vulnerabilities may
+require more time. We’ll communicate openly about any delays.
+____
+
+'''''
+
+=== Disclosure Policy
+
+We follow *coordinated disclosure* (also known as responsible
+disclosure):
+
+[arabic]
+. *You report* the vulnerability privately
+. *We acknowledge* and begin investigation
+. *We develop* a fix and prepare a release
+. *We coordinate* disclosure timing with you
+. *We publish* security advisory and fix simultaneously
+. *You may publish* your research after disclosure
+
+==== Our Commitments
+
+* We will not take legal action against researchers who follow this
+policy
+* We will work with you to understand and resolve the issue
+* We will credit you in the security advisory (unless you prefer
+anonymity)
+* We will notify you before public disclosure
+* We will publish advisories with sufficient detail for users to assess
+risk
+
+==== Your Commitments
+
+* Report vulnerabilities promptly after discovery
+* Give us reasonable time to address the issue before disclosure
+* Do not access, modify, or delete data beyond what’s necessary to
+demonstrate the vulnerability
+* Do not degrade service availability (no DoS testing on production)
+* Do not share vulnerability details with others until coordinated
+disclosure
+
+==== Disclosure Timeline
+
+....
+Day 0          You report vulnerability
+Day 1-2        We acknowledge receipt
+Day 7          We confirm vulnerability and share initial assessment
+Day 7-90       We develop and test fix
+Day 90         Coordinated public disclosure
+               (earlier if fix is ready; later by mutual agreement)
+....
+
+If we cannot reach agreement on disclosure timing, we default to 90 days
+from your initial report.
+
+'''''
+
+=== Scope
+
+==== In Scope ✅
+
+The following are within scope for security research:
+
+* This repository (`+hyperpolymath/nickel-augmentation+`) and all its
+code
+* Official releases and packages published from this repository
+* Documentation that could lead to security issues
+* Build and deployment configurations in this repository
+* Dependencies (report here, we’ll coordinate with upstream)
+
+==== Out of Scope ❌
+
+The following are *not* in scope:
+
+* Third-party services we integrate with (report directly to them)
+* Social engineering attacks against maintainers
+* Physical security
+* Denial of service attacks against production infrastructure
+* Spam, phishing, or other non-technical attacks
+* Issues already reported or publicly known
+* Theoretical vulnerabilities without proof of concept
+
+==== Qualifying Vulnerabilities
+
+We’re particularly interested in:
+
+* Remote code execution
+* SQL injection, command injection, code injection
+* Authentication/authorisation bypass
+* Cross-site scripting (XSS) and cross-site request forgery (CSRF)
+* Server-side request forgery (SSRF)
+* Path traversal / local file inclusion
+* Information disclosure (credentials, PII, secrets)
+* Cryptographic weaknesses
+* Deserialisation vulnerabilities
+* Memory safety issues (buffer overflows, use-after-free, etc.)
+* Supply chain vulnerabilities (dependency confusion, etc.)
+* Significant logic flaws
+
+==== Non-Qualifying Issues
+
+The following generally do not qualify as security vulnerabilities:
+
+* Missing security headers on non-sensitive pages
+* Clickjacking on pages without sensitive actions
+* Self-XSS (requires victim to paste code)
+* Missing rate limiting (unless it enables a specific attack)
+* Username/email enumeration (unless high-risk context)
+* Missing cookie flags on non-sensitive cookies
+* Software version disclosure
+* Verbose error messages (unless exposing secrets)
+* Best practice deviations without demonstrable impact
+
+'''''
+
+=== Safe Harbour
+
+We support security research conducted in good faith.
+
+==== Our Promise
+
+If you conduct security research in accordance with this policy:
+
+* ✅ We will not initiate legal action against you
+* ✅ We will not report your activity to law enforcement
+* ✅ We will work with you in good faith to resolve issues
+* ✅ We consider your research authorised under the Computer Fraud and
+Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
+* ✅ We waive any potential claim against you for circumvention of
+security controls
+
+==== Good Faith Requirements
+
+To qualify for safe harbour, you must:
+
+* Comply with this security policy
+* Report vulnerabilities promptly
+* Avoid privacy violations (do not access others’ data)
+* Avoid service degradation (no destructive testing)
+* Not exploit vulnerabilities beyond proof-of-concept
+* Not use vulnerabilities for profit (beyond bug bounties where offered)
+
+____
+*⚠️ Important:* This safe harbour does not extend to third-party
+systems. Always check their policies before testing.
+____
+
+'''''
+
+=== Recognition
+
+We believe in recognising security researchers who help us improve.
+
+==== Hall of Fame
+
+Researchers who report valid vulnerabilities will be acknowledged in our
+link:SECURITY-ACKNOWLEDGMENTS.md[Security Acknowledgments] (unless they
+prefer anonymity).
+
+Recognition includes:
+
+* Your name (or chosen alias)
+* Link to your website/profile (optional)
+* Brief description of the vulnerability class
+* Date of report
+
+==== What We Offer
+
+* ✅ Public credit in security advisories
+* ✅ Acknowledgment in release notes
+* ✅ Entry in our Hall of Fame
+* ✅ Reference/recommendation letter upon request (for significant
+findings)
+
+==== What We Don’t Currently Offer
+
+* ❌ Monetary bug bounties
+* ❌ Hardware or swag
+* ❌ Paid security research contracts
+
+____
+*Note:* We’re a community project with limited resources. Your
+contributions help everyone who uses this software.
+____
+
+'''''
+
+=== Security Updates
+
+==== Receiving Updates
+
+To stay informed about security updates:
+
+* *Watch this repository*: Click "`Watch`" → "`Custom`" → Select
+"`Security alerts`"
+* *GitHub Security Advisories*: Published at
+https://github.com/hyperpolymath/nickel-augmentation/security/advisories[Security
+Advisories]
+* *Release notes*: Security fixes noted in link:CHANGELOG.md[CHANGELOG]
+
+==== Update Policy
+
+[cols=",",options="header",]
+|===
+|Severity |Response
+|*Critical/High* |Patch release as soon as fix is ready
+|*Medium* |Included in next scheduled release (or earlier)
+|*Low* |Included in next scheduled release
+|===
+
+==== Supported Versions
+
+[cols=",,",options="header",]
+|===
+|Version |Supported |Notes
+|`+main+` branch |✅ Yes |Latest development
+|Latest release |✅ Yes |Current stable
+|Previous minor release |✅ Yes |Security fixes backported
+|Older versions |❌ No |Please upgrade
+|===
+
+'''''
+
+=== Security Best Practices
+
+When using nickel-augmentation, we recommend:
+
+==== General
+
+* Keep dependencies up to date
+* Use the latest stable release
+* Subscribe to security notifications
+* Review configuration against security documentation
+* Follow principle of least privilege
+
+==== For Contributors
+
+* Never commit secrets, credentials, or API keys
+* Use signed commits (`+git config commit.gpgsign true+`)
+* Review dependencies before adding them
+* Run security linters locally before pushing
+* Report any concerns about existing code
+
+'''''
+
+=== Additional Resources
+
+* https://hyperpolymath.github.io/pgp.asc[Our PGP Public Key]
+* https://github.com/hyperpolymath/nickel-augmentation/security/advisories[Security
+Advisories]
+* link:CHANGELOG.md[Changelog]
+* link:CONTRIBUTING.md[Contributing Guidelines]
+* https://cve.mitre.org/[CVE Database]
+* https://www.first.org/cvss/calculator/3.1[CVSS Calculator]
+
+'''''
+
+=== Contact
+
+[width="100%",cols="50%,50%",options="header",]
+|===
+|Purpose |Contact
+|*Security issues*
+|https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new[Report
+via GitHub] or j.d.a.jewell@open.ac.uk
+
+|*General questions*
+|https://github.com/hyperpolymath/nickel-augmentation/discussions[GitHub
+Discussions]
+
+|*Other enquiries* |See link:README.md[README] for contact information
+|===
+
+'''''
+
+=== Policy Changes
+
+This security policy may be updated from time to time. Significant
+changes will be:
+
+* Committed to this repository with a clear commit message
+* Noted in the changelog
+* Announced via GitHub Discussions (for major changes)
+
+'''''
+
+_Thank you for helping keep nickel-augmentation and its users safe._ 🛡️
+
+'''''
+
+Last updated: 2026 · Policy version: 1.0.0
diff --git a/SECURITY.md b/SECURITY.md
deleted file mode 100644
index c3c350c..0000000
--- a/SECURITY.md
+++ /dev/null
@@ -1,392 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Security Policy
-
-We take security seriously. We appreciate your efforts to responsibly disclose vulnerabilities and will make every effort to acknowledge your contributions.
-
-## Table of Contents
-
-- [Reporting a Vulnerability](#reporting-a-vulnerability)
-- [What to Include](#what-to-include)
-- [Response Timeline](#response-timeline)
-- [Disclosure Policy](#disclosure-policy)
-- [Scope](#scope)
-- [Safe Harbour](#safe-harbour)
-- [Recognition](#recognition)
-- [Security Updates](#security-updates)
-- [Security Best Practices](#security-best-practices)
-
----
-
-## Reporting a Vulnerability
-
-### Preferred Method: GitHub Security Advisories
-
-The preferred method for reporting security vulnerabilities is through GitHub's Security Advisory feature:
-
-1. Navigate to [Report a Vulnerability](https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new)
-2. Click **"Report a vulnerability"**
-3. Complete the form with as much detail as possible
-4. Submit — we'll receive a private notification
-
-This method ensures:
-
-- End-to-end encryption of your report
-- Private discussion space for collaboration
-- Coordinated disclosure tooling
-- Automatic credit when the advisory is published
-
-### Alternative: Encrypted Email
-
-If you cannot use GitHub Security Advisories, you may email us directly:
-
-| | |
-|---|---|
-| **Email** | j.d.a.jewell@open.ac.uk |
-| **PGP Key** | [Download Public Key](https://hyperpolymath.github.io/pgp.asc) |
-| **Fingerprint** | `TBD` |
-
-```bash
-# Import our PGP key
-curl -sSL https://hyperpolymath.github.io/pgp.asc | gpg --import
-
-# Verify fingerprint
-gpg --fingerprint j.d.a.jewell@open.ac.uk
-
-# Encrypt your report
-gpg --armor --encrypt --recipient j.d.a.jewell@open.ac.uk report.txt
-```
-
-> **⚠️ Important:** Do not report security vulnerabilities through public GitHub issues, pull requests, discussions, or social media.
-
----
-
-## What to Include
-
-A good vulnerability report helps us understand and reproduce the issue quickly.
-
-### Required Information
-
-- **Description**: Clear explanation of the vulnerability
-- **Impact**: What an attacker could achieve (confidentiality, integrity, availability)
-- **Affected versions**: Which versions/commits are affected
-- **Reproduction steps**: Detailed steps to reproduce the issue
-
-### Helpful Additional Information
-
-- **Proof of concept**: Code, scripts, or screenshots demonstrating the vulnerability
-- **Attack scenario**: Realistic attack scenario showing exploitability
-- **CVSS score**: Your assessment of severity (use [CVSS 3.1 Calculator](https://www.first.org/cvss/calculator/3.1))
-- **CWE ID**: Common Weakness Enumeration identifier if known
-- **Suggested fix**: If you have ideas for remediation
-- **References**: Links to related vulnerabilities, research, or advisories
-
-### Example Report Structure
-
-```markdown
-## Summary
-[One-sentence description of the vulnerability]
-
-## Vulnerability Type
-[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
-
-## Affected Component
-[File path, function name, API endpoint, etc.]
-
-## Affected Versions
-[Version range or specific commits]
-
-## Severity Assessment
-- CVSS 3.1 Score: [X.X]
-- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
-
-## Description
-[Detailed technical description]
-
-## Steps to Reproduce
-1. [First step]
-2. [Second step]
-3. [...]
-
-## Proof of Concept
-[Code, curl commands, screenshots, etc.]
-
-## Impact
-[What can an attacker achieve?]
-
-## Suggested Remediation
-[Optional: your ideas for fixing]
-
-## References
-[Links to related issues, CVEs, research]
-```
-
----
-
-## Response Timeline
-
-We commit to the following response times:
-
-| Stage | Timeframe | Description |
-|-------|-----------|-------------|
-| **Initial Response** | 48 hours | We acknowledge receipt and confirm we're investigating |
-| **Triage** | 7 days | We assess severity, confirm the vulnerability, and estimate timeline |
-| **Status Update** | Every 7 days | Regular updates on remediation progress |
-| **Resolution** | 90 days | Target for fix development and release (complex issues may take longer) |
-| **Disclosure** | 90 days | Public disclosure after fix is available (coordinated with you) |
-
-> **Note:** These are targets, not guarantees. Complex vulnerabilities may require more time. We'll communicate openly about any delays.
-
----
-
-## Disclosure Policy
-
-We follow **coordinated disclosure** (also known as responsible disclosure):
-
-1. **You report** the vulnerability privately
-2. **We acknowledge** and begin investigation
-3. **We develop** a fix and prepare a release
-4. **We coordinate** disclosure timing with you
-5. **We publish** security advisory and fix simultaneously
-6. **You may publish** your research after disclosure
-
-### Our Commitments
-
-- We will not take legal action against researchers who follow this policy
-- We will work with you to understand and resolve the issue
-- We will credit you in the security advisory (unless you prefer anonymity)
-- We will notify you before public disclosure
-- We will publish advisories with sufficient detail for users to assess risk
-
-### Your Commitments
-
-- Report vulnerabilities promptly after discovery
-- Give us reasonable time to address the issue before disclosure
-- Do not access, modify, or delete data beyond what's necessary to demonstrate the vulnerability
-- Do not degrade service availability (no DoS testing on production)
-- Do not share vulnerability details with others until coordinated disclosure
-
-### Disclosure Timeline
-
-```
-Day 0          You report vulnerability
-Day 1-2        We acknowledge receipt
-Day 7          We confirm vulnerability and share initial assessment
-Day 7-90       We develop and test fix
-Day 90         Coordinated public disclosure
-               (earlier if fix is ready; later by mutual agreement)
-```
-
-If we cannot reach agreement on disclosure timing, we default to 90 days from your initial report.
-
----
-
-## Scope
-
-### In Scope ✅
-
-The following are within scope for security research:
-
-- This repository (`hyperpolymath/nickel-augmentation`) and all its code
-- Official releases and packages published from this repository
-- Documentation that could lead to security issues
-- Build and deployment configurations in this repository
-- Dependencies (report here, we'll coordinate with upstream)
-
-### Out of Scope ❌
-
-The following are **not** in scope:
-
-- Third-party services we integrate with (report directly to them)
-- Social engineering attacks against maintainers
-- Physical security
-- Denial of service attacks against production infrastructure
-- Spam, phishing, or other non-technical attacks
-- Issues already reported or publicly known
-- Theoretical vulnerabilities without proof of concept
-
-### Qualifying Vulnerabilities
-
-We're particularly interested in:
-
-- Remote code execution
-- SQL injection, command injection, code injection
-- Authentication/authorisation bypass
-- Cross-site scripting (XSS) and cross-site request forgery (CSRF)
-- Server-side request forgery (SSRF)
-- Path traversal / local file inclusion
-- Information disclosure (credentials, PII, secrets)
-- Cryptographic weaknesses
-- Deserialisation vulnerabilities
-- Memory safety issues (buffer overflows, use-after-free, etc.)
-- Supply chain vulnerabilities (dependency confusion, etc.)
-- Significant logic flaws
-
-### Non-Qualifying Issues
-
-The following generally do not qualify as security vulnerabilities:
-
-- Missing security headers on non-sensitive pages
-- Clickjacking on pages without sensitive actions
-- Self-XSS (requires victim to paste code)
-- Missing rate limiting (unless it enables a specific attack)
-- Username/email enumeration (unless high-risk context)
-- Missing cookie flags on non-sensitive cookies
-- Software version disclosure
-- Verbose error messages (unless exposing secrets)
-- Best practice deviations without demonstrable impact
-
----
-
-## Safe Harbour
-
-We support security research conducted in good faith.
-
-### Our Promise
-
-If you conduct security research in accordance with this policy:
-
-- ✅ We will not initiate legal action against you
-- ✅ We will not report your activity to law enforcement
-- ✅ We will work with you in good faith to resolve issues
-- ✅ We consider your research authorised under the Computer Fraud and Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
-- ✅ We waive any potential claim against you for circumvention of security controls
-
-### Good Faith Requirements
-
-To qualify for safe harbour, you must:
-
-- Comply with this security policy
-- Report vulnerabilities promptly
-- Avoid privacy violations (do not access others' data)
-- Avoid service degradation (no destructive testing)
-- Not exploit vulnerabilities beyond proof-of-concept
-- Not use vulnerabilities for profit (beyond bug bounties where offered)
-
-> **⚠️ Important:** This safe harbour does not extend to third-party systems. Always check their policies before testing.
-
----
-
-## Recognition
-
-We believe in recognising security researchers who help us improve.
-
-### Hall of Fame
-
-Researchers who report valid vulnerabilities will be acknowledged in our [Security Acknowledgments](SECURITY-ACKNOWLEDGMENTS.md) (unless they prefer anonymity).
-
-Recognition includes:
-
-- Your name (or chosen alias)
-- Link to your website/profile (optional)
-- Brief description of the vulnerability class
-- Date of report
-
-### What We Offer
-
-- ✅ Public credit in security advisories
-- ✅ Acknowledgment in release notes
-- ✅ Entry in our Hall of Fame
-- ✅ Reference/recommendation letter upon request (for significant findings)
-
-### What We Don't Currently Offer
-
-- ❌ Monetary bug bounties
-- ❌ Hardware or swag
-- ❌ Paid security research contracts
-
-> **Note:** We're a community project with limited resources. Your contributions help everyone who uses this software.
-
----
-
-## Security Updates
-
-### Receiving Updates
-
-To stay informed about security updates:
-
-- **Watch this repository**: Click "Watch" → "Custom" → Select "Security alerts"
-- **GitHub Security Advisories**: Published at [Security Advisories](https://github.com/hyperpolymath/nickel-augmentation/security/advisories)
-- **Release notes**: Security fixes noted in [CHANGELOG](CHANGELOG.md)
-
-### Update Policy
-
-| Severity | Response |
-|----------|----------|
-| **Critical/High** | Patch release as soon as fix is ready |
-| **Medium** | Included in next scheduled release (or earlier) |
-| **Low** | Included in next scheduled release |
-
-### Supported Versions
-
-<!-- Adjust this table to match your actual version support policy -->
-
-| Version | Supported | Notes |
-|---------|-----------|-------|
-| `main` branch | ✅ Yes | Latest development |
-| Latest release | ✅ Yes | Current stable |
-| Previous minor release | ✅ Yes | Security fixes backported |
-| Older versions | ❌ No | Please upgrade |
-
----
-
-## Security Best Practices
-
-When using nickel-augmentation, we recommend:
-
-### General
-
-- Keep dependencies up to date
-- Use the latest stable release
-- Subscribe to security notifications
-- Review configuration against security documentation
-- Follow principle of least privilege
-
-### For Contributors
-
-- Never commit secrets, credentials, or API keys
-- Use signed commits (`git config commit.gpgsign true`)
-- Review dependencies before adding them
-- Run security linters locally before pushing
-- Report any concerns about existing code
-
----
-
-## Additional Resources
-
-- [Our PGP Public Key](https://hyperpolymath.github.io/pgp.asc)
-- [Security Advisories](https://github.com/hyperpolymath/nickel-augmentation/security/advisories)
-- [Changelog](CHANGELOG.md)
-- [Contributing Guidelines](CONTRIBUTING.md)
-- [CVE Database](https://cve.mitre.org/)
-- [CVSS Calculator](https://www.first.org/cvss/calculator/3.1)
-
----
-
-## Contact
-
-| Purpose | Contact |
-|---------|---------|
-| **Security issues** | [Report via GitHub](https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new) or j.d.a.jewell@open.ac.uk |
-| **General questions** | [GitHub Discussions](https://github.com/hyperpolymath/nickel-augmentation/discussions) |
-| **Other enquiries** | See [README](README.md) for contact information |
-
----
-
-## Policy Changes
-
-This security policy may be updated from time to time. Significant changes will be:
-
-- Committed to this repository with a clear commit message
-- Noted in the changelog
-- Announced via GitHub Discussions (for major changes)
-
----
-
-*Thank you for helping keep nickel-augmentation and its users safe.* 🛡️
-
----
-
-<sub>Last updated: 2026 · Policy version: 1.0.0</sub>
diff --git a/TEST-NEEDS.adoc b/TEST-NEEDS.adoc
new file mode 100644
index 0000000..56ec522
--- /dev/null
+++ b/TEST-NEEDS.adoc
@@ -0,0 +1,74 @@
+== TEST-NEEDS.md — nickel-augmentation
+
+=== CRG Grade: C — ACHIEVED 2026-04-04
+
+____
+Generated 2026-03-29 by punishing audit.
+____
+
+=== Current State
+
+[cols=",,",options="header",]
+|===
+|Category |Count |Notes
+|Unit tests |0 |None
+|Integration |1 |tests/integration/test_contracts.sh
+|E2E |0 |None
+|Benchmarks |0 |None
+|===
+
+*Source modules:* ~19 Nickel (.ncl) files in augmented/ and
+config-reporter/ directories. Config language library and reporter tool.
+
+=== What’s Missing
+
+==== P2P (Property-Based) Tests
+
+* [ ] Contract validation: property tests for all Nickel contracts
+* [ ] Config generation: arbitrary input config property tests
+
+==== E2E Tests
+
+* [ ] Full augmentation pipeline: input config -> augment -> validate ->
+output
+* [ ] Reporter: generate report from augmented config
+* [ ] Contract enforcement: valid and invalid config
+rejection/acceptance
+
+==== Aspect Tests
+
+* *Security:* No tests for config injection, contract bypass
+* *Performance:* No config evaluation benchmarks
+* *Concurrency:* N/A
+* *Error handling:* No tests for malformed Nickel, invalid contracts,
+missing dependencies
+
+==== Build & Execution
+
+* [ ] `+nickel typecheck+` for all .ncl files
+* [ ] Shell integration test execution
+
+==== Benchmarks Needed
+
+* [ ] Config evaluation time by complexity
+* [ ] Contract validation overhead
+
+==== Self-Tests
+
+* [ ] All .ncl files typecheck cleanly
+* [ ] Contract self-consistency verification
+
+=== Priority
+
+*MEDIUM.* 19 Nickel files with 1 shell integration test. Small project
+but the contracts are meant to enforce correctness — they need their own
+correctness verified. The integration test is a start but unit-level
+contract testing is missing.
+
+=== FAKE-FUZZ ALERT
+
+* `+tests/fuzz/placeholder.txt+` is a scorecard placeholder inherited
+from rsr-template-repo — it does NOT provide real fuzz testing
+* Replace with an actual fuzz harness (see
+rsr-template-repo/tests/fuzz/README.adoc) or remove the file
+* Priority: P2 — creates false impression of fuzz coverage
diff --git a/TEST-NEEDS.md b/TEST-NEEDS.md
deleted file mode 100644
index a090771..0000000
--- a/TEST-NEEDS.md
+++ /dev/null
@@ -1,59 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# TEST-NEEDS.md — nickel-augmentation
-
-## CRG Grade: C — ACHIEVED 2026-04-04
-
-> Generated 2026-03-29 by punishing audit.
-
-## Current State
-
-| Category     | Count | Notes |
-|-------------|-------|-------|
-| Unit tests   | 0     | None |
-| Integration  | 1     | tests/integration/test_contracts.sh |
-| E2E          | 0     | None |
-| Benchmarks   | 0     | None |
-
-**Source modules:** ~19 Nickel (.ncl) files in augmented/ and config-reporter/ directories. Config language library and reporter tool.
-
-## What's Missing
-
-### P2P (Property-Based) Tests
-- [ ] Contract validation: property tests for all Nickel contracts
-- [ ] Config generation: arbitrary input config property tests
-
-### E2E Tests
-- [ ] Full augmentation pipeline: input config -> augment -> validate -> output
-- [ ] Reporter: generate report from augmented config
-- [ ] Contract enforcement: valid and invalid config rejection/acceptance
-
-### Aspect Tests
-- **Security:** No tests for config injection, contract bypass
-- **Performance:** No config evaluation benchmarks
-- **Concurrency:** N/A
-- **Error handling:** No tests for malformed Nickel, invalid contracts, missing dependencies
-
-### Build & Execution
-- [ ] `nickel typecheck` for all .ncl files
-- [ ] Shell integration test execution
-
-### Benchmarks Needed
-- [ ] Config evaluation time by complexity
-- [ ] Contract validation overhead
-
-### Self-Tests
-- [ ] All .ncl files typecheck cleanly
-- [ ] Contract self-consistency verification
-
-## Priority
-
-**MEDIUM.** 19 Nickel files with 1 shell integration test. Small project but the contracts are meant to enforce correctness — they need their own correctness verified. The integration test is a start but unit-level contract testing is missing.
-
-## FAKE-FUZZ ALERT
-
-- `tests/fuzz/placeholder.txt` is a scorecard placeholder inherited from rsr-template-repo — it does NOT provide real fuzz testing
-- Replace with an actual fuzz harness (see rsr-template-repo/tests/fuzz/README.adoc) or remove the file
-- Priority: P2 — creates false impression of fuzz coverage
diff --git a/TOPOLOGY.md b/TOPOLOGY.adoc
similarity index 88%
rename from TOPOLOGY.md
rename to TOPOLOGY.adoc
index 43b5ac3..d82be8d 100644
--- a/TOPOLOGY.md
+++ b/TOPOLOGY.adoc
@@ -1,15 +1,8 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-<!-- TOPOLOGY.md — Project architecture map and completion dashboard -->
-<!-- Last updated: 2026-03-16 -->
+== nickel-augmentation — Project Topology
 
-# nickel-augmentation — Project Topology
+=== System Architecture
 
-## System Architecture
-
-```
+....
                         ┌─────────────────────────────────────────┐
                         │              OPERATOR / AGENT           │
                         │        (Nickel Configs / YAML / JSON)   │
@@ -41,11 +34,11 @@ Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
                 │  Justfile Automation  .machine_readable/ │
                 │  .bot_directives/     0-AI-MANIFEST.a2ml │
                 └─────────────────────────────────────────┘
-```
+....
 
-## Completion Dashboard
+=== Completion Dashboard
 
-```
+....
 COMPONENT                          STATUS              NOTES
 ─────────────────────────────────  ──────────────────  ─────────────────────────────────
 AUGMENTED (Library)
@@ -74,11 +67,11 @@ INFRASTRUCTURE
 
 ─────────────────────────────────────────────────────────────────────────────
 OVERALL:                            ██████░░░░  ~55%   Library stable, reporter active
-```
+....
 
-## Key Dependencies
+=== Key Dependencies
 
-```
+....
 augmented/lib/ ──────► examples/ ───► Validation (nickel typecheck / export)
      │                     │
      │                     ▼
@@ -86,16 +79,17 @@ augmented/lib/ ──────► examples/ ───► Validation (nickel t
      │
      ▼
 contractiles/k9/ ──── K9 templates use contracts from lib/
-```
+....
 
-## Update Protocol
+=== Update Protocol
 
 This file is maintained by both humans and AI agents. When updating:
 
-1. **After completing a component**: Change its bar and percentage
-2. **After adding a component**: Add a new row in the appropriate section
-3. **After architectural changes**: Update the ASCII diagram
-4. **Date**: Update the `Last updated` comment at the top of this file
+[arabic]
+. *After completing a component*: Change its bar and percentage
+. *After adding a component*: Add a new row in the appropriate section
+. *After architectural changes*: Update the ASCII diagram
+. *Date*: Update the `+Last updated+` comment at the top of this file
 
-Progress bars use: `█` (filled) and `░` (empty), 10 characters wide.
-Percentages: 0%, 10%, 20%, ... 100% (in 10% increments).
+Progress bars use: `+█+` (filled) and `+░+` (empty), 10 characters wide.
+Percentages: 0%, 10%, 20%, … 100% (in 10% increments).
diff --git a/augmented/CODE_OF_CONDUCT.adoc b/augmented/CODE_OF_CONDUCT.adoc
new file mode 100644
index 0000000..442c50d
--- /dev/null
+++ b/augmented/CODE_OF_CONDUCT.adoc
@@ -0,0 +1,340 @@
+== Code of Conduct
+
+=== Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in
+Nickel Augmentation a harassment-free experience for everyone,
+regardless of age, body size, visible or invisible disability,
+ethnicity, sex characteristics, gender identity and expression, level of
+experience, education, socio-economic status, nationality, personal
+appearance, race, caste, colour, religion, or sexual identity and
+orientation.
+
+We pledge to act and interact in ways that contribute to an open,
+welcoming, diverse, inclusive, and healthy community.
+
+We recognise that a thriving open source community requires
+*psychological safety* — an environment where people can contribute, ask
+questions, make mistakes, and learn without fear of ridicule or
+retaliation.
+
+'''''
+
+=== Our Standards
+
+==== Expected Behaviour
+
+The following behaviours contribute to a positive environment:
+
+*Communication* - Using welcoming and inclusive language - Being
+respectful of differing viewpoints and experiences - Giving and
+gracefully accepting constructive feedback - Assuming good intent while
+addressing impact - Communicating clearly and patiently, especially with
+newcomers
+
+*Collaboration* - Focusing on what is best for the community - Showing
+empathy and kindness toward other community members - Being
+collaborative rather than competitive - Mentoring and supporting less
+experienced contributors - Celebrating others’ contributions and
+successes
+
+*Professionalism* - Accepting responsibility and apologising to those
+affected by our mistakes - Learning from the experience and avoiding
+repetition - Respecting others’ time and attention - Staying on topic in
+project spaces - Following project guidelines and conventions
+
+*Accessibility* - Using plain language and avoiding unnecessary jargon -
+Providing alt text for images and transcripts for audio/video - Being
+patient with those using assistive technologies - Accommodating
+different communication styles and needs - Recognising that not everyone
+communicates the same way
+
+==== Unacceptable Behaviour
+
+The following behaviours are considered harassment and are unacceptable:
+
+*Harassment* - The use of sexualised language or imagery, and sexual
+attention or advances of any kind - Trolling, insulting or derogatory
+comments, and personal or political attacks - Public or private
+harassment - Deliberate intimidation, stalking, or following (online or
+in-person) - Unwelcome physical contact or simulated physical contact
+(e.g., emoji) - Sustained disruption of talks, events, or online
+discussions
+
+*Discrimination* - Discriminatory jokes and language - Posting or
+threatening to post others’ personally identifying information
+("`doxing`") - Advocating for, or encouraging, any of the above
+behaviour - Microaggressions — subtle, often unintentional,
+discriminatory comments or actions
+
+*Professional Misconduct* - Publishing others’ private information
+without explicit permission - Misrepresenting affiliation or
+contributions - Plagiarism or claiming credit for others’ work -
+Retaliating against anyone who reports a Code of Conduct violation -
+Other conduct which could reasonably be considered inappropriate in a
+professional setting
+
+==== Grey Areas
+
+Some situations require judgement. When uncertain:
+
+* *Intent vs Impact*: Good intentions do not excuse harmful impact.
+Focus on making things right.
+* *Power Dynamics*: Those with more power (maintainers, employers,
+experienced contributors) must be especially mindful of their impact.
+* *Cultural Differences*: What’s acceptable varies by culture. When in
+doubt, err on the side of caution and ask.
+* *Humour*: Jokes at others’ expense are rarely funny to everyone. Punch
+up, not down.
+
+'''''
+
+=== Scope
+
+This Code of Conduct applies within all community spaces, including:
+
+*Online Spaces* - Repository discussions, issues, and pull/merge
+requests - Project chat channels (Matrix, Discord, Slack, IRC) - Mailing
+lists and forums - Social media when representing the project - Video
+calls and virtual meetings
+
+*In-Person Spaces* - Conferences, meetups, and events - Workshops and
+training sessions - Any gathering where you represent the project
+
+*Representation* This Code of Conduct also applies when an individual is
+officially representing the community in public spaces. Examples
+include:
+
+* Using an official project email address
+* Posting via an official social media account
+* Acting as an appointed representative at an event
+* Speaking on behalf of the project
+
+'''''
+
+=== Enforcement
+
+==== Reporting
+
+If you experience or witness unacceptable behaviour, or have any other
+concerns, please report it as soon as possible.
+
+*How to Report*
+
+[width="99%",cols="30%,33%,37%",options="header",]
+|===
+|Method |Details |Best For
+|*Email* |\{\{CONDUCT_EMAIL}} |Detailed reports, sensitive matters
+
+|*Private Message* |Contact any maintainer directly |Quick questions,
+minor issues
+
+|*Anonymous Form* |[Link to form if available] |When you need anonymity
+|===
+
+*What to Include*
+
+* Your contact information (unless anonymous)
+* Names/usernames of those involved
+* Description of what happened
+* When and where it occurred
+* Any witnesses
+* Any supporting evidence (screenshots, links)
+* How you would like us to respond (if you have a preference)
+
+*What Happens Next*
+
+[arabic]
+. You will receive acknowledgment within *\{\{RESPONSE_TIME}}*
+. The \{\{CONDUCT_TEAM}} will review the report
+. We may ask for additional information
+. We will determine appropriate action
+. We will inform you of the outcome (respecting others’ privacy)
+
+==== Confidentiality
+
+All reports will be handled with discretion:
+
+* Reporter identity is protected by default
+* Details are shared only with those who need to know
+* We will ask before naming you in any communication
+* Anonymous reports are accepted and investigated
+
+==== Conflicts of Interest
+
+If a \{\{CONDUCT_TEAM}} member is involved in an incident:
+
+* They will recuse themselves from the process
+* Another maintainer or external party will handle the report
+* We will disclose any potential conflicts
+
+'''''
+
+=== Enforcement Guidelines
+
+The \{\{CONDUCT_TEAM}} will follow these guidelines in determining
+consequences:
+
+==== 1. Correction
+
+*Community Impact*: Use of inappropriate language or other behaviour
+deemed unprofessional or unwelcome.
+
+*Consequence*: A private, written warning providing clarity around the
+nature of the violation and an explanation of why the behaviour was
+inappropriate. A public apology may be requested.
+
+*Duration*: Immediate
+
+==== 2. Warning
+
+*Community Impact*: A violation through a single incident or series of
+actions.
+
+*Consequence*: A warning with consequences for continued behaviour. No
+interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, for a specified period. This
+includes avoiding interactions in community spaces as well as external
+channels like social media. Violating these terms may lead to a
+temporary or permanent ban.
+
+*Duration*: 1-4 weeks
+
+==== 3. Temporary Ban
+
+*Community Impact*: A serious violation of community standards,
+including sustained inappropriate behaviour.
+
+*Consequence*: A temporary ban from any sort of interaction or public
+communication with the community for a specified period. No public or
+private interaction with the people involved, including unsolicited
+interaction with those enforcing the Code of Conduct, is allowed during
+this period. Violating these terms may lead to a permanent ban.
+
+*Duration*: 1-6 months
+
+==== 4. Permanent Ban
+
+*Community Impact*: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behaviour, harassment of an
+individual, or aggression toward or disparagement of classes of
+individuals.
+
+*Consequence*: A permanent ban from any sort of public interaction
+within the community.
+
+*Duration*: Permanent (with appeal rights after 12 months)
+
+==== Enforcement Across Perimeters
+
+For contributors with elevated access (Perimeter 2 or 1):
+
+[cols=",",options="header",]
+|===
+|Level |Additional Consequence
+|Correction |Noted in contributor record
+|Warning |Access privileges may be temporarily reduced
+|Temporary Ban |Access reduced to Perimeter 3 for ban duration
+|Permanent Ban |All access revoked
+|===
+
+'''''
+
+=== Appeals
+
+If you believe an enforcement decision was made in error:
+
+[arabic]
+. *Wait 7 days* after the decision (cooling-off period)
+. *Email* \{\{CONDUCT_EMAIL}} with subject line "`Appeal: [Original
+Report ID]`"
+. *Explain* why you believe the decision should be reconsidered
+. *Provide* any new information not previously available
+
+*Appeals Process*
+
+* Appeals are reviewed by a different \{\{CONDUCT_TEAM}} member than the
+original
+* You will receive a response within 14 days
+* The appeals decision is final
+* You may only appeal once per incident
+
+*Grounds for Appeal*
+
+* Procedural errors in the original investigation
+* New evidence not previously available
+* Disproportionate response to the violation
+* Misunderstanding of facts
+
+'''''
+
+=== Supporting Those Who Report
+
+We are committed to supporting those who report violations:
+
+*We Will* - Believe and take all reports seriously - Respect your
+privacy and confidentiality preferences - Keep you informed of progress
+(if you wish) - Take steps to protect you from retaliation - Provide
+resources if you need support
+
+*We Will Not* - Require you to confront the person directly - Dismiss
+reports without investigation - Reveal your identity without consent -
+Tolerate retaliation against reporters - Rush you to make decisions
+
+'''''
+
+=== Prevention
+
+Beyond enforcement, we actively work to prevent issues:
+
+*Onboarding* - All contributors are expected to read this Code of
+Conduct - Perimeter 2 applicants must confirm they’ve read and
+understood it - Maintainers receive additional training on enforcement
+
+*Culture* - We model the behaviour we expect - We intervene early when
+we see potential issues - We thank people for positive contributions -
+We create opportunities for diverse voices
+
+*Review* - This Code of Conduct is reviewed annually - Community
+feedback is welcomed - Changes are communicated clearly
+
+'''''
+
+=== Acknowledgments
+
+This Code of Conduct is adapted from:
+
+* https://www.contributor-covenant.org/[Contributor Covenant], version
+2.1
+* https://www.djangoproject.com/conduct/[Django Code of Conduct]
+* https://www.rust-lang.org/policies/code-of-conduct[Rust Code of
+Conduct]
+* https://www.python.org/psf/conduct/[Python Community Code of Conduct]
+
+We thank these communities for their leadership in creating welcoming
+spaces.
+
+'''''
+
+=== Questions?
+
+If you have questions about this Code of Conduct:
+
+* Open a
+https://github.com/hyperpolymath/nickel-augmentation/discussions[Discussion]
+(for general questions)
+* Email \{\{CONDUCT_EMAIL}} (for private questions)
+* Contact any maintainer directly
+
+'''''
+
+=== Summary
+
+*Be kind. Be respectful. Be collaborative.*
+
+We’re all here because we care about this project. Let’s make it a place
+where everyone can do their best work.
+
+'''''
+
+Last updated: 2026 · Based on Contributor Covenant 2.1
diff --git a/augmented/CODE_OF_CONDUCT.md b/augmented/CODE_OF_CONDUCT.md
deleted file mode 100644
index b053b96..0000000
--- a/augmented/CODE_OF_CONDUCT.md
+++ /dev/null
@@ -1,331 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Code of Conduct
-
-<!-- 
-============================================================================
-TEMPLATE INSTRUCTIONS (delete this block before publishing)
-============================================================================
-Replace all {{PLACEHOLDER}} values:
-  Nickel Augmentation     - Your project name
-  hyperpolymath            - GitHub/GitLab username or org
-  nickel-augmentation             - Repository name
-  {{CONDUCT_EMAIL}}    - Email for conduct reports
-  {{CONDUCT_TEAM}}     - Name of conduct team/committee
-  {{RESPONSE_TIME}}    - Initial response SLA (e.g., 48 hours)
-  2026     - Current year
-
-Review and customise:
-- Adjust enforcement ladder for your community size
-- Add/remove examples based on your context
-- Ensure contact methods work for your team
-============================================================================
--->
-
-## Our Pledge
-
-We as members, contributors, and leaders pledge to make participation in Nickel Augmentation a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, colour, religion, or sexual identity and orientation.
-
-We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
-
-We recognise that a thriving open source community requires **psychological safety** — an environment where people can contribute, ask questions, make mistakes, and learn without fear of ridicule or retaliation.
-
----
-
-## Our Standards
-
-### Expected Behaviour
-
-The following behaviours contribute to a positive environment:
-
-**Communication**
-- Using welcoming and inclusive language
-- Being respectful of differing viewpoints and experiences
-- Giving and gracefully accepting constructive feedback
-- Assuming good intent while addressing impact
-- Communicating clearly and patiently, especially with newcomers
-
-**Collaboration**
-- Focusing on what is best for the community
-- Showing empathy and kindness toward other community members
-- Being collaborative rather than competitive
-- Mentoring and supporting less experienced contributors
-- Celebrating others' contributions and successes
-
-**Professionalism**
-- Accepting responsibility and apologising to those affected by our mistakes
-- Learning from the experience and avoiding repetition
-- Respecting others' time and attention
-- Staying on topic in project spaces
-- Following project guidelines and conventions
-
-**Accessibility**
-- Using plain language and avoiding unnecessary jargon
-- Providing alt text for images and transcripts for audio/video
-- Being patient with those using assistive technologies
-- Accommodating different communication styles and needs
-- Recognising that not everyone communicates the same way
-
-### Unacceptable Behaviour
-
-The following behaviours are considered harassment and are unacceptable:
-
-**Harassment**
-- The use of sexualised language or imagery, and sexual attention or advances of any kind
-- Trolling, insulting or derogatory comments, and personal or political attacks
-- Public or private harassment
-- Deliberate intimidation, stalking, or following (online or in-person)
-- Unwelcome physical contact or simulated physical contact (e.g., emoji)
-- Sustained disruption of talks, events, or online discussions
-
-**Discrimination**
-- Discriminatory jokes and language
-- Posting or threatening to post others' personally identifying information ("doxing")
-- Advocating for, or encouraging, any of the above behaviour
-- Microaggressions — subtle, often unintentional, discriminatory comments or actions
-
-**Professional Misconduct**
-- Publishing others' private information without explicit permission
-- Misrepresenting affiliation or contributions
-- Plagiarism or claiming credit for others' work
-- Retaliating against anyone who reports a Code of Conduct violation
-- Other conduct which could reasonably be considered inappropriate in a professional setting
-
-### Grey Areas
-
-Some situations require judgement. When uncertain:
-
-- **Intent vs Impact**: Good intentions do not excuse harmful impact. Focus on making things right.
-- **Power Dynamics**: Those with more power (maintainers, employers, experienced contributors) must be especially mindful of their impact.
-- **Cultural Differences**: What's acceptable varies by culture. When in doubt, err on the side of caution and ask.
-- **Humour**: Jokes at others' expense are rarely funny to everyone. Punch up, not down.
-
----
-
-## Scope
-
-This Code of Conduct applies within all community spaces, including:
-
-**Online Spaces**
-- Repository discussions, issues, and pull/merge requests
-- Project chat channels (Matrix, Discord, Slack, IRC)
-- Mailing lists and forums
-- Social media when representing the project
-- Video calls and virtual meetings
-
-**In-Person Spaces**
-- Conferences, meetups, and events
-- Workshops and training sessions
-- Any gathering where you represent the project
-
-**Representation**
-This Code of Conduct also applies when an individual is officially representing the community in public spaces. Examples include:
-
-- Using an official project email address
-- Posting via an official social media account
-- Acting as an appointed representative at an event
-- Speaking on behalf of the project
-
----
-
-## Enforcement
-
-### Reporting
-
-If you experience or witness unacceptable behaviour, or have any other concerns, please report it as soon as possible.
-
-**How to Report**
-
-| Method | Details | Best For |
-|--------|---------|----------|
-| **Email** | {{CONDUCT_EMAIL}} | Detailed reports, sensitive matters |
-| **Private Message** | Contact any maintainer directly | Quick questions, minor issues |
-| **Anonymous Form** | [Link to form if available] | When you need anonymity |
-
-**What to Include**
-
-- Your contact information (unless anonymous)
-- Names/usernames of those involved
-- Description of what happened
-- When and where it occurred
-- Any witnesses
-- Any supporting evidence (screenshots, links)
-- How you would like us to respond (if you have a preference)
-
-**What Happens Next**
-
-1. You will receive acknowledgment within **{{RESPONSE_TIME}}**
-2. The {{CONDUCT_TEAM}} will review the report
-3. We may ask for additional information
-4. We will determine appropriate action
-5. We will inform you of the outcome (respecting others' privacy)
-
-### Confidentiality
-
-All reports will be handled with discretion:
-
-- Reporter identity is protected by default
-- Details are shared only with those who need to know
-- We will ask before naming you in any communication
-- Anonymous reports are accepted and investigated
-
-### Conflicts of Interest
-
-If a {{CONDUCT_TEAM}} member is involved in an incident:
-
-- They will recuse themselves from the process
-- Another maintainer or external party will handle the report
-- We will disclose any potential conflicts
-
----
-
-## Enforcement Guidelines
-
-The {{CONDUCT_TEAM}} will follow these guidelines in determining consequences:
-
-### 1. Correction
-
-**Community Impact**: Use of inappropriate language or other behaviour deemed unprofessional or unwelcome.
-
-**Consequence**: A private, written warning providing clarity around the nature of the violation and an explanation of why the behaviour was inappropriate. A public apology may be requested.
-
-**Duration**: Immediate
-
-### 2. Warning
-
-**Community Impact**: A violation through a single incident or series of actions.
-
-**Consequence**: A warning with consequences for continued behaviour. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
-
-**Duration**: 1-4 weeks
-
-### 3. Temporary Ban
-
-**Community Impact**: A serious violation of community standards, including sustained inappropriate behaviour.
-
-**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
-
-**Duration**: 1-6 months
-
-### 4. Permanent Ban
-
-**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behaviour, harassment of an individual, or aggression toward or disparagement of classes of individuals.
-
-**Consequence**: A permanent ban from any sort of public interaction within the community.
-
-**Duration**: Permanent (with appeal rights after 12 months)
-
-### Enforcement Across Perimeters
-
-For contributors with elevated access (Perimeter 2 or 1):
-
-| Level | Additional Consequence |
-|-------|----------------------|
-| Correction | Noted in contributor record |
-| Warning | Access privileges may be temporarily reduced |
-| Temporary Ban | Access reduced to Perimeter 3 for ban duration |
-| Permanent Ban | All access revoked |
-
----
-
-## Appeals
-
-If you believe an enforcement decision was made in error:
-
-1. **Wait 7 days** after the decision (cooling-off period)
-2. **Email** {{CONDUCT_EMAIL}} with subject line "Appeal: [Original Report ID]"
-3. **Explain** why you believe the decision should be reconsidered
-4. **Provide** any new information not previously available
-
-**Appeals Process**
-
-- Appeals are reviewed by a different {{CONDUCT_TEAM}} member than the original
-- You will receive a response within 14 days
-- The appeals decision is final
-- You may only appeal once per incident
-
-**Grounds for Appeal**
-
-- Procedural errors in the original investigation
-- New evidence not previously available
-- Disproportionate response to the violation
-- Misunderstanding of facts
-
----
-
-## Supporting Those Who Report
-
-We are committed to supporting those who report violations:
-
-**We Will**
-- Believe and take all reports seriously
-- Respect your privacy and confidentiality preferences
-- Keep you informed of progress (if you wish)
-- Take steps to protect you from retaliation
-- Provide resources if you need support
-
-**We Will Not**
-- Require you to confront the person directly
-- Dismiss reports without investigation
-- Reveal your identity without consent
-- Tolerate retaliation against reporters
-- Rush you to make decisions
-
----
-
-## Prevention
-
-Beyond enforcement, we actively work to prevent issues:
-
-**Onboarding**
-- All contributors are expected to read this Code of Conduct
-- Perimeter 2 applicants must confirm they've read and understood it
-- Maintainers receive additional training on enforcement
-
-**Culture**
-- We model the behaviour we expect
-- We intervene early when we see potential issues
-- We thank people for positive contributions
-- We create opportunities for diverse voices
-
-**Review**
-- This Code of Conduct is reviewed annually
-- Community feedback is welcomed
-- Changes are communicated clearly
-
----
-
-## Acknowledgments
-
-This Code of Conduct is adapted from:
-
-- [Contributor Covenant](https://www.contributor-covenant.org/), version 2.1
-- [Django Code of Conduct](https://www.djangoproject.com/conduct/)
-- [Rust Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct)
-- [Python Community Code of Conduct](https://www.python.org/psf/conduct/)
-
-We thank these communities for their leadership in creating welcoming spaces.
-
----
-
-## Questions?
-
-If you have questions about this Code of Conduct:
-
-- Open a [Discussion](https://github.com/hyperpolymath/nickel-augmentation/discussions) (for general questions)
-- Email {{CONDUCT_EMAIL}} (for private questions)
-- Contact any maintainer directly
-
----
-
-## Summary
-
-**Be kind. Be respectful. Be collaborative.**
-
-We're all here because we care about this project. Let's make it a place where everyone can do their best work.
-
----
-
-<sub>Last updated: 2026 · Based on Contributor Covenant 2.1</sub>
diff --git a/augmented/CONTRIBUTING.adoc b/augmented/CONTRIBUTING.adoc
index e9b1993..610ec53 100644
--- a/augmented/CONTRIBUTING.adoc
+++ b/augmented/CONTRIBUTING.adoc
@@ -1,21 +1,109 @@
-// SPDX-License-Identifier: CC-BY-SA-4.0
-// Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
-= Contributing Guide
+== Clone the repository
 
-== Getting Started
+git clone https://github.com/hyperpolymath/nickel-augmentation.git cd
+nickel-augmentation
 
-1. Fork the repository
-2. Create a feature branch from `main`
-3. Sign off commits (`git commit -s`)
-4. Submit a pull request
+== Using Nix (recommended for reproducibility)
 
-== Commit Guidelines
+nix develop
 
-* Conventional commits: `type(scope): description`
-* Sign all commits (DCO required)
-* Atomic, focused commits
+== Or using toolbox/distrobox
 
-== License
+toolbox create nickel-augmentation-dev toolbox enter
+nickel-augmentation-dev # Install dependencies manually
 
-Contributions licensed under project license.
+== Verify setup
 
+just check # or: cargo check / mix compile / etc. just test # Run test
+suite
+
+....
+
+### Repository Structure
+....
+
+nickel-augmentation/ ├── src/ # Source code (Perimeter 1-2) ├── lib/ #
+Library code (Perimeter 1-2) ├── extensions/ # Extensions (Perimeter 2)
+├── plugins/ # Plugins (Perimeter 2) ├── tools/ # Tooling (Perimeter 2)
+├── docs/ # Documentation (Perimeter 3) │ ├── architecture/ # ADRs,
+specs (Perimeter 2) │ └── proposals/ # RFCs (Perimeter 3) ├── examples/
+# Examples (Perimeter 3) ├── spec/ # Spec tests (Perimeter 3) ├── tests/
+# Test suite (Perimeter 2-3) ├── .well-known/ # Protocol files
+(Perimeter 1-3) ├── .github/ # GitHub config (Perimeter 1) │ ├──
+ISSUE_TEMPLATE/ │ └── workflows/ ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md
+├── CONTRIBUTING.md # This file ├── GOVERNANCE.md ├── LICENSE ├──
+MAINTAINERS.md ├── README.adoc ├── SECURITY.md ├── flake.nix # Nix flake
+(Perimeter 1) └── Justfile # Task runner (Perimeter 1)
+
+....
+
+---
+
+## How to Contribute
+
+### Reporting Bugs
+
+**Before reporting**:
+1. Search existing issues
+2. Check if it's already fixed in `main`
+3. Determine which perimeter the bug affects
+
+**When reporting**:
+
+Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
+
+- Clear, descriptive title
+- Environment details (OS, versions, toolchain)
+- Steps to reproduce
+- Expected vs actual behaviour
+- Logs, screenshots, or minimal reproduction
+
+### Suggesting Features
+
+**Before suggesting**:
+1. Check the [roadmap](ROADMAP.md) if available
+2. Search existing issues and discussions
+3. Consider which perimeter the feature belongs to
+
+**When suggesting**:
+
+Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
+
+- Problem statement (what pain point does this solve?)
+- Proposed solution
+- Alternatives considered
+- Which perimeter this affects
+
+### Your First Contribution
+
+Look for issues labelled:
+
+- [`good first issue`](https://github.com/hyperpolymath/nickel-augmentation/labels/good%20first%20issue) — Simple Perimeter 3 tasks
+- [`help wanted`](https://github.com/hyperpolymath/nickel-augmentation/labels/help%20wanted) — Community help needed
+- [`documentation`](https://github.com/hyperpolymath/nickel-augmentation/labels/documentation) — Docs improvements
+- [`perimeter-3`](https://github.com/hyperpolymath/nickel-augmentation/labels/perimeter-3) — Community sandbox scope
+
+---
+
+## Development Workflow
+
+### Branch Naming
+....
+
+docs/short-description # Documentation (P3) test/what-added # Test
+additions (P3) feat/short-description # New features (P2)
+fix/issue-number-description # Bug fixes (P2) refactor/what-changed #
+Code improvements (P2) security/what-fixed # Security fixes (P1-2)
+
+....
+
+### Commit Messages
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/):
+....
+
+():
+
+{empty}[optional body]
+
+{empty}[optional footer]
diff --git a/augmented/CONTRIBUTING.md b/augmented/CONTRIBUTING.md
deleted file mode 100644
index e220e66..0000000
--- a/augmented/CONTRIBUTING.md
+++ /dev/null
@@ -1,120 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Clone the repository
-git clone https://github.com/hyperpolymath/nickel-augmentation.git
-cd nickel-augmentation
-
-# Using Nix (recommended for reproducibility)
-nix develop
-
-# Or using toolbox/distrobox
-toolbox create nickel-augmentation-dev
-toolbox enter nickel-augmentation-dev
-# Install dependencies manually
-
-# Verify setup
-just check   # or: cargo check / mix compile / etc.
-just test    # Run test suite
-```
-
-### Repository Structure
-```
-nickel-augmentation/
-├── src/                 # Source code (Perimeter 1-2)
-├── lib/                 # Library code (Perimeter 1-2)
-├── extensions/          # Extensions (Perimeter 2)
-├── plugins/             # Plugins (Perimeter 2)
-├── tools/               # Tooling (Perimeter 2)
-├── docs/                # Documentation (Perimeter 3)
-│   ├── architecture/    # ADRs, specs (Perimeter 2)
-│   └── proposals/       # RFCs (Perimeter 3)
-├── examples/            # Examples (Perimeter 3)
-├── spec/                # Spec tests (Perimeter 3)
-├── tests/               # Test suite (Perimeter 2-3)
-├── .well-known/         # Protocol files (Perimeter 1-3)
-├── .github/             # GitHub config (Perimeter 1)
-│   ├── ISSUE_TEMPLATE/
-│   └── workflows/
-├── CHANGELOG.md
-├── CODE_OF_CONDUCT.md
-├── CONTRIBUTING.md      # This file
-├── GOVERNANCE.md
-├── LICENSE
-├── MAINTAINERS.md
-├── README.adoc
-├── SECURITY.md
-├── flake.nix            # Nix flake (Perimeter 1)
-└── Justfile             # Task runner (Perimeter 1)
-```
-
----
-
-## How to Contribute
-
-### Reporting Bugs
-
-**Before reporting**:
-1. Search existing issues
-2. Check if it's already fixed in `main`
-3. Determine which perimeter the bug affects
-
-**When reporting**:
-
-Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
-
-- Clear, descriptive title
-- Environment details (OS, versions, toolchain)
-- Steps to reproduce
-- Expected vs actual behaviour
-- Logs, screenshots, or minimal reproduction
-
-### Suggesting Features
-
-**Before suggesting**:
-1. Check the [roadmap](ROADMAP.md) if available
-2. Search existing issues and discussions
-3. Consider which perimeter the feature belongs to
-
-**When suggesting**:
-
-Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
-
-- Problem statement (what pain point does this solve?)
-- Proposed solution
-- Alternatives considered
-- Which perimeter this affects
-
-### Your First Contribution
-
-Look for issues labelled:
-
-- [`good first issue`](https://github.com/hyperpolymath/nickel-augmentation/labels/good%20first%20issue) — Simple Perimeter 3 tasks
-- [`help wanted`](https://github.com/hyperpolymath/nickel-augmentation/labels/help%20wanted) — Community help needed
-- [`documentation`](https://github.com/hyperpolymath/nickel-augmentation/labels/documentation) — Docs improvements
-- [`perimeter-3`](https://github.com/hyperpolymath/nickel-augmentation/labels/perimeter-3) — Community sandbox scope
-
----
-
-## Development Workflow
-
-### Branch Naming
-```
-docs/short-description       # Documentation (P3)
-test/what-added              # Test additions (P3)
-feat/short-description       # New features (P2)
-fix/issue-number-description # Bug fixes (P2)
-refactor/what-changed        # Code improvements (P2)
-security/what-fixed          # Security fixes (P1-2)
-```
-
-### Commit Messages
-
-We follow [Conventional Commits](https://www.conventionalcommits.org/):
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer]
diff --git a/augmented/SECURITY.adoc b/augmented/SECURITY.adoc
new file mode 100644
index 0000000..24ac5cc
--- /dev/null
+++ b/augmented/SECURITY.adoc
@@ -0,0 +1,453 @@
+== Security Policy
+
+We take security seriously. We appreciate your efforts to responsibly
+disclose vulnerabilities and will make every effort to acknowledge your
+contributions.
+
+=== Table of Contents
+
+* link:#reporting-a-vulnerability[Reporting a Vulnerability]
+* link:#what-to-include[What to Include]
+* link:#response-timeline[Response Timeline]
+* link:#disclosure-policy[Disclosure Policy]
+* link:#scope[Scope]
+* link:#safe-harbour[Safe Harbour]
+* link:#recognition[Recognition]
+* link:#security-updates[Security Updates]
+* link:#security-best-practices[Security Best Practices]
+
+'''''
+
+=== Reporting a Vulnerability
+
+==== Preferred Method: GitHub Security Advisories
+
+The preferred method for reporting security vulnerabilities is through
+GitHub’s Security Advisory feature:
+
+[arabic]
+. Navigate to
+https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new[Report
+a Vulnerability]
+. Click *"`Report a vulnerability`"*
+. Complete the form with as much detail as possible
+. Submit — we’ll receive a private notification
+
+This method ensures:
+
+* End-to-end encryption of your report
+* Private discussion space for collaboration
+* Coordinated disclosure tooling
+* Automatic credit when the advisory is published
+
+==== Alternative: Encrypted Email
+
+If you cannot use GitHub Security Advisories, you may email us directly:
+
+[cols=",",]
+|===
+|*Email* |6759885+hyperpolymath@users.noreply.github.com
+|*PGP Key* |link:%7B%7BPGP_KEY_URL%7D%7D[Download Public Key]
+|*Fingerprint* |`+[PGP fingerprint not set]+`
+|===
+
+[source,bash]
+----
+# Import our PGP key
+curl -sSL {{PGP_KEY_URL}} | gpg --import
+
+# Verify fingerprint
+gpg --fingerprint 6759885+hyperpolymath@users.noreply.github.com
+
+# Encrypt your report
+gpg --armor --encrypt --recipient 6759885+hyperpolymath@users.noreply.github.com report.txt
+----
+
+____
+*⚠️ Important:* Do not report security vulnerabilities through public
+GitHub issues, pull requests, discussions, or social media.
+____
+
+'''''
+
+=== What to Include
+
+A good vulnerability report helps us understand and reproduce the issue
+quickly.
+
+==== Required Information
+
+* *Description*: Clear explanation of the vulnerability
+* *Impact*: What an attacker could achieve (confidentiality, integrity,
+availability)
+* *Affected versions*: Which versions/commits are affected
+* *Reproduction steps*: Detailed steps to reproduce the issue
+
+==== Helpful Additional Information
+
+* *Proof of concept*: Code, scripts, or screenshots demonstrating the
+vulnerability
+* *Attack scenario*: Realistic attack scenario showing exploitability
+* *CVSS score*: Your assessment of severity (use
+https://www.first.org/cvss/calculator/3.1[CVSS 3.1 Calculator])
+* *CWE ID*: Common Weakness Enumeration identifier if known
+* *Suggested fix*: If you have ideas for remediation
+* *References*: Links to related vulnerabilities, research, or
+advisories
+
+==== Example Report Structure
+
+[source,markdown]
+----
+## Summary
+[One-sentence description of the vulnerability]
+
+## Vulnerability Type
+[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
+
+## Affected Component
+[File path, function name, API endpoint, etc.]
+
+## Affected Versions
+[Version range or specific commits]
+
+## Severity Assessment
+- CVSS 3.1 Score: [X.X]
+- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
+
+## Description
+[Detailed technical description]
+
+## Steps to Reproduce
+1. [First step]
+2. [Second step]
+3. [...]
+
+## Proof of Concept
+[Code, curl commands, screenshots, etc.]
+
+## Impact
+[What can an attacker achieve?]
+
+## Suggested Remediation
+[Optional: your ideas for fixing]
+
+## References
+[Links to related issues, CVEs, research]
+----
+
+'''''
+
+=== Response Timeline
+
+We commit to the following response times:
+
+[width="100%",cols="24%,35%,41%",options="header",]
+|===
+|Stage |Timeframe |Description
+|*Initial Response* |48 hours |We acknowledge receipt and confirm we’re
+investigating
+
+|*Triage* |7 days |We assess severity, confirm the vulnerability, and
+estimate timeline
+
+|*Status Update* |Every 7 days |Regular updates on remediation progress
+
+|*Resolution* |90 days |Target for fix development and release (complex
+issues may take longer)
+
+|*Disclosure* |90 days |Public disclosure after fix is available
+(coordinated with you)
+|===
+
+____
+*Note:* These are targets, not guarantees. Complex vulnerabilities may
+require more time. We’ll communicate openly about any delays.
+____
+
+'''''
+
+=== Disclosure Policy
+
+We follow *coordinated disclosure* (also known as responsible
+disclosure):
+
+[arabic]
+. *You report* the vulnerability privately
+. *We acknowledge* and begin investigation
+. *We develop* a fix and prepare a release
+. *We coordinate* disclosure timing with you
+. *We publish* security advisory and fix simultaneously
+. *You may publish* your research after disclosure
+
+==== Our Commitments
+
+* We will not take legal action against researchers who follow this
+policy
+* We will work with you to understand and resolve the issue
+* We will credit you in the security advisory (unless you prefer
+anonymity)
+* We will notify you before public disclosure
+* We will publish advisories with sufficient detail for users to assess
+risk
+
+==== Your Commitments
+
+* Report vulnerabilities promptly after discovery
+* Give us reasonable time to address the issue before disclosure
+* Do not access, modify, or delete data beyond what’s necessary to
+demonstrate the vulnerability
+* Do not degrade service availability (no DoS testing on production)
+* Do not share vulnerability details with others until coordinated
+disclosure
+
+==== Disclosure Timeline
+
+....
+Day 0          You report vulnerability
+Day 1-2        We acknowledge receipt
+Day 7          We confirm vulnerability and share initial assessment
+Day 7-90       We develop and test fix
+Day 90         Coordinated public disclosure
+               (earlier if fix is ready; later by mutual agreement)
+....
+
+If we cannot reach agreement on disclosure timing, we default to 90 days
+from your initial report.
+
+'''''
+
+=== Scope
+
+==== In Scope ✅
+
+The following are within scope for security research:
+
+* This repository (`+hyperpolymath/nickel-augmentation+`) and all its
+code
+* Official releases and packages published from this repository
+* Documentation that could lead to security issues
+* Build and deployment configurations in this repository
+* Dependencies (report here, we’ll coordinate with upstream)
+
+==== Out of Scope ❌
+
+The following are *not* in scope:
+
+* Third-party services we integrate with (report directly to them)
+* Social engineering attacks against maintainers
+* Physical security
+* Denial of service attacks against production infrastructure
+* Spam, phishing, or other non-technical attacks
+* Issues already reported or publicly known
+* Theoretical vulnerabilities without proof of concept
+
+==== Qualifying Vulnerabilities
+
+We’re particularly interested in:
+
+* Remote code execution
+* SQL injection, command injection, code injection
+* Authentication/authorisation bypass
+* Cross-site scripting (XSS) and cross-site request forgery (CSRF)
+* Server-side request forgery (SSRF)
+* Path traversal / local file inclusion
+* Information disclosure (credentials, PII, secrets)
+* Cryptographic weaknesses
+* Deserialisation vulnerabilities
+* Memory safety issues (buffer overflows, use-after-free, etc.)
+* Supply chain vulnerabilities (dependency confusion, etc.)
+* Significant logic flaws
+
+==== Non-Qualifying Issues
+
+The following generally do not qualify as security vulnerabilities:
+
+* Missing security headers on non-sensitive pages
+* Clickjacking on pages without sensitive actions
+* Self-XSS (requires victim to paste code)
+* Missing rate limiting (unless it enables a specific attack)
+* Username/email enumeration (unless high-risk context)
+* Missing cookie flags on non-sensitive cookies
+* Software version disclosure
+* Verbose error messages (unless exposing secrets)
+* Best practice deviations without demonstrable impact
+
+'''''
+
+=== Safe Harbour
+
+We support security research conducted in good faith.
+
+==== Our Promise
+
+If you conduct security research in accordance with this policy:
+
+* ✅ We will not initiate legal action against you
+* ✅ We will not report your activity to law enforcement
+* ✅ We will work with you in good faith to resolve issues
+* ✅ We consider your research authorised under the Computer Fraud and
+Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
+* ✅ We waive any potential claim against you for circumvention of
+security controls
+
+==== Good Faith Requirements
+
+To qualify for safe harbour, you must:
+
+* Comply with this security policy
+* Report vulnerabilities promptly
+* Avoid privacy violations (do not access others’ data)
+* Avoid service degradation (no destructive testing)
+* Not exploit vulnerabilities beyond proof-of-concept
+* Not use vulnerabilities for profit (beyond bug bounties where offered)
+
+____
+*⚠️ Important:* This safe harbour does not extend to third-party
+systems. Always check their policies before testing.
+____
+
+'''''
+
+=== Recognition
+
+We believe in recognising security researchers who help us improve.
+
+==== Hall of Fame
+
+Researchers who report valid vulnerabilities will be acknowledged in our
+link:SECURITY-ACKNOWLEDGMENTS.md[Security Acknowledgments] (unless they
+prefer anonymity).
+
+Recognition includes:
+
+* Your name (or chosen alias)
+* Link to your website/profile (optional)
+* Brief description of the vulnerability class
+* Date of report
+
+==== What We Offer
+
+* ✅ Public credit in security advisories
+* ✅ Acknowledgment in release notes
+* ✅ Entry in our Hall of Fame
+* ✅ Reference/recommendation letter upon request (for significant
+findings)
+
+==== What We Don’t Currently Offer
+
+* ❌ Monetary bug bounties
+* ❌ Hardware or swag
+* ❌ Paid security research contracts
+
+____
+*Note:* We’re a community project with limited resources. Your
+contributions help everyone who uses this software.
+____
+
+'''''
+
+=== Security Updates
+
+==== Receiving Updates
+
+To stay informed about security updates:
+
+* *Watch this repository*: Click "`Watch`" → "`Custom`" → Select
+"`Security alerts`"
+* *GitHub Security Advisories*: Published at
+https://github.com/hyperpolymath/nickel-augmentation/security/advisories[Security
+Advisories]
+* *Release notes*: Security fixes noted in link:CHANGELOG.md[CHANGELOG]
+
+==== Update Policy
+
+[cols=",",options="header",]
+|===
+|Severity |Response
+|*Critical/High* |Patch release as soon as fix is ready
+|*Medium* |Included in next scheduled release (or earlier)
+|*Low* |Included in next scheduled release
+|===
+
+==== Supported Versions
+
+[cols=",,",options="header",]
+|===
+|Version |Supported |Notes
+|`+main+` branch |✅ Yes |Latest development
+|Latest release |✅ Yes |Current stable
+|Previous minor release |✅ Yes |Security fixes backported
+|Older versions |❌ No |Please upgrade
+|===
+
+'''''
+
+=== Security Best Practices
+
+When using Nickel Augmentation, we recommend:
+
+==== General
+
+* Keep dependencies up to date
+* Use the latest stable release
+* Subscribe to security notifications
+* Review configuration against security documentation
+* Follow principle of least privilege
+
+==== For Contributors
+
+* Never commit secrets, credentials, or API keys
+* Use signed commits (`+git config commit.gpgsign true+`)
+* Review dependencies before adding them
+* Run security linters locally before pushing
+* Report any concerns about existing code
+
+'''''
+
+=== Additional Resources
+
+* link:%7B%7BPGP_KEY_URL%7D%7D[Our PGP Public Key]
+* https://github.com/hyperpolymath/nickel-augmentation/security/advisories[Security
+Advisories]
+* link:CHANGELOG.md[Changelog]
+* link:CONTRIBUTING.md[Contributing Guidelines]
+* https://cve.mitre.org/[CVE Database]
+* https://www.first.org/cvss/calculator/3.1[CVSS Calculator]
+
+'''''
+
+=== Contact
+
+[width="100%",cols="50%,50%",options="header",]
+|===
+|Purpose |Contact
+|*Security issues*
+|https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new[Report
+via GitHub] or 6759885+hyperpolymath@users.noreply.github.com
+
+|*General questions*
+|https://github.com/hyperpolymath/nickel-augmentation/discussions[GitHub
+Discussions]
+
+|*Other enquiries* |See link:README.md[README] for contact information
+|===
+
+'''''
+
+=== Policy Changes
+
+This security policy may be updated from time to time. Significant
+changes will be:
+
+* Committed to this repository with a clear commit message
+* Noted in the changelog
+* Announced via GitHub Discussions (for major changes)
+
+'''''
+
+_Thank you for helping keep Nickel Augmentation and its users safe._ 🛡️
+
+'''''
+
+Last updated: 2026 · Policy version: 1.0.0
diff --git a/augmented/SECURITY.md b/augmented/SECURITY.md
deleted file mode 100644
index a49b3c9..0000000
--- a/augmented/SECURITY.md
+++ /dev/null
@@ -1,410 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Security Policy
-
-<!-- 
-============================================================================
-TEMPLATE INSTRUCTIONS (delete this block before publishing)
-============================================================================
-Replace all {{PLACEHOLDER}} values with your information:
-  Nickel Augmentation     - Your project name
-  hyperpolymath            - GitHub username or org (e.g., hyperpolymath)
-  nickel-augmentation             - Repository name
-  6759885+hyperpolymath@users.noreply.github.com   - Security contact email
-  [PGP fingerprint not set]  - Your PGP key fingerprint (40 chars, no spaces)
-  {{PGP_KEY_URL}}      - URL to your public PGP key
-  {{WEBSITE}}          - Your website/domain
-  2026     - Current year for copyright
-
-Optional: Remove sections that don't apply (e.g., PGP if you don't use it)
-============================================================================
--->
-
-We take security seriously. We appreciate your efforts to responsibly disclose vulnerabilities and will make every effort to acknowledge your contributions.
-
-## Table of Contents
-
-- [Reporting a Vulnerability](#reporting-a-vulnerability)
-- [What to Include](#what-to-include)
-- [Response Timeline](#response-timeline)
-- [Disclosure Policy](#disclosure-policy)
-- [Scope](#scope)
-- [Safe Harbour](#safe-harbour)
-- [Recognition](#recognition)
-- [Security Updates](#security-updates)
-- [Security Best Practices](#security-best-practices)
-
----
-
-## Reporting a Vulnerability
-
-### Preferred Method: GitHub Security Advisories
-
-The preferred method for reporting security vulnerabilities is through GitHub's Security Advisory feature:
-
-1. Navigate to [Report a Vulnerability](https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new)
-2. Click **"Report a vulnerability"**
-3. Complete the form with as much detail as possible
-4. Submit — we'll receive a private notification
-
-This method ensures:
-
-- End-to-end encryption of your report
-- Private discussion space for collaboration
-- Coordinated disclosure tooling
-- Automatic credit when the advisory is published
-
-### Alternative: Encrypted Email
-
-If you cannot use GitHub Security Advisories, you may email us directly:
-
-| | |
-|---|---|
-| **Email** | 6759885+hyperpolymath@users.noreply.github.com |
-| **PGP Key** | [Download Public Key]({{PGP_KEY_URL}}) |
-| **Fingerprint** | `[PGP fingerprint not set]` |
-
-```bash
-# Import our PGP key
-curl -sSL {{PGP_KEY_URL}} | gpg --import
-
-# Verify fingerprint
-gpg --fingerprint 6759885+hyperpolymath@users.noreply.github.com
-
-# Encrypt your report
-gpg --armor --encrypt --recipient 6759885+hyperpolymath@users.noreply.github.com report.txt
-```
-
-> **⚠️ Important:** Do not report security vulnerabilities through public GitHub issues, pull requests, discussions, or social media.
-
----
-
-## What to Include
-
-A good vulnerability report helps us understand and reproduce the issue quickly.
-
-### Required Information
-
-- **Description**: Clear explanation of the vulnerability
-- **Impact**: What an attacker could achieve (confidentiality, integrity, availability)
-- **Affected versions**: Which versions/commits are affected
-- **Reproduction steps**: Detailed steps to reproduce the issue
-
-### Helpful Additional Information
-
-- **Proof of concept**: Code, scripts, or screenshots demonstrating the vulnerability
-- **Attack scenario**: Realistic attack scenario showing exploitability
-- **CVSS score**: Your assessment of severity (use [CVSS 3.1 Calculator](https://www.first.org/cvss/calculator/3.1))
-- **CWE ID**: Common Weakness Enumeration identifier if known
-- **Suggested fix**: If you have ideas for remediation
-- **References**: Links to related vulnerabilities, research, or advisories
-
-### Example Report Structure
-
-```markdown
-## Summary
-[One-sentence description of the vulnerability]
-
-## Vulnerability Type
-[e.g., SQL Injection, XSS, SSRF, Path Traversal, etc.]
-
-## Affected Component
-[File path, function name, API endpoint, etc.]
-
-## Affected Versions
-[Version range or specific commits]
-
-## Severity Assessment
-- CVSS 3.1 Score: [X.X]
-- CVSS Vector: [CVSS:3.1/AV:X/AC:X/PR:X/UI:X/S:X/C:X/I:X/A:X]
-
-## Description
-[Detailed technical description]
-
-## Steps to Reproduce
-1. [First step]
-2. [Second step]
-3. [...]
-
-## Proof of Concept
-[Code, curl commands, screenshots, etc.]
-
-## Impact
-[What can an attacker achieve?]
-
-## Suggested Remediation
-[Optional: your ideas for fixing]
-
-## References
-[Links to related issues, CVEs, research]
-```
-
----
-
-## Response Timeline
-
-We commit to the following response times:
-
-| Stage | Timeframe | Description |
-|-------|-----------|-------------|
-| **Initial Response** | 48 hours | We acknowledge receipt and confirm we're investigating |
-| **Triage** | 7 days | We assess severity, confirm the vulnerability, and estimate timeline |
-| **Status Update** | Every 7 days | Regular updates on remediation progress |
-| **Resolution** | 90 days | Target for fix development and release (complex issues may take longer) |
-| **Disclosure** | 90 days | Public disclosure after fix is available (coordinated with you) |
-
-> **Note:** These are targets, not guarantees. Complex vulnerabilities may require more time. We'll communicate openly about any delays.
-
----
-
-## Disclosure Policy
-
-We follow **coordinated disclosure** (also known as responsible disclosure):
-
-1. **You report** the vulnerability privately
-2. **We acknowledge** and begin investigation
-3. **We develop** a fix and prepare a release
-4. **We coordinate** disclosure timing with you
-5. **We publish** security advisory and fix simultaneously
-6. **You may publish** your research after disclosure
-
-### Our Commitments
-
-- We will not take legal action against researchers who follow this policy
-- We will work with you to understand and resolve the issue
-- We will credit you in the security advisory (unless you prefer anonymity)
-- We will notify you before public disclosure
-- We will publish advisories with sufficient detail for users to assess risk
-
-### Your Commitments
-
-- Report vulnerabilities promptly after discovery
-- Give us reasonable time to address the issue before disclosure
-- Do not access, modify, or delete data beyond what's necessary to demonstrate the vulnerability
-- Do not degrade service availability (no DoS testing on production)
-- Do not share vulnerability details with others until coordinated disclosure
-
-### Disclosure Timeline
-
-```
-Day 0          You report vulnerability
-Day 1-2        We acknowledge receipt
-Day 7          We confirm vulnerability and share initial assessment
-Day 7-90       We develop and test fix
-Day 90         Coordinated public disclosure
-               (earlier if fix is ready; later by mutual agreement)
-```
-
-If we cannot reach agreement on disclosure timing, we default to 90 days from your initial report.
-
----
-
-## Scope
-
-### In Scope ✅
-
-The following are within scope for security research:
-
-- This repository (`hyperpolymath/nickel-augmentation`) and all its code
-- Official releases and packages published from this repository
-- Documentation that could lead to security issues
-- Build and deployment configurations in this repository
-- Dependencies (report here, we'll coordinate with upstream)
-
-### Out of Scope ❌
-
-The following are **not** in scope:
-
-- Third-party services we integrate with (report directly to them)
-- Social engineering attacks against maintainers
-- Physical security
-- Denial of service attacks against production infrastructure
-- Spam, phishing, or other non-technical attacks
-- Issues already reported or publicly known
-- Theoretical vulnerabilities without proof of concept
-
-### Qualifying Vulnerabilities
-
-We're particularly interested in:
-
-- Remote code execution
-- SQL injection, command injection, code injection
-- Authentication/authorisation bypass
-- Cross-site scripting (XSS) and cross-site request forgery (CSRF)
-- Server-side request forgery (SSRF)
-- Path traversal / local file inclusion
-- Information disclosure (credentials, PII, secrets)
-- Cryptographic weaknesses
-- Deserialisation vulnerabilities
-- Memory safety issues (buffer overflows, use-after-free, etc.)
-- Supply chain vulnerabilities (dependency confusion, etc.)
-- Significant logic flaws
-
-### Non-Qualifying Issues
-
-The following generally do not qualify as security vulnerabilities:
-
-- Missing security headers on non-sensitive pages
-- Clickjacking on pages without sensitive actions
-- Self-XSS (requires victim to paste code)
-- Missing rate limiting (unless it enables a specific attack)
-- Username/email enumeration (unless high-risk context)
-- Missing cookie flags on non-sensitive cookies
-- Software version disclosure
-- Verbose error messages (unless exposing secrets)
-- Best practice deviations without demonstrable impact
-
----
-
-## Safe Harbour
-
-We support security research conducted in good faith.
-
-### Our Promise
-
-If you conduct security research in accordance with this policy:
-
-- ✅ We will not initiate legal action against you
-- ✅ We will not report your activity to law enforcement
-- ✅ We will work with you in good faith to resolve issues
-- ✅ We consider your research authorised under the Computer Fraud and Abuse Act (CFAA), UK Computer Misuse Act, and similar laws
-- ✅ We waive any potential claim against you for circumvention of security controls
-
-### Good Faith Requirements
-
-To qualify for safe harbour, you must:
-
-- Comply with this security policy
-- Report vulnerabilities promptly
-- Avoid privacy violations (do not access others' data)
-- Avoid service degradation (no destructive testing)
-- Not exploit vulnerabilities beyond proof-of-concept
-- Not use vulnerabilities for profit (beyond bug bounties where offered)
-
-> **⚠️ Important:** This safe harbour does not extend to third-party systems. Always check their policies before testing.
-
----
-
-## Recognition
-
-We believe in recognising security researchers who help us improve.
-
-### Hall of Fame
-
-Researchers who report valid vulnerabilities will be acknowledged in our [Security Acknowledgments](SECURITY-ACKNOWLEDGMENTS.md) (unless they prefer anonymity).
-
-Recognition includes:
-
-- Your name (or chosen alias)
-- Link to your website/profile (optional)
-- Brief description of the vulnerability class
-- Date of report
-
-### What We Offer
-
-- ✅ Public credit in security advisories
-- ✅ Acknowledgment in release notes
-- ✅ Entry in our Hall of Fame
-- ✅ Reference/recommendation letter upon request (for significant findings)
-
-### What We Don't Currently Offer
-
-- ❌ Monetary bug bounties
-- ❌ Hardware or swag
-- ❌ Paid security research contracts
-
-> **Note:** We're a community project with limited resources. Your contributions help everyone who uses this software.
-
----
-
-## Security Updates
-
-### Receiving Updates
-
-To stay informed about security updates:
-
-- **Watch this repository**: Click "Watch" → "Custom" → Select "Security alerts"
-- **GitHub Security Advisories**: Published at [Security Advisories](https://github.com/hyperpolymath/nickel-augmentation/security/advisories)
-- **Release notes**: Security fixes noted in [CHANGELOG](CHANGELOG.md)
-
-### Update Policy
-
-| Severity | Response |
-|----------|----------|
-| **Critical/High** | Patch release as soon as fix is ready |
-| **Medium** | Included in next scheduled release (or earlier) |
-| **Low** | Included in next scheduled release |
-
-### Supported Versions
-
-<!-- Adjust this table to match your actual version support policy -->
-
-| Version | Supported | Notes |
-|---------|-----------|-------|
-| `main` branch | ✅ Yes | Latest development |
-| Latest release | ✅ Yes | Current stable |
-| Previous minor release | ✅ Yes | Security fixes backported |
-| Older versions | ❌ No | Please upgrade |
-
----
-
-## Security Best Practices
-
-When using Nickel Augmentation, we recommend:
-
-### General
-
-- Keep dependencies up to date
-- Use the latest stable release
-- Subscribe to security notifications
-- Review configuration against security documentation
-- Follow principle of least privilege
-
-### For Contributors
-
-- Never commit secrets, credentials, or API keys
-- Use signed commits (`git config commit.gpgsign true`)
-- Review dependencies before adding them
-- Run security linters locally before pushing
-- Report any concerns about existing code
-
----
-
-## Additional Resources
-
-- [Our PGP Public Key]({{PGP_KEY_URL}})
-- [Security Advisories](https://github.com/hyperpolymath/nickel-augmentation/security/advisories)
-- [Changelog](CHANGELOG.md)
-- [Contributing Guidelines](CONTRIBUTING.md)
-- [CVE Database](https://cve.mitre.org/)
-- [CVSS Calculator](https://www.first.org/cvss/calculator/3.1)
-
----
-
-## Contact
-
-| Purpose | Contact |
-|---------|---------|
-| **Security issues** | [Report via GitHub](https://github.com/hyperpolymath/nickel-augmentation/security/advisories/new) or 6759885+hyperpolymath@users.noreply.github.com |
-| **General questions** | [GitHub Discussions](https://github.com/hyperpolymath/nickel-augmentation/discussions) |
-| **Other enquiries** | See [README](README.md) for contact information |
-
----
-
-## Policy Changes
-
-This security policy may be updated from time to time. Significant changes will be:
-
-- Committed to this repository with a clear commit message
-- Noted in the changelog
-- Announced via GitHub Discussions (for major changes)
-
----
-
-*Thank you for helping keep Nickel Augmentation and its users safe.* 🛡️
-
----
-
-<sub>Last updated: 2026 · Policy version: 1.0.0</sub>
diff --git a/augmented/examples/nickel/README.adoc b/augmented/examples/nickel/README.adoc
new file mode 100644
index 0000000..b5b3f54
--- /dev/null
+++ b/augmented/examples/nickel/README.adoc
@@ -0,0 +1,46 @@
+== Nickel Policy Examples
+
+Example Nickel configurations demonstrating the RSR augmentation
+boundary.
+
+=== Files
+
+[width="100%",cols="21%,31%,48%",options="header",]
+|===
+|File |Purpose |Demonstrates
+|`+contracts.ncl+` |Shared contracts library |RSR language policy
+enforcement, secure hash validation
+
+|`+build.ncl+` |Build configuration |Contract-validated targets and
+dependencies
+
+|`+ci.ncl+` |CI/CD pipelines |Merge semantics for matrix builds, YAML
+generation
+
+|`+infra.ncl+` |Infrastructure config |Type-safe secret references,
+environment configs
+|===
+
+=== Usage
+
+[source,bash]
+----
+# Validate a config
+nickel typecheck build.ncl
+
+# Export CI config to YAML
+nickel export --format yaml ci.ncl | yq '.to_github_actions' > .github/workflows/ci.yml
+
+# Generate environment-specific infra config
+nickel export infra.ncl --field 'export "production"'
+----
+
+=== Boundary Reminder
+
+Nickel handles *build-time configuration with contracts*. It does NOT
+replace:
+
+* `+STATE.scm+` / `+META.scm+` → Guile Scheme (RSR governance)
+* `+guix.scm+` / `+flake.nix+` → Native package managers
+* Runtime config → Environment variables / JSON
+* Application logic → ReScript / Rust
diff --git a/augmented/examples/nickel/README.md b/augmented/examples/nickel/README.md
deleted file mode 100644
index f7da866..0000000
--- a/augmented/examples/nickel/README.md
+++ /dev/null
@@ -1,38 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Nickel Policy Examples
-
-Example Nickel configurations demonstrating the RSR augmentation boundary.
-
-## Files
-
-| File | Purpose | Demonstrates |
-|------|---------|--------------|
-| `contracts.ncl` | Shared contracts library | RSR language policy enforcement, secure hash validation |
-| `build.ncl` | Build configuration | Contract-validated targets and dependencies |
-| `ci.ncl` | CI/CD pipelines | Merge semantics for matrix builds, YAML generation |
-| `infra.ncl` | Infrastructure config | Type-safe secret references, environment configs |
-
-## Usage
-
-```bash
-# Validate a config
-nickel typecheck build.ncl
-
-# Export CI config to YAML
-nickel export --format yaml ci.ncl | yq '.to_github_actions' > .github/workflows/ci.yml
-
-# Generate environment-specific infra config
-nickel export infra.ncl --field 'export "production"'
-```
-
-## Boundary Reminder
-
-Nickel handles **build-time configuration with contracts**. It does NOT replace:
-
-- `STATE.scm` / `META.scm` → Guile Scheme (RSR governance)
-- `guix.scm` / `flake.nix` → Native package managers
-- Runtime config → Environment variables / JSON
-- Application logic → ReScript / Rust
diff --git a/config-reporter/CODE_OF_CONDUCT.adoc b/config-reporter/CODE_OF_CONDUCT.adoc
new file mode 100644
index 0000000..bd2a83c
--- /dev/null
+++ b/config-reporter/CODE_OF_CONDUCT.adoc
@@ -0,0 +1,24 @@
+== Contributor Covenant Code of Conduct
+
+=== Our Pledge
+
+We pledge to make participation a harassment-free experience for
+everyone.
+
+=== Our Standards
+
+*Positive behavior:* * Using welcoming language * Being respectful of
+differing viewpoints * Accepting constructive criticism * Focusing on
+what is best for the community
+
+*Unacceptable behavior:* * Harassment, trolling, or personal attacks *
+Publishing private information without permission
+
+=== Enforcement
+
+Report issues to the maintainers. All complaints will be reviewed.
+
+=== Attribution
+
+Adapted from https://www.contributor-covenant.org/[Contributor Covenant]
+v2.1.
diff --git a/config-reporter/CODE_OF_CONDUCT.md b/config-reporter/CODE_OF_CONDUCT.md
deleted file mode 100644
index bbe9219..0000000
--- a/config-reporter/CODE_OF_CONDUCT.md
+++ /dev/null
@@ -1,30 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-We pledge to make participation a harassment-free experience for everyone.
-
-## Our Standards
-
-**Positive behavior:**
-* Using welcoming language
-* Being respectful of differing viewpoints
-* Accepting constructive criticism
-* Focusing on what is best for the community
-
-**Unacceptable behavior:**
-* Harassment, trolling, or personal attacks
-* Publishing private information without permission
-
-## Enforcement
-
-Report issues to the maintainers. All complaints will be reviewed.
-
-## Attribution
-
-Adapted from [Contributor Covenant](https://www.contributor-covenant.org/) v2.1.
-
diff --git a/config-reporter/CONTRIBUTING.adoc b/config-reporter/CONTRIBUTING.adoc
index e9b1993..2d7853f 100644
--- a/config-reporter/CONTRIBUTING.adoc
+++ b/config-reporter/CONTRIBUTING.adoc
@@ -1,21 +1,109 @@
-// SPDX-License-Identifier: CC-BY-SA-4.0
-// Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
-= Contributing Guide
+== Clone the repository
 
-== Getting Started
+git clone https://github.com/hyperpolymath/nickel-config-reporter.git cd
+nickel-config-reporter
 
-1. Fork the repository
-2. Create a feature branch from `main`
-3. Sign off commits (`git commit -s`)
-4. Submit a pull request
+== Using Nix (recommended for reproducibility)
 
-== Commit Guidelines
+nix develop
 
-* Conventional commits: `type(scope): description`
-* Sign all commits (DCO required)
-* Atomic, focused commits
+== Or using toolbox/distrobox
 
-== License
+toolbox create nickel-config-reporter-dev toolbox enter
+nickel-config-reporter-dev # Install dependencies manually
 
-Contributions licensed under project license.
+== Verify setup
 
+just check # or: cargo check / mix compile / etc. just test # Run test
+suite
+
+....
+
+### Repository Structure
+....
+
+nickel-config-reporter/ ├── src/ # Source code (Perimeter 1-2) ├── lib/
+# Library code (Perimeter 1-2) ├── extensions/ # Extensions (Perimeter
+2) ├── plugins/ # Plugins (Perimeter 2) ├── tools/ # Tooling (Perimeter
+2) ├── docs/ # Documentation (Perimeter 3) │ ├── architecture/ # ADRs,
+specs (Perimeter 2) │ └── proposals/ # RFCs (Perimeter 3) ├── examples/
+# Examples (Perimeter 3) ├── spec/ # Spec tests (Perimeter 3) ├── tests/
+# Test suite (Perimeter 2-3) ├── .well-known/ # Protocol files
+(Perimeter 1-3) ├── .github/ # GitHub config (Perimeter 1) │ ├──
+ISSUE_TEMPLATE/ │ └── workflows/ ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md
+├── CONTRIBUTING.md # This file ├── GOVERNANCE.md ├── LICENSE ├──
+MAINTAINERS.md ├── README.adoc ├── SECURITY.md ├── flake.nix # Nix flake
+(Perimeter 1) └── Justfile # Task runner (Perimeter 1)
+
+....
+
+---
+
+## How to Contribute
+
+### Reporting Bugs
+
+**Before reporting**:
+1. Search existing issues
+2. Check if it's already fixed in `main`
+3. Determine which perimeter the bug affects
+
+**When reporting**:
+
+Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
+
+- Clear, descriptive title
+- Environment details (OS, versions, toolchain)
+- Steps to reproduce
+- Expected vs actual behaviour
+- Logs, screenshots, or minimal reproduction
+
+### Suggesting Features
+
+**Before suggesting**:
+1. Check the [roadmap](ROADMAP.md) if available
+2. Search existing issues and discussions
+3. Consider which perimeter the feature belongs to
+
+**When suggesting**:
+
+Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
+
+- Problem statement (what pain point does this solve?)
+- Proposed solution
+- Alternatives considered
+- Which perimeter this affects
+
+### Your First Contribution
+
+Look for issues labelled:
+
+- [`good first issue`](https://github.com/hyperpolymath/nickel-config-reporter/labels/good%20first%20issue) — Simple Perimeter 3 tasks
+- [`help wanted`](https://github.com/hyperpolymath/nickel-config-reporter/labels/help%20wanted) — Community help needed
+- [`documentation`](https://github.com/hyperpolymath/nickel-config-reporter/labels/documentation) — Docs improvements
+- [`perimeter-3`](https://github.com/hyperpolymath/nickel-config-reporter/labels/perimeter-3) — Community sandbox scope
+
+---
+
+## Development Workflow
+
+### Branch Naming
+....
+
+docs/short-description # Documentation (P3) test/what-added # Test
+additions (P3) feat/short-description # New features (P2)
+fix/issue-number-description # Bug fixes (P2) refactor/what-changed #
+Code improvements (P2) security/what-fixed # Security fixes (P1-2)
+
+....
+
+### Commit Messages
+
+We follow [Conventional Commits](https://www.conventionalcommits.org/):
+....
+
+():
+
+{empty}[optional body]
+
+{empty}[optional footer]
diff --git a/config-reporter/CONTRIBUTING.md b/config-reporter/CONTRIBUTING.md
deleted file mode 100644
index 74db2ad..0000000
--- a/config-reporter/CONTRIBUTING.md
+++ /dev/null
@@ -1,120 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Clone the repository
-git clone https://github.com/hyperpolymath/nickel-config-reporter.git
-cd nickel-config-reporter
-
-# Using Nix (recommended for reproducibility)
-nix develop
-
-# Or using toolbox/distrobox
-toolbox create nickel-config-reporter-dev
-toolbox enter nickel-config-reporter-dev
-# Install dependencies manually
-
-# Verify setup
-just check   # or: cargo check / mix compile / etc.
-just test    # Run test suite
-```
-
-### Repository Structure
-```
-nickel-config-reporter/
-├── src/                 # Source code (Perimeter 1-2)
-├── lib/                 # Library code (Perimeter 1-2)
-├── extensions/          # Extensions (Perimeter 2)
-├── plugins/             # Plugins (Perimeter 2)
-├── tools/               # Tooling (Perimeter 2)
-├── docs/                # Documentation (Perimeter 3)
-│   ├── architecture/    # ADRs, specs (Perimeter 2)
-│   └── proposals/       # RFCs (Perimeter 3)
-├── examples/            # Examples (Perimeter 3)
-├── spec/                # Spec tests (Perimeter 3)
-├── tests/               # Test suite (Perimeter 2-3)
-├── .well-known/         # Protocol files (Perimeter 1-3)
-├── .github/             # GitHub config (Perimeter 1)
-│   ├── ISSUE_TEMPLATE/
-│   └── workflows/
-├── CHANGELOG.md
-├── CODE_OF_CONDUCT.md
-├── CONTRIBUTING.md      # This file
-├── GOVERNANCE.md
-├── LICENSE
-├── MAINTAINERS.md
-├── README.adoc
-├── SECURITY.md
-├── flake.nix            # Nix flake (Perimeter 1)
-└── Justfile             # Task runner (Perimeter 1)
-```
-
----
-
-## How to Contribute
-
-### Reporting Bugs
-
-**Before reporting**:
-1. Search existing issues
-2. Check if it's already fixed in `main`
-3. Determine which perimeter the bug affects
-
-**When reporting**:
-
-Use the [bug report template](.github/ISSUE_TEMPLATE/bug_report.md) and include:
-
-- Clear, descriptive title
-- Environment details (OS, versions, toolchain)
-- Steps to reproduce
-- Expected vs actual behaviour
-- Logs, screenshots, or minimal reproduction
-
-### Suggesting Features
-
-**Before suggesting**:
-1. Check the [roadmap](ROADMAP.md) if available
-2. Search existing issues and discussions
-3. Consider which perimeter the feature belongs to
-
-**When suggesting**:
-
-Use the [feature request template](.github/ISSUE_TEMPLATE/feature_request.md) and include:
-
-- Problem statement (what pain point does this solve?)
-- Proposed solution
-- Alternatives considered
-- Which perimeter this affects
-
-### Your First Contribution
-
-Look for issues labelled:
-
-- [`good first issue`](https://github.com/hyperpolymath/nickel-config-reporter/labels/good%20first%20issue) — Simple Perimeter 3 tasks
-- [`help wanted`](https://github.com/hyperpolymath/nickel-config-reporter/labels/help%20wanted) — Community help needed
-- [`documentation`](https://github.com/hyperpolymath/nickel-config-reporter/labels/documentation) — Docs improvements
-- [`perimeter-3`](https://github.com/hyperpolymath/nickel-config-reporter/labels/perimeter-3) — Community sandbox scope
-
----
-
-## Development Workflow
-
-### Branch Naming
-```
-docs/short-description       # Documentation (P3)
-test/what-added              # Test additions (P3)
-feat/short-description       # New features (P2)
-fix/issue-number-description # Bug fixes (P2)
-refactor/what-changed        # Code improvements (P2)
-security/what-fixed          # Security fixes (P1-2)
-```
-
-### Commit Messages
-
-We follow [Conventional Commits](https://www.conventionalcommits.org/):
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer]
diff --git a/config-reporter/README.adoc b/config-reporter/README.adoc
index 3720f3b..eac6960 100644
--- a/config-reporter/README.adoc
+++ b/config-reporter/README.adoc
@@ -1,64 +1,86 @@
-// SPDX-License-Identifier: CC-BY-SA-4.0
-// Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
-= Nickel Config Reporter
-image:https://img.shields.io/badge/License-MPL--2.0-blue.svg[License: PMPL-1.0,link="https://github.com/hyperpolymath/palimpsest-license"]
+== nickel-config-reporter
 
-:toc: auto
-:icons: font
+image:https://img.shields.io/badge/License-MPL–2.0-blue.svg[License:
+PMPL-1.0,link="`https://github.com/hyperpolymath/palimpsest-license`"]
 
-Audits `.ncl` files for https://github.com/hyperpolymath/rhodium-standard-repositories[RSR] compliance. Part of the https://github.com/hyperpolymath/nickel-augmentation[nickel-augmentation] monorepo.
+A configuration reporter utility with multi-platform SCM mirroring
+infrastructure.
 
-== What It Checks
+=== Overview
 
-[cols="1,1,2"]
-|===
-|Rule |Severity |Description
+This repository provides automated mirroring infrastructure to
+synchronize code across multiple Git hosting platforms:
 
-|SPDX-001 |Error |SPDX-License-Identifier in first 5 lines
-|SPDX-002 |Warning |License is in the approved set (PMPL, MPL-2.0, MIT, etc.)
-|SEC-001 |Error |No `http://` URLs — HTTPS only
-|SEC-002 |Warning |No weak hashes (MD5, SHA-1)
-|LANG-001 |Error |No banned languages in build targets
-|K9-001 |Error |K9 files start with `K9!` magic header
-|K9-002 |Error |K9 files have a `pedigree` section
-|META-001 |Info |Copyright header present
-|TYPE-001 |Error |Nickel typecheck passes
-|===
+* *GitHub* (primary)
+* *GitLab*
+* *Codeberg*
+* *Bitbucket*
 
-== Usage
+=== Features
+
+* *Hub-and-Spoke Mirroring*: GitHub serves as the primary repository
+with automatic mirroring to secondary platforms
+* *Security-First Design*: SSH host key verification, pinned action
+versions, minimal permissions
+* *Conditional Mirroring*: Enable/disable individual mirrors via
+repository variables
+* *Concurrency Safe*: Prevents race conditions during simultaneous push
+events
+
+=== Setup
+
+==== Prerequisites
+
+[arabic]
+. GitHub repository with Actions enabled
+. SSH key pairs generated for each mirror target
+. Organization or repository secrets configured
+
+==== Configuration
+
+===== 1. Generate SSH Keys
+
+For each mirror platform, generate a dedicated SSH key pair:
 
 [source,bash]
 ----
-# Scan current directory
-./bin/config-reporter
+ssh-keygen -t ed25519 -C "mirror-gitlab" -f ~/.ssh/mirror_gitlab
+ssh-keygen -t ed25519 -C "mirror-codeberg" -f ~/.ssh/mirror_codeberg
+ssh-keygen -t ed25519 -C "mirror-bitbucket" -f ~/.ssh/mirror_bitbucket
+----
 
-# Scan a specific directory
-./bin/config-reporter /path/to/project
+===== 2. Add Public Keys to Mirror Platforms
 
-# JSON report (for CI integration)
-./bin/config-reporter --json /path/to/project > report.json
+Add the public key (`+.pub+` file contents) to each platform: -
+*GitLab*: Settings > SSH Keys - *Codeberg*: Settings > SSH/GPG Keys -
+*Bitbucket*: Personal Settings > SSH Keys
 
-# Help
-./bin/config-reporter --help
-----
+===== 3. Configure GitHub Secrets
+
+Add the private keys as secrets in your GitHub repository or
+organization: - `+GITLAB_SSH_KEY+` - `+CODEBERG_SSH_KEY+` -
+`+BITBUCKET_SSH_KEY+`
+
+===== 4. Enable Mirrors
+
+Set repository variables to enable desired mirrors: -
+`+GITLAB_MIRROR_ENABLED+` = `+true+` - `+CODEBERG_MIRROR_ENABLED+` =
+`+true+` - `+BITBUCKET_MIRROR_ENABLED+` = `+true+`
+
+=== Usage
 
-== Exit Codes
+Once configured, the mirroring workflow runs automatically on: - Push to
+`+main+` or `+master+` branches - Manual workflow dispatch from GitHub
+Actions
 
-[cols="1,3"]
-|===
-|Code |Meaning
+=== Security
 
-|0 |All checks passed (warnings and info allowed)
-|1 |Errors found
-|2 |Usage error (bad arguments, directory not found)
-|===
+See SECURITY.md for security policies and best practices.
 
-== Dependencies
+=== Roadmap
 
-- `nickel` (for TYPE-001 typecheck rule)
-- `jq` (for `--json` output)
-- `bash` 4+ (for `mapfile`)
+See ROADMAP.adoc for planned features and development priorities.
 
-== License
+=== License
 
 MPL-2.0
diff --git a/config-reporter/README.md b/config-reporter/README.md
deleted file mode 100644
index 481e649..0000000
--- a/config-reporter/README.md
+++ /dev/null
@@ -1,85 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# nickel-config-reporter
-image:https://img.shields.io/badge/License-MPL--2.0-blue.svg[License: PMPL-1.0,link="https://github.com/hyperpolymath/palimpsest-license"]
-
-
-
-A configuration reporter utility with multi-platform SCM mirroring infrastructure.
-
-## Overview
-
-This repository provides automated mirroring infrastructure to synchronize code across multiple Git hosting platforms:
-
-- **GitHub** (primary)
-- **GitLab**
-- **Codeberg**
-- **Bitbucket**
-
-## Features
-
-- **Hub-and-Spoke Mirroring**: GitHub serves as the primary repository with automatic mirroring to secondary platforms
-- **Security-First Design**: SSH host key verification, pinned action versions, minimal permissions
-- **Conditional Mirroring**: Enable/disable individual mirrors via repository variables
-- **Concurrency Safe**: Prevents race conditions during simultaneous push events
-
-## Setup
-
-### Prerequisites
-
-1. GitHub repository with Actions enabled
-2. SSH key pairs generated for each mirror target
-3. Organization or repository secrets configured
-
-### Configuration
-
-#### 1. Generate SSH Keys
-
-For each mirror platform, generate a dedicated SSH key pair:
-
-```bash
-ssh-keygen -t ed25519 -C "mirror-gitlab" -f ~/.ssh/mirror_gitlab
-ssh-keygen -t ed25519 -C "mirror-codeberg" -f ~/.ssh/mirror_codeberg
-ssh-keygen -t ed25519 -C "mirror-bitbucket" -f ~/.ssh/mirror_bitbucket
-```
-
-#### 2. Add Public Keys to Mirror Platforms
-
-Add the public key (`.pub` file contents) to each platform:
-- **GitLab**: Settings > SSH Keys
-- **Codeberg**: Settings > SSH/GPG Keys
-- **Bitbucket**: Personal Settings > SSH Keys
-
-#### 3. Configure GitHub Secrets
-
-Add the private keys as secrets in your GitHub repository or organization:
-- `GITLAB_SSH_KEY`
-- `CODEBERG_SSH_KEY`
-- `BITBUCKET_SSH_KEY`
-
-#### 4. Enable Mirrors
-
-Set repository variables to enable desired mirrors:
-- `GITLAB_MIRROR_ENABLED` = `true`
-- `CODEBERG_MIRROR_ENABLED` = `true`
-- `BITBUCKET_MIRROR_ENABLED` = `true`
-
-## Usage
-
-Once configured, the mirroring workflow runs automatically on:
-- Push to `main` or `master` branches
-- Manual workflow dispatch from GitHub Actions
-
-## Security
-
-See [SECURITY.md](SECURITY.md) for security policies and best practices.
-
-## Roadmap
-
-See [ROADMAP.adoc](ROADMAP.adoc) for planned features and development priorities.
-
-## License
-
-MPL-2.0
diff --git a/config-reporter/SECURITY.adoc b/config-reporter/SECURITY.adoc
new file mode 100644
index 0000000..29d7712
--- /dev/null
+++ b/config-reporter/SECURITY.adoc
@@ -0,0 +1,83 @@
+== Security Policy
+
+=== Supported Versions
+
+[cols=",",options="header",]
+|===
+|Version |Supported
+|main |:white_check_mark:
+|===
+
+=== Reporting a Vulnerability
+
+If you discover a security vulnerability in this project, please report
+it responsibly:
+
+[arabic]
+. *Do not* create a public GitHub issue for security vulnerabilities
+. Email the maintainer directly at: j.d.a.jewell@open.ac.uk
+. Include as much detail as possible:
+* Description of the vulnerability
+* Steps to reproduce
+* Potential impact
+* Suggested fix (if any)
+
+We aim to respond to security reports within 48 hours and will work with
+you to address the issue promptly.
+
+=== Security Measures in This Repository
+
+==== CI/CD Pipeline Security
+
+* *Action Version Pinning*: All GitHub Actions are pinned to specific
+commit SHAs, not tags
+* *Minimal Permissions*: Workflows use `+permissions: read-all+`
+(principle of least privilege)
+* *SSH Host Key Verification*: Known hosts are verified before SSH
+connections to prevent MITM attacks
+* *Secret Management*: Credentials are stored as GitHub organization
+secrets, never in code
+* *Concurrency Controls*: Mirror operations are serialized to prevent
+race conditions
+* *Job Timeouts*: All jobs have explicit timeouts to prevent runaway
+processes
+
+==== Repository Mirroring
+
+The multi-platform mirroring workflow includes: - SSH key-based
+authentication (no password storage) - Force push capability (required
+for true mirroring, documented) - Conditional execution based on
+repository variables - Independent mirror jobs that can fail without
+affecting others
+
+==== Secrets Required
+
+This repository requires the following secrets at the organization or
+repository level: - `+GITLAB_SSH_KEY+`: Private SSH key for GitLab
+mirror - `+CODEBERG_SSH_KEY+`: Private SSH key for Codeberg mirror -
+`+BITBUCKET_SSH_KEY+`: Private SSH key for Bitbucket mirror
+
+==== Repository Variables
+
+* `+GITLAB_MIRROR_ENABLED+`: Set to `+'true'+` to enable GitLab
+mirroring
+* `+CODEBERG_MIRROR_ENABLED+`: Set to `+'true'+` to enable Codeberg
+mirroring
+* `+BITBUCKET_MIRROR_ENABLED+`: Set to `+'true'+` to enable Bitbucket
+mirroring
+
+=== Best Practices
+
+When contributing to this repository:
+
+[arabic]
+. Never commit secrets, credentials, or API keys
+. Review workflow changes carefully before merging
+. Keep action versions pinned to commit SHAs
+. Use minimal permissions for any new workflows
+. Document any security-sensitive changes
+
+=== License
+
+This project is licensed under MPL-2.0. See the LICENSE file for
+details.
diff --git a/config-reporter/SECURITY.md b/config-reporter/SECURITY.md
deleted file mode 100644
index 61280e0..0000000
--- a/config-reporter/SECURITY.md
+++ /dev/null
@@ -1,71 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# Security Policy
-
-## Supported Versions
-
-| Version | Supported          |
-| ------- | ------------------ |
-| main    | :white_check_mark: |
-
-## Reporting a Vulnerability
-
-If you discover a security vulnerability in this project, please report it responsibly:
-
-1. **Do not** create a public GitHub issue for security vulnerabilities
-2. Email the maintainer directly at: j.d.a.jewell@open.ac.uk
-3. Include as much detail as possible:
-   - Description of the vulnerability
-   - Steps to reproduce
-   - Potential impact
-   - Suggested fix (if any)
-
-We aim to respond to security reports within 48 hours and will work with you to address the issue promptly.
-
-## Security Measures in This Repository
-
-### CI/CD Pipeline Security
-
-- **Action Version Pinning**: All GitHub Actions are pinned to specific commit SHAs, not tags
-- **Minimal Permissions**: Workflows use `permissions: read-all` (principle of least privilege)
-- **SSH Host Key Verification**: Known hosts are verified before SSH connections to prevent MITM attacks
-- **Secret Management**: Credentials are stored as GitHub organization secrets, never in code
-- **Concurrency Controls**: Mirror operations are serialized to prevent race conditions
-- **Job Timeouts**: All jobs have explicit timeouts to prevent runaway processes
-
-### Repository Mirroring
-
-The multi-platform mirroring workflow includes:
-- SSH key-based authentication (no password storage)
-- Force push capability (required for true mirroring, documented)
-- Conditional execution based on repository variables
-- Independent mirror jobs that can fail without affecting others
-
-### Secrets Required
-
-This repository requires the following secrets at the organization or repository level:
-- `GITLAB_SSH_KEY`: Private SSH key for GitLab mirror
-- `CODEBERG_SSH_KEY`: Private SSH key for Codeberg mirror
-- `BITBUCKET_SSH_KEY`: Private SSH key for Bitbucket mirror
-
-### Repository Variables
-
-- `GITLAB_MIRROR_ENABLED`: Set to `'true'` to enable GitLab mirroring
-- `CODEBERG_MIRROR_ENABLED`: Set to `'true'` to enable Codeberg mirroring
-- `BITBUCKET_MIRROR_ENABLED`: Set to `'true'` to enable Bitbucket mirroring
-
-## Best Practices
-
-When contributing to this repository:
-
-1. Never commit secrets, credentials, or API keys
-2. Review workflow changes carefully before merging
-3. Keep action versions pinned to commit SHAs
-4. Use minimal permissions for any new workflows
-5. Document any security-sensitive changes
-
-## License
-
-This project is licensed under MPL-2.0. See the [LICENSE](LICENSE) file for details.
diff --git a/docs/tech-debt-2026-05-26.adoc b/docs/tech-debt-2026-05-26.adoc
new file mode 100644
index 0000000..4063965
--- /dev/null
+++ b/docs/tech-debt-2026-05-26.adoc
@@ -0,0 +1,71 @@
+== Tech-Debt Audit — nickel-augmentation — 2026-05-26
+
+*Source:* estate-wide automated scan 2026-05-26. *Companion:*
+https://github.com/hyperpolymath/standards/tree/main/docs/audits[`+hyperpolymath/standards+`
+2026-05-26-estate-*-debt audits]. *Combined severity:* `+MEDIUM+`.
+
+This file records the _raw findings_ — it does not by itself fix the
+debt. Each section ends with a '`Recommended next move`' line; closing
+the debt is follow-up work.
+
+=== 1. Proof debt
+
+No proof-bearing files (`+*.v+`, `+*.lean+`, `+*.agda+`, `+*.idr+`,
+`+*.idr2+`, `+*.fst+`, `+*.dfy+`, `+*.tla+`, `+*.ads+`, `+*.adb+`) found
+in this repo.
+
+*Recommended next move:* none.
+
+=== 2. Licence debt
+
+[cols=",",options="header",]
+|===
+|Field |Value
+|LICENSE file |`+LICENSE+`
+|SPDX header |`+MPL-2.0+`
+|Manifest licence |`+NONE+`
+|Body classifier |`+Palimp-MPL-2.0+`
+|Severity |`+ok+`
+|===
+
+*Recommended next move:* none for licence.
+
+=== 3. Documentation debt
+
+[cols=",",options="header",]
+|===
+|Field |Value
+|README lines |83
+|`+docs/+` files |0
+|`+docs/+` LoC |0
+|CHANGELOG.md |N
+|CONTRIBUTING.md |Y
+|CODE_OF_CONDUCT.md |Y
+|SECURITY.md |Y
+|Severity |`+MEDIUM+`
+|===
+
+*Recommended next move:* introduce a `+docs/+` directory. The README at
+83 lines has likely grown to do the work of `+docs/+` — split it into a
+thin README + `+docs/architecture.md+`, `+docs/usage.md+`, etc.
+Heavy-wiki exemplars to copy from: `+affinescript+`, `+boj-server+`,
+`+echidna+`, `+hypatia+`.
+
+Additionally: *CHANGELOG.md is missing.* 65% of estate repos lack one —
+adopting a CHANGELOG (or auto-generating via `+git-cliff+`) is a
+recommended estate-wide follow-up.
+
+=== Cross-references
+
+* Estate proof-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md+`
+* Estate licence-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md+`
+* Estate documentation-debt audit:
+`+hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md+`
+
+'''''
+
+🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26).
+This file is informational — closing the debt is follow-up work owned by
+the maintainer.
diff --git a/docs/tech-debt-2026-05-26.md b/docs/tech-debt-2026-05-26.md
deleted file mode 100644
index 82f0460..0000000
--- a/docs/tech-debt-2026-05-26.md
+++ /dev/null
@@ -1,57 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
--->
-
-# Tech-Debt Audit — nickel-augmentation — 2026-05-26
-
-**Source:** estate-wide automated scan 2026-05-26.
-**Companion:** [`hyperpolymath/standards` 2026-05-26-estate-*-debt audits](https://github.com/hyperpolymath/standards/tree/main/docs/audits).
-**Combined severity:** `MEDIUM`.
-
-This file records the *raw findings* — it does not by itself fix the debt. Each section ends with a 'Recommended next move' line; closing the debt is follow-up work.
-
-## 1. Proof debt
-
-No proof-bearing files (`*.v`, `*.lean`, `*.agda`, `*.idr`, `*.idr2`, `*.fst`, `*.dfy`, `*.tla`, `*.ads`, `*.adb`) found in this repo.
-
-**Recommended next move:** none.
-
-## 2. Licence debt
-
-| Field | Value |
-|---|---|
-| LICENSE file | `LICENSE` |
-| SPDX header | `MPL-2.0` |
-| Manifest licence | `NONE` |
-| Body classifier | `Palimp-MPL-2.0` |
-| Severity | `ok` |
-
-**Recommended next move:** none for licence.
-
-## 3. Documentation debt
-
-| Field | Value |
-|---|---|
-| README lines | 83 |
-| `docs/` files | 0 |
-| `docs/` LoC | 0 |
-| CHANGELOG.md | N |
-| CONTRIBUTING.md | Y |
-| CODE_OF_CONDUCT.md | Y |
-| SECURITY.md | Y |
-| Severity | `MEDIUM` |
-
-**Recommended next move:** introduce a `docs/` directory. The README at 83 lines has likely grown to do the work of `docs/` — split it into a thin README + `docs/architecture.md`, `docs/usage.md`, etc. Heavy-wiki exemplars to copy from: `affinescript`, `boj-server`, `echidna`, `hypatia`.
-
-Additionally: **CHANGELOG.md is missing.** 65% of estate repos lack one — adopting a CHANGELOG (or auto-generating via `git-cliff`) is a recommended estate-wide follow-up.
-
-## Cross-references
-
-- Estate proof-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-proof-debt.md`
-- Estate licence-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-licence-debt.md`
-- Estate documentation-debt audit: `hyperpolymath/standards/docs/audits/2026-05-26-estate-documentation-debt.md`
-
----
-
-🤖 Generated by Claude Code estate-wide tech-debt scan (2026-05-26). This file is informational — closing the debt is follow-up work owned by the maintainer.
diff --git a/llm-warmup-dev.adoc b/llm-warmup-dev.adoc
new file mode 100644
index 0000000..f7c1036
--- /dev/null
+++ b/llm-warmup-dev.adoc
@@ -0,0 +1,19 @@
+== LLM Warmup — nickel-augmentation (Developer)
+
+=== What is nickel-augmentation?
+
+See README.adoc for overview.
+
+=== Key Commands
+
+* `+just setup+` — set up development environment
+* `+just build+` — build the project
+* `+just test+` — run tests
+* `+just doctor+` — diagnose issues
+* `+just heal+` — attempt auto-repair
+
+=== Quick Context
+
+* License: MPL-2.0
+* Part of hyperpolymath ecosystem
+* See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-dev.md b/llm-warmup-dev.md
deleted file mode 100644
index a3497ff..0000000
--- a/llm-warmup-dev.md
+++ /dev/null
@@ -1,20 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# LLM Warmup — nickel-augmentation (Developer)
-
-## What is nickel-augmentation?
-See README.adoc for overview.
-
-## Key Commands
-- `just setup` — set up development environment
-- `just build` — build the project
-- `just test` — run tests
-- `just doctor` — diagnose issues
-- `just heal` — attempt auto-repair
-
-## Quick Context
-- License: MPL-2.0
-- Part of hyperpolymath ecosystem
-- See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-user.adoc b/llm-warmup-user.adoc
new file mode 100644
index 0000000..f94898a
--- /dev/null
+++ b/llm-warmup-user.adoc
@@ -0,0 +1,19 @@
+== LLM Warmup — nickel-augmentation (User)
+
+=== What is nickel-augmentation?
+
+See README.adoc for overview.
+
+=== Key Commands
+
+* `+just setup+` — set up development environment
+* `+just build+` — build the project
+* `+just test+` — run tests
+* `+just doctor+` — diagnose issues
+* `+just heal+` — attempt auto-repair
+
+=== Quick Context
+
+* License: MPL-2.0
+* Part of hyperpolymath ecosystem
+* See EXPLAINME.adoc for architecture
diff --git a/llm-warmup-user.md b/llm-warmup-user.md
deleted file mode 100644
index 34a6dcb..0000000
--- a/llm-warmup-user.md
+++ /dev/null
@@ -1,20 +0,0 @@
-<!--
-SPDX-License-Identifier: CC-BY-SA-4.0
-Copyright (c) Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>
--->
-# LLM Warmup — nickel-augmentation (User)
-
-## What is nickel-augmentation?
-See README.adoc for overview.
-
-## Key Commands
-- `just setup` — set up development environment
-- `just build` — build the project
-- `just test` — run tests
-- `just doctor` — diagnose issues
-- `just heal` — attempt auto-repair
-
-## Quick Context
-- License: MPL-2.0
-- Part of hyperpolymath ecosystem
-- See EXPLAINME.adoc for architecture