docs: finish instantiating the RSR docs skeleton

.github/CODEOWNERS

@@ -1,7 +1,7 @@
 # Code Owners
 
 # Default: All contributors with write access are code owners
-* @metadatastician
+* @hyperpolymath
 
 # For specific paths, add explicit owners below
 # Example:

.github/funding.yml

@@ -1,4 +1,4 @@
 # Funding Configuration
 # See: https://docs.github.com/en/repositories/managing-your-repositorys-custom-fields/displaying-a-sponsor-button-in-your-repository
 
-github: metadatastician
+github: hyperpolymath

ARCHITECTURE.md

@@ -1,47 +1,59 @@
-# Architecture
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
 
-## Overview
+# Architecture
 
-This repository follows a modular, maintainable architecture designed for clarity, scalability, and long-term sustainability.
+`technical-notes` is a documentation archive, not a software project:
+it holds short, citable technical notes (Markdown, optionally with a
+Typst source and rendered PDF) that are individually deposited on
+Zenodo with a DOI. There is no source code, no build system, and no
+runtime component.
 
-## Directory Structure
+## Layout
 
 ```
 .
-├── 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
+├── README.md # index of published notes (title, date, DOI)
+├── <note-slug>.md # note source (Markdown)
+├── <note-slug>.pdf # rendered note (optional, Typst-produced)
+├── <note-slug>.typ # Typst source for the PDF (optional)
+├── docs/ # process documentation (this file's siblings)
+├── LICENSE / LICENSES/ # MPL-2.0 (repo tooling/process docs) +
+│ # CC-BY-SA-4.0; individual notes carry
+│ # their own licence at Zenodo-deposit time
+└── .github/ # CI wrappers (governance, security scan)
 ```
 
-## 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
+## The invariant
 
-## Dependencies
+Every note listed in the README resolves to a real, citable Zenodo
+record. If that link breaks, the repo has failed at its one job.
 
-- External dependencies are minimized and clearly declared
-- Version pinning is used for reproducibility
+## Publishing flow
 
-## Security Considerations
+There is no runtime to diagram; the only "flow" is authorial:
 
-- Sensitive data is never committed to the repository
-- Secrets are managed through environment variables or secure vaults
-- Regular dependency audits are performed
+```
+draft note (.md [+ .typ -> .pdf])
+ |
+ v
+ README table entry (title, date, concept DOI, version DOI)
+ |
+ v
+ Zenodo deposit (direct API today; GitHub Release once the
+ Zenodo-GitHub integration is enabled — see README § Zenodo archiving)
+```
 
-## Maintainability
+## Out of scope
 
-- Code follows consistent style guidelines
-- Pull requests require review and CI checks
-- Issues and discussions are tracked transparently
+* No source code, package, or binary is built or shipped from this repo.
+* No API, service, or CLI.
+* No automated test suite — there is no code to exercise.
 
----
+## See also
 
-*Last updated: 2026-07-18*
+* [docs/usage.adoc](docs/usage.adoc) — how to cite a note.
+* [docs/contributing.adoc](docs/contributing.adoc) — how to add a new note.
+* [docs/decisions/](docs/decisions/) — ADRs, historical record of why this shape.

GOVERNANCE.md

@@ -1,60 +1,49 @@
-# Governance
-
-## Overview
-
-This project is governed by the following principles and structures to ensure transparent, inclusive, and effective decision-making.
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
 
-## Roles and Responsibilities
-
-### Maintainers
+# Governance
 
