MEMEROOT · OPERATIONS · CANONICAL REFERENCE

# Take this forward.

A practitioner's playbook for running Memeroot at production quality. Ten sections: substrate philosophy and style, development environment, skills inventory, canvas operations, CLI workflows, tool stack, quality discipline, onboarding sequence, production patterns, and roadmap.

Read top-to-bottom for first-time setup; jump by section thereafter. Every concrete recommendation includes the rationale and the trade-off. Where a choice exists, defaults are stated; where defaults don't generalise, the document says so.

## Section 01Substrate philosophy & style

Everything that follows is downstream of five axioms about how knowledge artifacts should behave. The axioms drive the technology choices, the visual style, the naming conventions, and the communication tone. They are not preferences. They are constraints that determine which behaviours are possible.

### The five axioms

Axiom I
Purity of resolution

Every value in the substrate must resolve to exactly one canonical byte sequence. Whitespace tolerance, attribute-order tolerance, encoding tolerance — all forbidden. A value either matches a hash exactly or it does not.

Axiom II
Byte-stability

Parsing then serialising a region must reproduce the same bytes. If a roundtrip changes one byte, signatures break, hashes break, the audit trail breaks. Tools that don't preserve byte stability cannot be used inside the substrate.

Axiom III
Null-strict canonicalisation

There is no “close enough”. No similarity scores, no cosine distances, no fuzzy matching at the trust layer. A signature verifies or it does not. A hash matches or it does not. The substrate refuses to express uncertainty about identity.

Axiom IV
Content addressing

The hash of a region is the region's identity. Location, filename, URL — all of these are mutable pointers. Only the content hash is the identity. Move a region across systems, the hash travels with it; only the pointer changes.

Axiom V
Total provenance

Every meaningful claim chains to a signed identity. Anonymous content can exist in the substrate, but it is marked as such; it cannot pose as attested. The boundary between “someone said this” and “this identity signed this” is bright and observable.

### What the axioms permit

The axioms permit cryptographic verification of every claim, federated trust without a central operator, byte-identical reproduction across systems, content survival across infrastructure change, and audit trails that survive both the original system and the original organisation. These are properties no platform built on similarity, vector search, or non-canonical serialisation can offer.

### Visual style guide

The visual style is deliberately consistent across every Memeroot artifact: documents, canvas surfaces, demo packets, skill bundles. The consistency is the brand; deviation from it is itself a signal that the artifact comes from elsewhere.

#### Palette

bg-deep#06080b
bg#0a0d11
bg-card#12161c
accent#d4a574 · gold
accent-2#8fa9c4 · steel
accent-3#c97a7a · rose
verify#7eb87e · sage
ink#d8dde4

#### Typography

Monospace · JetBrains Mono
  For code, identifiers, eyebrow labels, table cells, navigation, technical metadata. Falls back to `SF Mono`, `Consolas`, `Liberation Mono`.
Serif · Cormorant Garamond
  For prose, headings, descriptions, italicised emphasis. Falls back to `Iowan Old Style`, `Georgia`. The italic is doing work — used to mark emphasis, terms-of-art, and the document's own voice.

No sans-serif body text. No emoji. No icons that aren't either Unicode mark characters (`·` `◇` `◫` `◐` `⤞`) or hand-tuned SVG. The dual-typeface system (mono + serif) maps to the dual nature of the substrate: precise machine-verifiable claims rendered alongside human prose.

#### Tone

Precise, evidence-first, devoid of marketing language. What it does over why it's better. Numbers are specific. Claims are verifiable. Verbs are active. The eyebrow labels carry the technical category in uppercase tracking; the headings carry the human-facing name in italic serif.

### Naming conventions

Artifact | Pattern | Example
--- | --- | ---
Document | MEMEROOT-{TYPE}-{DOMAIN}-{YEAR}-{NNN} | MEMEROOT-NUM-GEO-2026-001
Region (control) | {DOMAIN}-{TYPE}-{NNN} | REV-CTRL-001
Region (test) | {KIND}-{CONTROL}-{PERIOD} | TOE-REV-001-2026Q1
Region (embed) | EMBED-{SUBJECT}-{PERIOD} | EMBED-DASHBOARD-Q1-2026
Region (finding) | F-{YEAR}-{PERIOD}-{NNN} | F-2026-Q1-014
Workspace | WS-{SUBJECT}-{DATE} | WS-REV-001-2026Q1-AUDIT
Skill pack | {role}-{domain}-author | regulated-document-author
Canvas feature | feature-{name}-{verb}.xml | feature-iframe-region-renderer.xml
Catalog entry | {category}-{name} | viz-mixed-demo-packet
Identity | {Person} · {Org} · {Role} | Sarah Chen · Acme · Control Owner

