Take this forward.

Section 01Substrate philosophy & style

The five axioms

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

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

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

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

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.

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

The three production skill packs

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

Section 04Canvas operations

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:

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.

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 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

Languages

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)

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

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

Section 08Onboarding sequence

Section 09Production patterns

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

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.