-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
+`technical-notes` is a single-maintainer repository in the
+`hyperpolymath` estate. There is no multi-maintainer or RFC process
+here; estate-wide policy lives in
+[`hyperpolymath/standards`](https://github.com/hyperpolymath/standards).
 
-### Contributors
+## Maintainer
 
-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
+See [`MAINTAINERS`](MAINTAINERS) for who currently maintains this repo.
 
-## Decision Making
+## Decision making
 
-### Minor Changes
-- Can be made by any maintainer
-- Include bug fixes, documentation updates, dependency updates
+The maintainer accepts, revises, or declines contributions directly.
+A non-trivial process change — how notes are drafted, versioned, or
+archived — is recorded as an ADR in
+[`docs/decisions/`](docs/decisions/) rather than decided ad hoc.
 
-### Major Changes
-- Require discussion in issues or pull requests
-- Include new features, architectural changes, API changes
-- Need approval from at least 2 maintainers
+## Licensing
 
-### Breaking Changes
-- Require RFC (Request for Comments) process
-- Need approval from majority of maintainers
-- Must include migration guide
+* Repository tooling and process documentation: MPL-2.0 or
+ CC-BY-SA-4.0 per the SPDX header on each file (see `LICENSE` /
+ `LICENSES/`).
+* Each published note carries its own licence, set at Zenodo-deposit
+ time and recorded in that note's Zenodo metadata (see the root
+ `README.md` § Licence).
 
-## Code of Conduct
+## CI-enforced governance
 
-All participants are expected to follow our Code of Conduct. Violations can be reported to the maintainers.
+SPDX-header presence, licence consistency, secrets scanning, and
+workflow security are enforced by the shared reusable workflow in
+`hyperpolymath/standards`; see
+[`.github/workflows/governance.yml`](.github/workflows/governance.yml)
+and
+[`.github/workflows/hypatia-scan.yml`](.github/workflows/hypatia-scan.yml).
 
 ## 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*
+* **Issues**: bugs or gaps in this repo — broken DOI links, wrong
+ citations, process gaps.
+* **Pull requests**: proposed changes; see
+ [`CONTRIBUTING.md`](CONTRIBUTING.md).
+* **Security**: follow estate policy in `hyperpolymath/standards` —
+ do not file security-relevant findings as public issues.

MAINTAINERS

@@ -1,3 +1,8 @@
+<!--
+SPDX-License-Identifier: CC-BY-SA-4.0
+SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath)
+-->
+
 # Maintainers
 
 This file lists the current maintainers of this project.
@@ -6,38 +11,15 @@ This file lists the current maintainers of this project.
 
 | Name | GitHub | Role | Since |
 |------|--------|------|-------|