The patterns are unambiguous, sortable, and survive copy-paste across systems. Hyphens not underscores. Uppercase for short identifying parts. Lowercase-with-hyphens for descriptive parts. No spaces, no Unicode beyond `·` for human-readable identity labels.

## Section 02Development environment

The substrate is byte-stable; so the tools that handle it must be too. This section is opinionated because the tool choices are constrained by the substrate's behaviour, not by preference. Use what's here unless you have a specific reason to deviate, and if you deviate, document why.

### Editor

Primary recommendation: Cursor or VS Code. Both ship with first-class git integration, robust XML/HTML/JS support, and integrated terminal. Cursor adds AI-assisted code completion that pairs naturally with Claude Code workflows.

Secondary options if the team has strong preferences: Zed (faster, lighter, growing ecosystem), Neovim with `nvim-lspconfig` and tree-sitter (for terminal-first practitioners). Avoid tools that don't handle raw text-byte fidelity — Word, Google Docs, Notion's rich-text editor — for anything that will be signed or hashed.

#### Required editor settings

Line endings
  `LF` only (never CRLF). Configure `.editorconfig` at the repo root.
Trailing whitespace
  Strip on save. CRLF or trailing whitespace will change content hashes and break signatures.
Final newline
  Always present. Most generators emit one; tools that strip it cause inconsistent canonical forms.
UTF-8 encoding
  Always. No BOM (the `tolerant-paste` canvas feature handles BOM but the source should not have one to begin with).
Tab vs space
  2-space indentation for XML, JSON, HTML, JS. Tabs allowed in Makefiles and certain shell scripts where required by the format.

#### .editorconfig template

    root = true

    [*]
    end_of_line = lf
    insert_final_newline = true
    charset = utf-8
    trim_trailing_whitespace = true
    indent_style = space
    indent_size = 2

    [*.{md,txt}]
    trim_trailing_whitespace = false  # preserve hard line breaks

    [Makefile]
    indent_style = tab

### Runtime

Tool | Version | Used for
--- | --- | ---
Node.js | `≥ 18.x` (LTS preferred) | CLI, skill packs, build scripts, browser-side crypto, jsdom-based testing. Requires WebCrypto (built-in since 18).
npm or pnpm | npm 10+, pnpm 9+ | Dependency management. `pnpm` preferred for disk efficiency in multi-package repos.
Git | `≥ 2.40` | Version control. Configure `core.autocrlf = false` to prevent CRLF substitution.
Bash / Zsh | any modern POSIX | Glue scripting, capture pipelines, CI invocation.
Browser | any current Chrome, Firefox, Safari, Edge | Canvas operations, signing, bundle export. WebCrypto required.
Python 3.11+ | optional | Only if data-processing pipelines need it. Avoid for substrate work — Node has better byte-stability guarantees in WebCrypto context.

### Claude Code setup

    $ npm install -g @anthropic-ai/claude-code
    $ export ANTHROPIC_API_KEY="sk-ant-..."          # or via direnv / 1Password CLI
    $ mkdir -p ~/.claude/skills/
    $ claude --version
    claude-code 0.x.y

The skills directory `~/.claude/skills/` is where production skill packs are installed. Each pack is a folder whose `SKILL.md` documents the skill; Claude Code reads them on startup and activates them based on the description's trigger keywords.

### Identity management

An identity is an ECDSA P-256 keypair. The fingerprint (first 16 hex of SHA-256 of the SPKI public key) is the identity's stable handle. Identities have human-readable labels (`Sarah Chen · Acme · Control Owner`) for display but the cryptographic identity is the keypair.

#### Storage

Development identities
  Generated in-canvas via Sign tab → Generate Identity. Stored in browser `localStorage`. Acceptable for solo dev work.
Production individual identities
  OS keychain (macOS Keychain, Linux Secret Service, Windows DPAPI) accessed via 1Password CLI, `secret-tool`, or equivalent. Private keys never on disk in plaintext.
Production organisational identities
  HSM-backed (YubiKey, Nitrokey, AWS KMS, GCP KMS, Azure Key Vault). Sign operations call out to the HSM; private key material never leaves the device.
Public keys
  Commit to the repo. Public keys are not secrets. A team's `identities/` folder containing `*.pubkey.json` files is canonical.

#### Never

