How This Works

You're inside the proof.

This site is a semantic memory system you can examine, trace, and verify. The methodology we sell built this page.

This site is built this way. The claims on this site aren't scattered across independent pages. They exist as canonical assertions in a structured knowledge base. The pages you see are derived from those claims. When we update a canonical claim, every page that references it can update.

View the Architecture →

Explore
↓

Five-Layer Architecture

Every page passes through five layers. Claims flow from canonical source to themed output.

architecture:
layer_1: canonical/SMS-CLAIMS.json # Truth source
layer_2: framework/manifests/*.json # Page contracts
layer_3: pages/*.md # Content with claim refs
layer_4: framework/build/ # Build pipeline
layer_5: dist/ # Themed HTML output

No layer operates independently. Each depends on the one above it.

Layer 1: Canonical Claims

The foundation. A single JSON file contains every verified assertion this site can make.

location: canonical/SMS-CLAIMS.json
contents:

Claims are atomic. Each has an ID, short form, full form, source, and confidence level. When a claim changes, it changes once—in this file.

Example claim structure:

{
  "sms-method-01": {
    "id": "sms-method-01",
    "category": "methodology",
    "short": "Verify upstream, generate downstream",
    "full": "Verify upstream, generate downstream. Human verification happens once, at the source.",
    "confidence": "canonical"
  }
}

Layer 2: Manifests

Manifests are contracts. They specify what each page must contain before content exists.

location: framework/manifests/{page-id}-manifest.json
specifies:

The manifest for this page required three specific claims. The build verifies they appear.

Layer 3: Content

Markdown files reference claims by ID. They don't contain the claims—they point to them.

Documents are outputs, not sources. They're generated from canonical claims, not authored independently. One truth, multiple presentations.

A claim reference looks like this in the source:

`<div class="canonical-claim" data-claim-id="sms-method-02" data-category="methodology">
<p class="canonical-claim__text">Documents are outputs, not sources. They're generated from canonical claims, not authored independently. One truth, multiple presentations.</p>

</div>`

The build pipeline resolves these references. If a claim ID doesn't exist, the build fails. If a claim changes in the canonical file, every page referencing it updates.

Layer 4: Build Pipeline

The pipeline transforms content into output. It validates, resolves, and generates.

pipeline_stages:
1_validate: Check manifests against pages
2_resolve: Replace claim references with content
3_verify: Run manifest verification checks
4_transform: Apply templates and themes
5_generate: Output themed HTML

Build commands:

# Lint markdown (STAGE 3)
cd build
python lint.py --all

# Refine voice (STAGE 3.5)
python refine.py --all

# Generate HTML (STAGE 4)
python generate.py          # Dev build
python generate.py --prod   # Production build

Layer 5: Themed Output

Final HTML lives in the output directory. Each vertical gets its own theme.

output_structure:

Same claims, different presentations. A healthcare page and a general page can reference the same claim. Each renders with appropriate styling.

Theme System

Verticals have distinct color systems. The theme layer applies visual identity without changing content.

Vertical Theme Class Accent Purpose
Core (none) Teal General methodology
Healthcare theme-healthcare Green Clinical knowledge
Software theme-software Amber Development focus
Retail theme-retail Pink Commerce emphasis
Education theme-education Indigo Learning context

Content flows through. Theme wraps it.

Trace Any Claim

Pick any claim on this site. Trace it back.

  1. View the rendered page (you're here)
  2. Find the claim reference in pages/how-this-site-works.md
  3. Look up the claim ID in canonical/SMS-CLAIMS.json
  4. Check the manifest in framework/manifests/how-this-site-works-manifest.json
  5. Verify the claim was required or permitted

Every assertion has provenance. Nothing appears without a source.

Build Commands

Reproduce this site locally.

# Clone the repository
git clone https://github.com/semanticmemorysystems/site.git

# Install dependencies
pip install -r requirements.txt

# Run full build
cd build
python generate.py --prod

# Preview locally
cd ../output
python -m http.server 8000

The build either succeeds or fails. No partial states. If a required claim is missing, you'll know.

What This Proves

One truth, multiple presentations. The same claim might appear as a formal policy statement, a simplified FAQ answer, a training bullet, or a chatbot constraint. The presentations differ in format—but they never contradict because they share a source.

This site demonstrates four architectural properties:

  1. Single source of truth — Claims exist in one place
  2. Derivation, not duplication — Pages reference, not copy
  3. Manifest contracts — Requirements are explicit and verified
  4. Traceable provenance — Every assertion has an origin

The methodology we describe is the methodology we use. You can verify it.

Ready to build semantic memory for your organization?

Start a Conversation →

See the Full Methodology → | View Proof Points →