-| Metadatastician | @metadatastician | Primary | Project Start |
+| Jonathan D.A. Jewell | [@hyperpolymath](https://github.com/hyperpolymath) | Primary | Project start |
 
 ## Emeritus Maintainers
 
 None at this time.
 
-## Becoming a Maintainer
-
-To become a maintainer:
-
-1. Demonstrate consistent, high-quality contributions
-2. Show understanding of the project's goals and architecture
-3. Be active in code reviews and community discussions
-4. Be nominated by an existing maintainer
-5. Be approved by consensus of existing maintainers
-
-## Maintainer Responsibilities
-
-- Reviewing and merging pull requests
-- Managing releases
-- Triaging issues
-- Enforcing code standards
-- Mentoring new contributors
-- Participating in decision-making
-
-## Maintainer Expectations
-
-- Respond to issues and PRs in a timely manner
-- Follow the code of conduct
-- Be transparent in decision-making
-- Communicate clearly and respectfully
-
----
+## Notes
 
-*Last updated: 2026-07-18*
+This is currently a single-maintainer repository, so there is no
+formal "becoming a maintainer" process. See
+[`GOVERNANCE.md`](GOVERNANCE.md) for how decisions are made and
+[`CONTRIBUTING.md`](CONTRIBUTING.md) for how to propose a change.

docs/architecture.adoc

@@ -1,78 +1,76 @@
 // SPDX-License-Identifier: CC-BY-SA-4.0
 // SPDX-FileCopyrightText: 2026 Jonathan D.A. Jewell (hyperpolymath) <6759885+hyperpolymath@users.noreply.github.com>
 = Architecture — technical-notes
-:revdate: 2026-MM-DD
+:revdate: 2026-07-27
 
 == System overview
 
-One paragraph: what this project does and what it does not do. State the
-*invariant* — the property that, if violated, would make the whole project
-pointless. Future maintainers will read this paragraph first.
+`technical-notes` is a documentation archive, not a running system. It
+holds short, citable technical notes (Markdown, optionally with a Typst
+source and rendered PDF) that are individually deposited on Zenodo with a
+DOI. The invariant that matters: every note listed in the README resolves
+to a real, citable Zenodo record. If that link breaks, the repo has
+failed at its one job.
 
 == Component diagram
 
-Replace this section with an ASCII or Mermaid diagram. Keep it under 20
-lines — anything bigger belongs in `architecture/`.
+There is no runtime component graph. The only "flow" is authorial:
 
 [source]
 ----
-+------------------+ +------------------+
-|Component A | ---> | Component B |
-+------------------++------------------+
- |
- v
-+------------------+
-|Component C |
-+------------------+
+draft note (.md [+ .typ -> .pdf])
+ |
+ v
+README table entry (title, date, concept DOI, version DOI)
+|
+ v
+Zenodo deposit (direct API today; GitHub Release once the
+ Zenodo-GitHub integration is enabled)
 ----
 
 == Data flow
 
-For each external input, describe:
-
-* **Source**: where it comes from.
-* **Validation**: what guarantees we enforce on entry.
-* **Transformation**: high-level processing stages.
-* **Sink**: where the result goes.
+* **Source**: the maintainer's own drafting — no external input feed.
+* **Validation**: none automated beyond estate governance CI (SPDX
+ headers, licence consistency, secrets scanning — see
+ `.github/workflows/governance.yml` and
+ `.github/workflows/hypatia-scan.yml`).
+* **Transformation**: optional Typst → PDF render for notes that ship one.
+* **Sink**: Zenodo (DOI-bearing deposit) and the README index.
 
 == Key invariants
 
-Enumerate the load-bearing invariants of the system. Each should have:
-
-. A one-line statement.
-. The code location(s) that enforce it.
-. The failure mode if the invariant is violated.
-
-Example:
-
 [cols="1,2,2,2", options="header"]
 |===
 | # | Invariant | Enforced at | Failure mode
 
 | 1
-| All HTTP requests carry a valid `X-Request-ID`.
-| `src/middleware/request_id.rs`
-| Logs become unjoinable; correlation breaks.
+| Every README row has a resolvable DOI link.
+| Manual, at note-publish time.
+| Citation breaks; the note becomes unfindable via its concept DOI.
 
 | 2
-| The output buffer is always flushed before exit.
-| `src/main.rs:88-92` (Drop impl)
-| Last ~16KB of log lost on crash.
+| Every published note's licence matches its Zenodo deposit metadata.
+| `.zenodo.json` for the deposited record; manual cross-check.
+| Licence mismatch between GitHub and the archival copy.
 |===
 
 == Dependencies
 
-* **Internal**: list other hyperpolymath repos this depends on.
-* **External**: SHA-pinned (see `Cargo.lock` / `deno.lock` / etc.).
-* **Build-time**: tools required to build (just, deno, cargo, …).
+* **Internal**: none — this repo does not depend on other hyperpolymath
+ repos.
+* **External**: Zenodo (archival + DOI minting).
+* **Build-time**: none to read a note; Typst only when producing a PDF
+ rendering of a note that has one.
 
 == Out of scope
 
-Explicit non-goals. Things we deliberately do *not* do, with a one-line
-reason for each. This section saves more time than the rest combined.
+* No source code, package, or binary is built or shipped from this repo.
+* No API, service, or CLI — there is nothing to run.
+* No automated test suite — there is no code to exercise.
 
 == See also
 
-* link:./usage.adoc[Usage] — consumer perspective.
-* link:./contributing.adoc[Contributing] — developer setup.
+* link:./usage.adoc[Usage] — how to cite a note.
+* link:./contributing.adoc[Contributing] — how to add a new note.
 * link:./decisions/[ADRs] — historical record of why this shape.