Commit a private key file to source control, ever, even “just for development”. Use `.gitignore` + repo-level secret scanning (GitHub secret scanning, `gitleaks`) to enforce this mechanically.

### Working directory layout

    ~/memeroot/
    ├── .editorconfig
    ├── .gitignore                       # identities/private/**, *.private.json, .env
    ├── README.md
    │
    ├── identities/
    │   ├── public/                      # committed to repo
    │   │   ├── rob-anderson.pubkey.json
    │   │   ├── memeroot-publisher.pubkey.json
    │   │   └── README.md
    │   └── private/                     # gitignored; backed up to keychain only
    │
    ├── canvases/
    │   ├── MR-CANVAS-v0.8.html
    │   └── working/                     # local working canvases per project
    │
    ├── workspaces/                      # in-progress region XML
    │   ├── REV-001-Q1-2026/
    │   │   ├── control.xml
    │   │   ├── tod.xml
    │   │   ├── toe.xml
    │   │   └── evidence-dashboard.xml
    │   └── ...
    │
    ├── bundles/                         # exported signed bundles, immutable
    │   └── audit-packets/
    │       └── REV-001-2026Q1.html
    │
    ├── skills/                          # local skill development
    │   ├── regulated-document-author/   # symlink to ~/.claude/skills/...
    │   ├── memeroot-bridge/
    │   └── iframe-snapshot-author/
    │
    ├── features/                        # canvas features under development
    │   ├── feature-iframe-region-renderer.xml
    │   ├── feature-svg-region-renderer.xml
    │   └── feature-tolerant-paste.xml
    │
    ├── catalog/                         # catalog publisher's working tree
    │   ├── entries/
    │   ├── build-catalog.js
    │   └── memeroot-catalog.html
    │
    └── scripts/
        ├── capture.js
        ├── sign-region.js
        └── build-delivery.sh

This layout is canonical. Deviating is fine for solo work; teams should adopt it because cross-referencing tools (CI, skill discovery, sign helpers) assume these paths.

## Section 03Skills inventory & installation

Claude Code with the right skills installed becomes an operator rather than an assistant. Each production skill is a body of domain knowledge plus templates and helper scripts; together they encode workflows that would otherwise require an experienced practitioner to walk through manually.

### The three production skill packs

Skill | Triggers when | Produces
--- | --- | ---
regulated-document-author | SOX controls, FDA submissions, IRB protocols, GxP records, audit packets, compliance attestations | Structured XML regions following the relevant framework (PCAOB AS 2201, ICH GCP, 21 CFR Part 11, AICPA AU-C 265). 6 templates + checklist + worked example.
memeroot-bridge | Any output destined for Memeroot canvas; mentions of region, workspace, signed content | Well-formed XML with stable IDs, addressable regions, no fake signatures, composable workspace bundles. 7 templates spanning generic + iframe + SVG region kinds.
iframe-snapshot-author | Capturing external HTML as evidence; mentions of snapshot, freeze content, audit-grade capture | iframe-region XML with embedded HTML CDATA + SHA-256 captured-hash. Includes Node.js capture script and shell variant.

### Installation

    # From the official memeroot-delivery.zip
    $ mkdir -p ~/.claude/skills/
    $ cd ~/.claude/skills/
    $ unzip ~/Downloads/regulated-document-author.zip
    $ unzip ~/Downloads/memeroot-bridge.zip
    $ unzip ~/Downloads/iframe-snapshot-author.zip

    # Verify each pack's manifest signature
    $ for d in regulated-document-author memeroot-bridge iframe-snapshot-author; do
          echo "=== $d ==="
          cat ~/.claude/skills/$d/skill-manifest.json | head -20
      done

    # Restart Claude Code (or start a new session)
    $ claude
    # Skills appear in the active set; ask Claude "list active skills" to confirm

### Verification

Each skill pack ships with a `{name}-bundle.html` companion file — open in any browser to see every file in the pack with both author and reviewer signatures verifying via WebCrypto. Run this verification on first install, especially if you received the pack via a channel you didn't fully trust. Tamper at any layer will be visible.

    $ open regulated-document-author-bundle.html
    # Status bar: "✓ all 9 files verified by both author and reviewer"
    # Click any file to inspect content + see signatures verify

### The update / fork pattern

Skills should not be edited in place. The pattern is:

1. Keep the original pack unchanged in `~/.claude/skills/{name}/`
2. Create a fork at `~/.claude/skills/{name}-{your-suffix}/`
3. Add your customisations as new files (don't modify originals)
4. Sign your additions with your own identity
5. Maintain a `fork-manifest.json` referencing the original manifest hash

This pattern preserves cryptographic lineage. Consumers of your fork can verify both the original publisher's signatures on the inherited files AND your signature on your additions. The lineage proves your fork is derivative, not adversarial.

### Planned skill packs

Skill | Domain | Status
--- | --- | ---
memeroot-canvas-feature-author | Building new canvas features in the federation pattern | Planned · Q3 2026
memeroot-publisher | Orchestrating catalogs + bundles + multi-publisher trust | Planned · Q3 2026
defense-contract-author | DFARS 7012, NIST SP 800-171, supply chain cybersecurity | Backlog
drug-development-cmc-author | FDA Module 3, ICH Q-series, batch records, validation | Backlog
mortgage-underwriting-decision-author | TRID, RESPA, ECOA, fair-lending documentation | Backlog
kyc-aml-decision-author | KYC/CDD, SAR, transaction-monitoring rationale | Backlog
medical-device-510k-author | FDA 510(k) submissions, risk analysis, design history | Backlog

## Section 04Canvas operations

The canvas (`MR-CANVAS-v0.8.html`) is the substrate's local runtime. Every signing operation, every region ingestion, every bundle export happens inside a browser tab. No data ever leaves the user's machine during canvas operations; the canvas contacts no server.

### Recommended feature set

The canvas ships with three bootstrap features (registries, readers-base, tree-inspector). For production use, load these additional features on every canvas session:

Feature | Provides | Load when
--- | --- | ---
`feature-tolerant-paste.xml` | Auto-trims BOM, whitespace, markdown fences, prose preamble before parse | Always (load first)
`feature-iframe-region-renderer.xml` | Reader for `<iframe-region>`, sandboxed iframe rendering, captured-hash verification | Any session with iframe-regions
`feature-svg-region-renderer.xml` | Reader for `<svg-region>`, inline SVG rendering, sanitization, captured-hash verification | Any session with svg-regions

A workspace canvas template that loads these on boot can be saved as `working-canvas.html` in your `canvases/` directory.

### Identity creation

In the Sign tab: click Generate Identity → enter human-readable label → keypair is generated in-browser via WebCrypto and stored in `localStorage`. Export the public key for inclusion in your repo's `identities/public/` folder; export the private key separately and store in your password manager / keychain.

#### Identity hygiene

One identity per role, per individual. Sarah Chen as Control Owner is a different keypair from Sarah Chen as CFO is a different keypair from Sarah Chen as Audit Committee Chair. Mixing roles on one key destroys the separation-of-duties signal that signatures are meant to carry.

### The end-to-end workflow

    # 1. Author in Claude Code (with skills active)
    $ claude
    user> Help me document REV-001 for Q1 SOX testing as a Memeroot packet
    # Claude Code produces control.xml, tod.xml, toe.xml + supporting evidence.xml

    # 2. Validate
    $ memeroot validate workspaces/REV-001-Q1-2026/*.xml
    ✓ control.xml  <control id="REV-001"> · 1842b
    ✓ tod.xml      <test-of-design id="TOD-REV-001-2026Q1"> · 2410b
    ✓ toe.xml      <test-of-operating-effectiveness id="TOE-REV-001-2026Q1"> · 3104b
    ✓ evidence.xml <iframe-region id="EMBED-DASHBOARD-Q1"> · snapshot 14kb · sha256 verified

    # 3. Package as canvas-ready HTML
    $ memeroot package workspaces/REV-001-Q1-2026/*.xml \
          -o bundles/audit-packets/REV-001-2026Q1-draft.html \
          --title "REV-001 Q1 2026 audit packet"

    # 4. Open in browser, sign as appropriate identities
    $ open bundles/audit-packets/REV-001-2026Q1-draft.html
    #    Sign REV-001 as Control Owner (Sarah Chen)
    #    Sign TOD as Internal Audit Tester (Marcus Patel)
    #    Sign TOE as Internal Audit Tester (Aisha Okonkwo — different from TOD tester)
    #    Sign evidence.xml as Captor (Sarah Chen)

    # 5. Export bundle from Bundle tab → bundle-final.html
    # 6. Deliver via your channel of choice. External auditor opens; WebCrypto verifies all locally.

### Bundle export

The Bundle tab exports a single HTML file containing the canvas + all signed regions + the catalog of public keys for the signers. Recipients open in any browser; WebCrypto re-runs verification automatically.

For long-term archival, store bundles in immutable storage (S3 with object-lock, Azure Blob with immutability policy, GCS with retention policy). A bundle's content hash IS its retention identity — name the file by its first 16 hex of SHA-256.

## Section 05CLI workflows

The `memeroot` CLI bridges Claude Code's authoring with the canvas's signing. Three commands; pure Node.js; no runtime dependencies. Designed to be invoked by Claude Code via the bash tool, by humans at the terminal, or by CI runners.

### The three commands

memeroot validate <file>...
  Well-formedness, stable IDs matching `[A-Za-z][A-Za-z0-9_-]{1,127}`, known region kinds, no fake signatures, no absolute paths, no unfilled `[NEEDS INPUT:…]` placeholders, captured-hash matches snapshot/svg-content CDATA. Exit 0 on pass, 1 on any failure.
memeroot bundle <file>... -o workspace.xml
  Combines multiple region files into one `<workspace>` element. Each input validated first; bundle aborts on failure. Wrapper carries metadata (timestamp, source filenames, region count).
memeroot package <file>... -o packet.html
  Produces a single HTML file containing the canvas + bundled regions + bootstrap script that auto-injects content on page open. The recipient just opens the HTML.

### Daily session pattern

    # A typical control documentation session, ~10 minutes end-to-end

    $ cd ~/memeroot/workspaces
    $ mkdir REV-002-Q1-2026 && cd REV-002-Q1-2026

    $ claude
    user> Document the new Q1 receivables aging control for SOX 404
    # Claude Code produces control.xml, tod.xml, toe.xml

    $ memeroot validate *.xml
    ✓ 3 ok · 0 failed · 0 warnings

    $ memeroot package *.xml -o ../../bundles/audit-packets/REV-002-Q1.html

    $ open ../../bundles/audit-packets/REV-002-Q1.html
    # Sign in browser as appropriate identities

### CI integration

A pull request that adds or modifies regions should be CI-validated. `validate` is the right check: it catches well-formedness errors, ID conflicts, broken hashes, and unfilled placeholders before review.

    # .github/workflows/memeroot-validate.yml
    name: Validate Memeroot regions
    on: [pull_request]

    jobs:
      validate:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v4
          - uses: actions/setup-node@v4
            with:
              node-version: "20"
          - run: npm install -g memeroot-cli
          - run: memeroot validate $(find workspaces -name "*.xml")

### Pre-commit hook

    # .git/hooks/pre-commit (or via the pre-commit framework)
    #!/usr/bin/env bash
    set -e
    changed_xml=$(git diff --cached --name-only --diff-filter=AM | grep '\.xml$' || true)
    if [ -n "$changed_xml" ]; then
      memeroot validate $changed_xml
    fi

This catches problems before commit, before push, before PR — the cheapest place to fix a broken region.

## Section 06Tool stack recommendations

Every recommendation below is a choice the substrate forces — byte-stability, canonical serialization, deterministic builds. Not all programming languages and libraries can preserve those properties; the ones listed can.

### Languages

Language | Use for | Avoid for
--- | --- | ---
JavaScript (Node.js + browser) | Canvas features, CLI commands, build scripts, signing logic, browser-side crypto. The substrate's lingua franca. | —
TypeScript | Production-grade upgrade from plain JS. Same runtime, plus compile-time type checking. Recommended for skill packs that other people will install. | —
Python 3.11+ | Data processing pipelines, ML preprocessing, NLP feature extraction. Only where Node lacks a library; never for substrate operations. | Region authoring, signing, canonical form computation (different serialization conventions break byte-stability)
Bash / Zsh | Glue scripting, capture pipelines (with curl + openssl), CI orchestration, build chains | Anything more than 200 lines (move to Node)
HTML / CSS | Canvas surfaces, demo packets, documentation, embeddable widgets | —
XML | Region format, canvas feature definitions, signed artifacts | Configuration files (use JSON), human-edited documents (use Markdown)
JSON | Manifests (skill, catalog), configuration, schema definitions, identity public-key bundles | Anything humans will edit extensively (XML or Markdown are kinder)
Markdown | SKILL.md, README.md, INSTALL.md, ADRs, runbooks | —
Rust | If you build a substrate runtime that runs outside a browser (e.g. a verifier CLI in a regulated environment), Rust gives byte-exact control and portable binaries. | Day-to-day skill authoring (Node is faster to iterate)
Go | Alternative to Rust for a portable verifier; simpler concurrency story. | Day-to-day skill authoring

### Libraries

#### Required

jsdom (≥ 22.x)
  Server-side DOM for canonical form computation, region manipulation in build scripts, and headless testing of canvas behaviour. The canonical XMLSerializer in jsdom matches the canvas's browser-side serializer; this is what makes signing pipelines work.
node:crypto.webcrypto (built-in)
  ECDSA P-256 signing/verification, SHA-256 hashing. Identical API to `window.crypto.subtle` in browsers; code written against this works in both environments.

#### Strongly recommended

prettier (≥ 3.x)
  Opinionated formatter. Configures with `.prettierrc`. Run on commit via husky / pre-commit.
eslint (≥ 9.x)
  Linting for JS/TS. With `eslint-config-prettier` to avoid conflicts.
vitest or node:test
  Test runner. `vitest` for skill packs with browser-like APIs; `node:test` (built-in) for pure-Node code.
tsx
  Run TypeScript files directly without a build step. Useful for one-off scripts and CI checks.
direnv
  Per-directory `.envrc` files. Auto-load `ANTHROPIC_API_KEY` when entering a project, unload when leaving. Pairs with 1Password CLI for never-in-shell secrets.
1Password CLI / vault
  Secret retrieval at runtime. `op run --env-file=.env -- node script.js`.

#### Optional but useful

zod
  Runtime schema validation for JSON. Useful for skill manifests, catalog entries, identity files.
pino
  Structured logging in Node. Fast, JSON-output, plays well with log aggregators.
monolith
  Capture a URL as a single self-contained HTML file with all CSS/JS/images inlined. Use as upstream of `iframe-snapshot-author` for fidelity-critical captures.
pdf-lib / pdfkit
  If you need `pdf-region` rendering. `pdf-lib` for embedding existing PDFs; `pdfkit` for generating them.
D2 or Mermaid
  Diagrams-as-code, rendered to SVG. D2 syntax is cleaner; Mermaid has wider tooling support. Either produces SVG suitable for `svg-region` embedding.

### Dev tools (terminal & OS)

Tool | Use
--- | ---
`tmux` or `zellij` | Terminal multiplexing for long-running sessions
`jq` | JSON query/manipulation in shell pipelines
`yq` | YAML/XML query (alternative to xmllint for simple cases)
`xmllint` (libxml2) | XML validation, XPath, pretty-printing
`httpie` or `hurl` | HTTP requests with readable output
`delta` | Git diff with syntax highlighting
`fd` + `ripgrep` (rg) | Fast file finding and content search
`gitleaks` or `trufflehog` | Detect committed secrets at pre-commit time
`act` | Run GitHub Actions locally for debugging

### Documentation tools

Documentation lives in three places: SKILL.md inside each skill pack, README.md inside each repository, and standalone HTML documents in the Memeroot style for shareable deliverables. Markdown for the first two, hand-written HTML (matching this document's style) for the third.

Avoid documentation generators that produce sprawling auto-generated sites. Documentation is content; if it isn't worth a human authoring, it isn't worth reading.

## Section 07Quality discipline

The substrate enforces some things mechanically (signatures, hashes); other things require practice. This section is the practice. It is intentionally short — the practices are few, but each is non-negotiable.

### Code review

- Every PR has a reviewer counter-signature. The author signs; a different identity reviews and signs. Self-merging your own PR signs both sides; this is allowed in solo work but document the role-conflation explicitly.
- Validation runs on every PR. The CI workflow in §5 enforces this. Failing validation blocks merge.
- Signed files require re-signing on modification. This is mechanical: if you change a signed file, its signature must be regenerated by the appropriate identity. Reviewers verify the new signature, not just the diff.
- Diff review focuses on intent, not bytes. Compare what the change does to the documented purpose. Byte-level changes are caught by the validator; reviewers add judgment about whether the change should be happening.

### Signing discipline

- One identity per role per person. A control owner identity is not the same key as a tester identity.
- Roles cannot self-sign across separation-of-duties boundaries: the same identity should never appear as both control owner AND tester on the same control's evidence chain.
- If team size forces role conflation, document it explicitly in the signed artifact (a `<separation-acknowledgement>` child of the region) so the artifact's auditability is preserved.
- Identity rotation: production identities rotate annually (or per the regulatory framework's requirement). Old public keys remain in the repo for historical signature verification; new private keys replace old in HSMs.

### Audit trail preservation

- Fork rather than overwrite. When revising a signed region, create a fork with a `fork-source` reference back to the original. Both versions ship in the audit packet.
- Diffs annotated in fork descriptions. The fork's metadata should explain what changed and why. The diff itself is computable from the two versions; the why is not.
- Bundles are immutable. Once signed and exported, a bundle's bytes are fixed. Revising a bundle means creating a new bundle that supersedes the old; the old bundle remains in archival storage.
- Retention follows the framework. SOX: 7 years. FDA: per the relevant CFR section. ICH GCP: minimum 15 years post-study completion. Configure your archival storage's retention policy accordingly.

### Versioning conventions

Artifact | Versioning scheme | Notes
--- | --- | ---
Skill packs | SemVer: `1.0.0` | Major bump on breaking changes to SKILL.md triggers or output shape
Canvas features | Single integer version: `0.1`, `0.2` | Track in `<feature version="...">`
Catalogs | Date-based: `2026-05-23` | Manifest hash is the cryptographic version
Documents | Sequence: `v1`, `v2` | Embedded in document id; revisions fork
Individual regions | Content-hash (immutable) | The hash IS the version; revisions are new regions with fork-source

## Section 08Onboarding sequence

A practitioner-grade onboarding sequence: Day 1, Week 1, Month 1. Each phase has concrete deliverables. By the end of Month 1, the new operator can produce signed audit-grade artifacts independently.

#### Day 1 · Install, identity, sign

- Install Node.js 18+, Git, Cursor or VS Code, Chrome/Firefox
- Install Claude Code; configure `ANTHROPIC_API_KEY` via direnv + 1Password CLI
- Clone the team's memeroot repo; set up `.editorconfig` and pre-commit hook
- Install the three production skill packs: `regulated-document-author`, `memeroot-bridge`, `iframe-snapshot-author`
- Install memeroot-cli: `npm install -g memeroot-cli`
- Open a working canvas; load `feature-tolerant-paste` + the two renderer features
- Generate your first identity in the canvas Sign tab; back up the private key to your keychain; commit the public key to the repo
- Open the `iframe + svg demo packet` bundle from the delivery; verify all signatures; click into each region to see content + hash verification

Day 1 deliverable: a working environment with one verified identity, all skills installed, and the demo packet successfully opened and verified locally.

#### Week 1 · First signed packet

- Pick a real (or representative sample) compliance scenario — a SOX control, an IRB protocol, an audit finding
- In Claude Code with skills active, produce the relevant regions. Iterate on content; ask Claude Code to refine descriptions, tighten risk language, fill in operational details
- Validate via `memeroot validate`; fix any issues
- If supporting evidence is needed, use the iframe-snapshot-author skill to capture URLs or local HTML files as iframe-regions with embedded snapshots
- Package as a canvas-ready HTML via `memeroot package`
- Open in browser; sign as the appropriate identities (use your test identities for now)
- Export the bundle from the Bundle tab; verify it externally by re-opening and clicking Verify
- Share with a colleague who verifies the bundle on their machine (no service contact)

Week 1 deliverable: one signed bundle that another operator independently verifies. Confirms the trust model works end-to-end in your environment.

#### Month 1 · Integrate into real workflow

- Pick a real compliance cycle (a quarterly SOX test, a regulatory submission, an audit period) and run it through the substrate end-to-end
- Establish role-identity discipline: create separate identities for author, reviewer, approver across the team. Document them in `identities/public/`
- Configure CI: GitHub Actions workflow running `memeroot validate` on every PR
- If your domain isn't covered by the existing skills, fork `regulated-document-author` with your customisations. Maintain the fork-source reference. Sign your fork as the team's publisher identity
- Build your team's first catalog: list the artifacts your team produces, sign as the publisher, distribute
- Train one additional team member through the Day 1 / Week 1 sequence

Month 1 deliverable: the team's compliance cycle produces signed bundles as standard output, with CI validation, multi-identity signing, and at least two operators trained end-to-end.

## Section 09Production patterns

The same substrate runs at three scales. Solo operator, small team, regulated enterprise. The differences are in identity discipline, archival rigor, and CI complexity — not in the underlying tooling.

### Solo operator

Identity
  One identity for everything. Document the role-conflation explicitly. Acceptable when no separation-of-duties requirement applies, common in research, journalism, due-diligence consultancy.
Canvas
  One working canvas; private keys in browser localStorage with regular keychain backups.
Archival
  Personal git repo on GitHub/GitLab with bundle artifacts committed (or LFS for large bundles). Cloud backup of identity public keys.
CI
  Local pre-commit hook; remote CI optional.
Trade-off
  Speed of iteration over formal audit hygiene. Acceptable for solo deliverables that don't claim multi-party attestation.

### Small team (2–10)

Identity
  One identity per role per person. Public keys in repo's `identities/public/`. Private keys in each person's password manager / keychain.
Canvas
  Shared working canvas template (with team's feature set pre-loaded) stored in repo. Each person uses a fresh canvas instance per session.
Archival
  Shared git repo; bundles committed to immutable storage (S3 with object-lock, or equivalent). Catalog publisher role rotates.
CI
  GitHub Actions / GitLab CI runs `memeroot validate` on every PR. Pre-commit hook in addition to CI.
Trust topology
  Team's catalog publisher identity counter-signs entries from team members. Demonstrates federated trust in miniature.
Trade-off
  Some coordination overhead for the role discipline; the audit-trail integrity that comes with it is the return.

### Regulated enterprise (10+)

Identity
  HSM-backed for organisational identities (CFO, Chief Compliance Officer, External Auditor). Individual identities via personal HSMs (YubiKey 5, Nitrokey 3) or platform key vaults (AWS KMS, GCP KMS).
Canvas
  Internal-network-deployed canvas template; canvas is still client-side but the template is curated by Security and updated through change control.
Archival
  Compliance-grade immutable storage with retention policies matching the regulatory framework. Often a dedicated GRC system as the storage backend.
CI
  Full pipeline: validate, sign with build-time identities, push to staging, integration test the bundle in a recipient environment, promote to production storage.
Trust topology
  The organisation runs a catalog. Identities are managed by IAM with formal joiner-mover-leaver processes. Catalog publisher role is itself signed by an organisational root identity.
Integration with existing GRC
  Memeroot bundles function as audit-grade evidence inside Workiva / AuditBoard / ServiceNow GRC / MetricStream / Diligent. The substrate replaces the audit-trail layer of those platforms while leaving the workflow layer intact.
Trade-off
  Substantial setup work to integrate with existing IAM, HSM, archival, and GRC systems. The return is an audit trail that survives platform migrations, vendor changes, and regulatory framework evolution.

### Migration path

A team can start at the solo-operator pattern and incrementally migrate up. Each migration is additive: a solo operator becomes a small team by introducing second identities; a small team becomes a regulated-enterprise deployment by introducing HSMs and immutable storage. Nothing produced at the earlier scale is invalidated by the migration — bundles signed at solo-operator scale remain verifiable forever.

## Section 10Roadmap & open frontiers

Where the substrate is going next. Some items are committed work; others are open questions that the community will answer as Memeroot adoption grows. Listed in approximate priority order, not strict schedule.

### Near-term · committed

- Multi-publisher catalog entries. Replace the placeholder healthcare/finance fork demos with entries signed by genuinely different publisher identities. Demonstrates federated trust structurally rather than narratively.
- Third production skill pack. Highest-leverage candidates: `defense-contract-author` (DFARS + NIST SP 800-171), `drug-development-cmc-author` (FDA Module 3), or `kyc-aml-decision-author`.
- memeroot-canvas-feature-author skill. A meta-skill that teaches Claude Code how to produce new canvas features in the federation pattern. Lets domain teams add region kinds without substrate-author involvement.
- Hardened canvas signing. Move from in-browser localStorage identities to WebAuthn / passkey-backed identities. Same trust model, stronger key custody.

### Mid-term · planned

- Hosted catalog publishing flow. A small web service that accepts signed entry submissions, runs validation, and lets a publisher identity counter-sign for catalog inclusion. The catalog itself remains a static HTML file — the service is only the submission queue.
- Cross-bundle composition. iframe-regions whose snapshot is itself a Memeroot bundle. Workspaces composing workspaces recursively. Already structurally supported; needs a worked example and renderer ergonomics.
- PDF-region. Render embedded PDFs with PDF.js, captured-hash verification, same provenance pattern. Useful for regulatory submissions that arrive as PDFs.
- Memeroot Bloom Cycle integration. Six-stage knowledge lifecycle (Seed → Meme → Root → Foto → Bloom → Log) becomes the documented progression for content moving from authoring to archival.

### Long-term · open frontiers

- Federated catalog network. Multiple publisher catalogs that reference each other, with cross-publisher signature chains. The point at which Memeroot becomes a true ecosystem rather than a tool suite.
- Standards proposal. A document-level standard for content-addressed signed knowledge artifacts. The substrate's properties (axioms I-V) are not specific to Memeroot; they could be the basis of a broader specification.
- Regulator-direct verification. Substrate-aware regulators (SEC, FDA, FCA) accept signed bundles directly as filings, verifying via the same WebCrypto chain as any other recipient. Eliminates the platform-as-intermediary in regulatory reporting.
- Substrate-native LLM training data. Training corpora composed of signed regions with provenance preserved. Models trained on substrate-native data can themselves emit substrate-native output. Closes the loop.