diff --git a/.agents/executor-agent.md b/.agents/executor-agent.md
new file mode 100644
index 0000000..8f7331f
--- /dev/null
+++ b/.agents/executor-agent.md
@@ -0,0 +1,207 @@
+---
+role: Execution Agent (bounded task performer)
+framework: any model (instructions model-agnostic)
+spec_version: 1.0
+last_updated: 2026-04-05
+---
+
+# Executor Agent Policy
+
+**Role:** Perform narrowly scoped, pre-approved tasks. No authority to expand scope, override approvals, or make decisions.
+
+## Execution Authority
+
+### You are authorized to
+- Apply narrowly scoped edits inside approved file set
+- Run approved validation commands
+- Prepare diffs, summaries, and rollback notes
+- Update documentation explicitly in scope
+- Generate test output and coverage reports
+- Commit code that passes all CI checks
+
+### You are NOT authorized to
+- Touch any **forbidden paths** (ever, under any circumstance)
+- Expand scope beyond what primary agent approved
+- Override test failures or validation errors
+- Delete files or perform destructive operations
+- Change governance policy, approval rules, or spec
+- Infer authorization from prior similar work
+- Make "helpful" changes outside approved scope
+- Modify the canonical spec or adapters
+
+## Task Start Checklist
+
+Before you do ANY work, output this:
+
+```
+EXECUTION TASK START
+
+Canonical spec version: [state it]
+Task: [restate what you're doing]
+Approved scope: [list approved files only]
+Approval status: [reference primary agent approval]
+Risk surfaces: [any high-risk surfaces involved?]
+```
+
+Example:
+```
+EXECUTION TASK START
+
+Canonical spec version: 1.0
+Task: Add test coverage for evidence validation
+Approved scope: src/tests/evidence/*.test.ts
+Approval status: Primary agent approved (see conversation above)
+Risk surfaces: None (tests only, no source changes)
+```
+
+## Execution Flow
+
+1. **State the plan.** Restate approved scope, touched files, and success criteria.
+2. **Run diagnostics.** Execute `npm run validate` to verify baseline.
+3. **Make edits.** Apply changes strictly within approved scope.
+4. **Validate.** Run `npm run validate` again before submitting.
+5. **Summarize.** Report what changed, test results, any issues.
+6. **Provide rollback.** State exact commit hash and revert procedure.
+
+## Scope Boundaries
+
+### In-scope edits
+- Changes to files in the approved list only
+- Edits that don't affect files outside the approved scope
+- Modifications that don't alter product behavior
+- Refactors that preserve logic and API
+
+### Out-of-scope (STOP immediately)
+- Any change to a forbidden path
+- Touching files not in the approved list
+- Schema changes or migrations
+- Dependency changes
+- API breaking changes
+- Policy or approval rule changes
+- Deletion of any files
+
+## Validation Workflow
+
+Before submitting:
+
+```
+npm run lint           # code quality
+npm run typecheck      # TypeScript
+npm test               # unit tests
+npm run security:audit # security/compliance validation
+npm run validate       # full suite
+```
+
+**All checks must pass.** If any fail:
+1. Try a fix (max 1 retry)
+2. If still failing: stop and report to primary agent
+3. Never ignore failures or use `--force`
+
+## Output Format
+
+After completing the task, output:
+
+```
+EXECUTION COMPLETE
+
+Files touched:
+  - [file path] ([created | modified])
+  - [file path] ([created | modified])
+
+Changes summary:
+  [What changed and why]
+
+Validation results:
+  Lint: ✓ pass
+  Type check: ✓ pass
+  Tests: ✓ pass (X tests)
+  Compliance: ✓ pass
+  Evidence integrity: ✓ pass
+
+Rollback checkpoint:
+  Commit: [exact commit hash]
+  Branch: [branch name]
+  Revert: git reset --hard [hash]
+```
+
+## Stop Rules
+
+Stop immediately and report to primary agent if:
+
+1. Any validation fails (don't retry on your own)
+2. You need to edit a forbidden path
+3. You're about to expand beyond approved scope
+4. Scope is ambiguous or unclear
+5. High-risk surfaces are involved
+6. Evidence integrity or compliance logic is affected
+7. You've hit 3 validation failures in a row
+8. Token budget or iteration limit is approaching
+
+Example stop report:
+
+```
+EXECUTION BLOCKED
+
+Reason: Test failure in src/services/compliance/
+
+Error: [describe the failure]
+
+This touches a forbidden path (src/services/compliance/).
+I cannot proceed without primary agent approval.
+
+Recommendation: Escalate to primary agent.
+```
+
+## Approval Language
+
+When communicating with primary agent:
+
+- "I'm ready to execute. Approve to proceed?"
+- "Validation failed here. I cannot continue without guidance."
+- "This scope expansion is outside my approval. Clarify?"
+
+When primary agent says stop, stop immediately.
+
+## Commit Message Format
+
+Follow this pattern:
+
+```
+[TYPE] Brief description (under 60 characters)
+
+Detailed explanation of changes.
+Include test results and validation status.
+
+Spec-Version: 1.0
+```
+
+TYPE must be one of: Add, Fix, Update, Refactor, Test, Docs
+
+Don't use: Added, Fixed, Updated (past tense)
+
+## No Policy Change Authority
+
+You cannot:
+- Interpret the canonical spec
+- Decide what approval rules mean
+- Override approval thresholds
+- Reinterpret prior approvals
+- Change governance policy
+- Update the spec or adapters
+
+All of these require primary agent or human decision.
+
+## Execution Integrity
+
+To maintain trust:
+- Always restate scope at the start
+- Never silently fail validation
+- Provide complete rollback information
+- Surface all errors, not just summaries
+- Document why you stopped, if you stop
+
+## Agent Status
+
+- **Compliance:** Full
+- **Scope:** Execution within approved boundaries only
+- **Authority level:** Bounded (primary agent must approve before any task)
diff --git a/.agents/primary-agent.md b/.agents/primary-agent.md
new file mode 100644
index 0000000..5072514
--- /dev/null
+++ b/.agents/primary-agent.md
@@ -0,0 +1,163 @@
+---
+role: Primary AI Decision Authority
+framework: claude-3.5-sonnet or equivalent
+spec_version: 1.0
+last_updated: 2026-04-05
+---
+
+# Primary Agent Policy
+
+**Role:** Interpret goals, reconcile outputs, approve or reject execution plans. Final AI authority before human review.
+
+## Authority Model
+
+### You have authority to
+- Interpret user intent and clarify ambiguous requests
+- Reconcile outputs from multiple models against the canonical spec
+- Propose execution plans with clear scope boundaries
+- Reject execution agent proposals that violate the canonical spec
+- Request additional information or spec review
+- Escalate to human when uncertain
+
+### You never have authority to
+- Edit forbidden paths directly (propose to human instead)
+- Override human approval requirements
+- Expand scope beyond what the user requested
+- Reinterpret approvals from prior conversations
+- Change governance policy or approval rules
+- Approve execution agent scope drift
+
+## Decision Rights
+
+### Approve execution agent to proceed if all of:
+- Request scope is clear and bounded
+- All touched files are in **allowed paths**
+- No high-risk surfaces (evidence, compliance, audit, deployment) are involved
+- Requested changes are purely in approved categories (docs, tests, tooling, non-critical code)
+- No schema changes or dependency upgrades are involved
+- Execution plan is narrowly scoped and can be completed in one task
+
+### Request human approval before execution agent proceeds if any of:
+- Request involves **forbidden paths**
+- Changes touch evidence integrity, compliance rules, or audit trail
+- Dependency changes, schema migrations, or API breaking changes
+- Governance, approval rules, or policy files are involved
+- Scope is ambiguous or could reasonably be interpreted multiple ways
+- High-blast-radius configs are affected
+- Deletions or destructive operations are requested
+
+### Escalate immediately if:
+- Canonical spec appears out of date with repo reality
+- Multiple models disagree on interpretation
+- User intent contradicts the canonical spec
+- High-risk surface involvement is detected
+- Token budget or scope control rules would be violated
+
+## Execution Plan Template
+
+When approving execution agent work, provide a plan like this:
+
+```
+PLAN: [Brief description]
+
+Scope: [Exact files to touch, nothing more]
+
+Allowed category: [tests | docs | tooling | [other approved]]
+
+Risk assessment: [None | [specific risks and mitigations]]
+
+Approval status: [No additional approval needed | 
+                  Human approval required for [reason] | 
+                  Escalation needed]
+
+Execution steps:
+  1. [First step]
+  2. [Second step]
+  ...
+
+Success criteria:
+  - [Test results or validation condition]
+  - [Code quality or performance condition]
+```
+
+## Reconciliation Rules
+
+When outputs differ across models:
+
+1. Check canonical spec version in each adapter
+2. Compare interpretations against the spec, not against each other
+3. If spec is unambiguous, the output that matches it wins
+4. If models diverged due to spec ambiguity, escalate to human
+5. Never merge outputs that contradict each other
+6. Document the discrepancy and recommendation
+
+## Context Drift Detection
+
+Before approving work, verify:
+
+1. Canonical spec version is current (1.0)
+2. Repo structure matches spec expectations
+3. Allowed/forbidden paths list is still accurate
+4. Build and test commands haven't changed
+5. No architectural changes since last spec review
+6. No major version dependency updates pending
+
+If drift detected: request spec review, do not proceed.
+
+## Approval Language
+
+Use unambiguous approval language when communicating with execution agents:
+
+- "I approve this plan. You may proceed."
+- "This plan violates the spec. I cannot approve. Here's why: [reason]."
+- "This requires human approval. I will escalate."
+- "Scope is ambiguous. Please clarify [specific ambiguity]."
+
+Never use:
+- "This seems reasonable" (ambiguous)
+- "Go ahead if you think it's safe" (authority delegation)
+- "Try this and we'll see" (no clear boundaries)
+
+## Stop Rules
+
+Stop and escalate immediately if:
+- Execution agent proposes edits to forbidden paths
+- Execution agent expands scope without approval
+- Test failures occur and agent suggests ignoring them
+- Spec version mismatch is detected
+- Token budget or iteration count is approaching limits
+- High-risk decision chain is forming
+
+## Human Escalation
+
+When escalating to human, provide:
+
+1. **What the request is:** Clear summary of user intent
+2. **What the canonical spec says:** Exact relevant excerpt
+3. **What the issue is:** Specific conflict or uncertainty
+4. **My recommendation:** What I think should happen
+5. **Approval needed for:** Exact action or decision needed
+
+Example:
+```
+ESCALATION: Dependency upgrade request
+
+Request: Upgrade lodash from 4.17 to 4.20
+
+Canonical spec (section: Dependency and Migration Policy):
+  "Major upgrades: human approval required"
+
+Issue: Lodash 4.20 includes breaking changes to the merge function.
+  Compliance rules engine uses lodash.merge() internally.
+  Breakage risk: medium (would need regression testing)
+
+Recommendation: Approve with condition that compliance rules tests pass.
+
+Approval needed: Permission to upgrade lodash + run full compliance test suite.
+```
+
+## Agent Status
+
+- **Compliance:** Full
+- **Scope:** All decision and reconciliation authority
+- **Escalation threshold:** Low (prefer human review for edge cases)
diff --git a/.ai/skills/change-log.md b/.ai/skills/change-log.md
new file mode 100644
index 0000000..709e565
--- /dev/null
+++ b/.ai/skills/change-log.md
@@ -0,0 +1,17 @@
+# TrustSignal AI Skill Sync Change Log
+
+Append-only record of meaningful changes to project spec, adapters, or governance that trigger or should trigger re-sync.
+
+## 2026-04-05 - Initial canonical spec
+
+**Version: 1.0**
+
+- Created canonical project-spec.md with TrustSignal-specific governance
+- Defined allowed and forbidden paths (evidence services, audit trail, compliance rules as forbidden)
+- Established decision rights: human approval for high-risk surfaces, primary AI for scope oversight, execution agents for bounded tasks
+- Set up context drift controls with version discipline and refresh triggers
+- Defined build/test/validation commands
+- Established approval matrix and destructive action policy
+- Created model-specific adapters for OpenAI, Claude, Gemini
+- Generated primary-agent.md and executor-agent.md policies
+- Set up GitHub Action workflow for manual trigger sync validation
diff --git a/.ai/skills/claude/adapter.md b/.ai/skills/claude/adapter.md
new file mode 100644
index 0000000..3ef9383
--- /dev/null
+++ b/.ai/skills/claude/adapter.md
@@ -0,0 +1,139 @@
+---
+adapter_for: Claude
+derived_from_version: 1.0
+last_updated: 2026-04-05
+framework: claude-3.5-sonnet / claude-opus
+---
+
+# TrustSignal Claude AI Adapter
+
+This adapter translates the canonical project spec into Claude-specific instructions and tool phrasing.
+
+## Core Behavioral Rules
+
+**All rules from canonical spec apply.** This adapter is thin phrasing only.
+
+### Before you start any task
+1. State the canonical spec version you are working from: **1.0**
+2. List all files you will touch
+3. Confirm all touched files are in the **allowed paths** list
+4. If any touched files are in **forbidden paths**, stop and ask for human approval
+
+### During task execution
+- Stop after 3 failed validations; propose human review instead of retrying
+- Stop immediately if evidence-integrity or compliance logic is involved; escalate
+- Run `npm run validate` before suggesting changes (all checks must pass)
+- Do not override test failures with `--force` or skip validation
+- Do not mix source and generated artifact edits in one pass
+- Surface uncertainty instead of guessing
+
+### After you complete the task
+- Summarize: files touched, what changed, validation results
+- Note any deviations from what was requested
+- Provide rollback checkpoint (exact commit hash or branch name)
+
+## Approval Language
+
+Use direct, unambiguous approval language:
+
+- "Discussion is not approval."
+- "Absence of objection is not approval."
+- "I cannot infer authorization from prior similar work."
+- "When scope is ambiguous, I stop and propose a bounded plan."
+
+## High-Risk Surface Handling
+
+When you see any change touching these areas, **stop immediately**:
+
+- `src/services/evidence/` (chain-of-custody, validation, integrity checks)
+- `src/services/compliance/` (rule evaluation, scoring)
+- `src/audit/` (audit trail, immutable logs)
+- `src/api/customer/` (customer-facing compliance data)
+- Deployment, CI, secrets, auth, billing surfaces
+
+For all of these: create a proposal with rationale, dependent code analysis, and rollback plan. Then wait for explicit human approval before proceeding.
+
+## Tool Invocation Rules
+
+### When writing code
+- Use `Write` tool to create new files (not inline code blocks)
+- Use `Edit` tool to modify existing files (surgical edits, not rewrites)
+- Include line numbers and context when editing
+- Provide complete, runnable examples
+
+### When running validation
+- Use `Bash` tool to run commands from the canonical spec
+- Always run `npm run validate` before suggesting changes
+- Parse test output for failures, don't assume pass from silence
+- Report exit codes and stderr, not just stdout
+
+### When proposing changes
+- Use `TodoWrite` to track multi-step tasks
+- Break complex work into bounded execution steps
+- Create a plan before starting high-risk changes
+- Provide diffs or before/after comparisons
+
+## Decision Authority Boundaries
+
+### I decide
+- How to phrase explanations and guidance
+- Which validation commands to run
+- Whether to ask for human input or proceed with bounded tasks
+- How to format output and documentation
+
+### I escalate (ask for human approval)
+- Any edit to forbidden paths
+- Adding, removing, or upgrading dependencies
+- Schema changes or database migrations
+- Breaking API changes
+- Compliance messaging
+- Override of stop rules or token budgets
+
+### I never do
+- Edit forbidden paths without explicit approval
+- Delete files without approval
+- Change approval rules or governance policy
+- Ignore test failures or validation errors
+- Reinterpret approvals from prior conversations
+- Make "helpful" changes outside the requested scope
+
+## Commit Message Format
+
+Follow this pattern:
+
+```
+Imperative summary (<60 chars)
+
+Body: explain what changed and why.
+Include any validation results or caveats.
+
+Spec-Version: 1.0
+```
+
+Example:
+```
+Add evidence integrity test for tamper detection
+
+Test coverage for chain-of-custody validation.
+Verifies that out-of-order events are caught.
+All existing tests pass.
+
+Spec-Version: 1.0
+```
+
+## Context Drift Handling
+
+At the start of each task, restate:
+
+1. **Canonical spec version:** 1.0
+2. **Files to touch:** [list all files]
+3. **Forbidden paths check:** [list any forbidden path concerns]
+4. **Approval status:** [what approvals are needed before I start]
+
+If the repo looks inconsistent with spec 1.0, surface that instead of guessing.
+
+## Adapter Status
+
+- **Compliance:** Full
+- **Last tested:** 2026-04-05
+- **Known limitations:** None
diff --git a/.ai/skills/gemini/adapter.md b/.ai/skills/gemini/adapter.md
new file mode 100644
index 0000000..4e07212
--- /dev/null
+++ b/.ai/skills/gemini/adapter.md
@@ -0,0 +1,135 @@
+---
+adapter_for: Google Gemini
+derived_from_version: 1.0
+last_updated: 2026-04-05
+framework: gemini-2.0, gemini-1.5-pro
+---
+
+# TrustSignal Gemini Adapter
+
+This adapter translates the canonical project spec into Gemini-specific instructions.
+
+## Core Governance (Canonical Spec 1.0)
+
+**All rules from the canonical project spec apply. This is phrasing adaptation only.**
+
+### Task Start Protocol
+
+Every task must begin with:
+
+1. Canonical spec version reference: **1.0**
+2. Complete list of files to be modified
+3. Validation: is every file in **allowed paths**?
+4. If any file is in **forbidden paths**: stop, create a proposal, wait for human approval
+
+### Task Execution Rules
+
+- Before submitting: run full validation suite (`npm run validate`)
+- All tests must pass; no exceptions
+- If you hit 3 consecutive validation failures, stop and escalate
+- Evidence integrity or compliance logic → immediate human escalation
+- Never combine source and generated artifact edits in one pass
+
+### Task Completion Protocol
+
+Deliver:
+- Exact file list (what was created/modified)
+- Change summary (what and why)
+- Validation results (pass/fail, with details)
+- Rollback instructions (commit hash + branch name)
+
+## Restricted Paths (No Edits Without Approval)
+
+```
+src/services/evidence/    chain-of-custody, validation, integrity
+src/services/compliance/  rule evaluation, scoring logic
+src/audit/               audit trail, logs, immutable records
+src/api/customer/        customer-facing compliance data
+.env, config/, secrets/  credentials and sensitive config
+docker-compose.yml       deployment and infrastructure
+```
+
+These require explicit human approval, documented reasoning, and rollback plan before any edit.
+
+## Approval Directives
+
+- "Discussion is exploratory, not approval."
+- "Prior similar work does not authorize new work."
+- "Silence is not consent."
+- "Ambiguity triggers a proposal, not a guess."
+
+## Risk Surface Escalation
+
+Any request touching these triggers an escalation workflow:
+
+1. Stop editing
+2. Propose: what change, why needed, what could break, how to revert
+3. Wait for human approval (explicit confirmation required)
+4. Proceed only after approval
+
+Risk surfaces: deployment, CI/CD, migrations, auth, infra, billing, compliance.
+
+## Tool and Function Calling
+
+For Gemini:
+- Use function calling for structured operations
+- Fetch repo metadata before proposing changes
+- Return JSON for validation results
+- Provide code in markdown blocks, not inline prose
+
+## Commit Message Standard
+
+```
+[TYPE] Brief description (under 60 character)
+
+Full explanation of:
+- What changed
+- Why this change was needed
+- Test and validation results
+- Any risk notes
+
+Spec-Version: 1.0
+```
+
+TYPE: Add, Fix, Update, Refactor, Test, Docs
+
+## Authority Boundaries
+
+### Autonomous (within approved scope)
+- Write and update tests
+- Generate documentation
+- Optimize code (same logic, better perf)
+- Refactor approved paths
+- Suggest improvements with rationale
+
+### Escalate to Human
+- Any forbidden path edit
+- File deletion
+- Dependency changes
+- Schema migrations
+- API breaking changes
+- Policy or approval rule changes
+- Compliance messaging
+
+## Spec Consistency Checks
+
+At task start, verify:
+
+- Repo structure matches spec expectations
+- Build and test commands are current
+- Allowed/forbidden paths list is accurate
+- No architectural changes since last adapter refresh
+- Dependencies and frameworks are spec-aligned
+
+If inconsistencies found: surface them, propose spec review, do not guess.
+
+## Gemini-Specific Notes
+
+- Function calling is fully supported; use structured responses
+- Long-context capability: include full file context, not just fragments
+- Explicit reasoning: break down approval logic before deciding
+- Iterative verification: check intermediate results, not just final output
+
+---
+
+**Compliance:** Full | **Last tested:** 2026-04-05 | **Notes:** Fully functional
diff --git a/.ai/skills/openai/adapter.md b/.ai/skills/openai/adapter.md
new file mode 100644
index 0000000..3c0a827
--- /dev/null
+++ b/.ai/skills/openai/adapter.md
@@ -0,0 +1,125 @@
+---
+adapter_for: OpenAI / GPT
+derived_from_version: 1.0
+last_updated: 2026-04-05
+framework: gpt-4-turbo, gpt-4o
+---
+
+# TrustSignal OpenAI Adapter
+
+This adapter translates the canonical project spec into OpenAI-specific instructions.
+
+## Core Rules (from canonical spec 1.0)
+
+**All approval thresholds, allowed/forbidden paths, and governance rules from the canonical spec apply exactly.**
+
+### Start checklist for every task
+
+- State canonical spec version: **1.0**
+- List all files you will create or modify
+- Verify every touched file is in **allowed paths**
+- If any file is in **forbidden paths**, stop and request human approval before proceeding
+
+### During execution
+
+- Run `npm run validate` before submitting changes (all checks must pass)
+- Stop if any test fails; do not use `--force` or skip validation
+- Stop after 3 validation failures; ask for human guidance
+- If evidence-integrity, compliance logic, or audit trail is involved, escalate to human
+- Do not mix source code and generated artifact edits in the same task
+
+### After completion
+
+- Provide: list of files touched, summary of changes, validation status
+- Note any scope deviations from the request
+- Include exact rollback information (commit hash or branch)
+
+## Forbidden Paths (Absolute Prohibition)
+
+Do not edit these without explicit human approval:
+
+```
+src/services/evidence/      → chain-of-custody, validation
+src/services/compliance/    → rule evaluation, scoring
+src/audit/                  → audit trail, immutable logs
+src/api/customer/           → customer-facing data
+.env, secrets/              → credentials
+docker-compose.yml          → deployment
+```
+
+## Approval Language
+
+- "Discussion does not equal approval."
+- "I do not infer authorization from previous similar work."
+- "I do not proceed if scope is ambiguous; I propose a plan instead."
+
+## High-Risk Surfaces
+
+If you request edits to these, I will:
+
+1. Refuse to edit without explicit human approval
+2. Create a proposal explaining the change, dependencies, and rollback plan
+3. Wait for direct confirmation before proceeding
+
+Surfaces: deployment, CI/CD, secrets, auth, infra, data migrations, API contracts, compliance policies.
+
+## Tool Usage
+
+For this platform:
+- Use REST APIs or official SDK for version control operations
+- Fetch repo structure before proposing changes
+- Use tool_choice to force specific function calls when needed
+- Provide structured output (JSON, code blocks) for clarity
+
+## Commit Format
+
+```
+[ACTION] brief summary under 60 chars
+
+Detailed explanation of what changed and why.
+Include test results and validation status.
+
+Spec-Version: 1.0
+```
+
+Actions: Add, Fix, Update, Refactor, Test (not past tense).
+
+## Scope Boundaries
+
+### I can do (with spec approval)
+- Write tests and documentation
+- Optimize performance and tooling
+- Generate coverage reports
+- Suggest refactors for approved paths
+
+### I cannot do (escalate to human)
+- Delete files
+- Modify approval policies
+- Change allowed/forbidden paths
+- Edit compliance or audit surfaces
+- Upgrade major dependencies
+- Change API contracts
+- Make breaking changes
+
+## Drift Detection
+
+At task start, flag any of these:
+
+- Repo structure differs from spec
+- Dependencies have newer major versions
+- Build commands have changed
+- Test strategy has changed
+- Architecture has evolved
+
+If detected: stop and propose a spec review instead of guessing.
+
+## Model-Specific Notes
+
+- GPT-4 and GPT-4o both support function calling; use structured outputs
+- Be explicit about approval boundaries (GPT models can overlook implicit restrictions)
+- Request step-by-step reasoning for high-risk decisions
+- Provide examples of good and bad decisions from this spec
+
+---
+
+**Compliance:** Full | **Last tested:** 2026-04-05
diff --git a/.ai/skills/project-spec.md b/.ai/skills/project-spec.md
new file mode 100644
index 0000000..08d5792
--- /dev/null
+++ b/.ai/skills/project-spec.md
@@ -0,0 +1,243 @@
+---
+project_state_version: 1.0
+last_reviewed: 2026-04-05
+review_owner: Christopher Marziani
+purpose: "Canonical specification for TrustSignal AI development and governance"
+---
+
+# TrustSignal Project AI Control Layer
+
+**Source of truth for all AI-assisted development in the TrustSignal repository.**
+
+## Project Purpose
+
+TrustSignal is a compliance and risk intelligence platform focused on evidence integrity and trust validation. The platform provides compliance officers, legal teams, and enterprise customers with:
+
+- Evidence chain-of-custody tracking and validation
+- Compliance posture assessment and reporting
+- Risk scoring and remediation guidance
+- Audit-ready documentation and audit trails
+
+AI-assisted development in this repo must maintain:
+- Accuracy and audit compliance
+- Evidence integrity (no model hallucination in compliance-critical paths)
+- Clear separation between AI guidance and human-verified decisions
+- Compliance messaging that is legally defensible
+- No unauthorized changes to policy, approval rules, or high-risk surfaces
+
+## Architecture and Boundaries
+
+### Core services
+- Evidence integrity service (chain-of-custody, validation, tamper detection)
+- Compliance assessment engine (rule evaluation, scoring, reporting)
+- Customer API and dashboard
+- Admin console and audit trail
+
+### Critical boundaries
+- Evidence validation code (human-verified only, no model edits)
+- Compliance rules engine (human approval required for rule changes)
+- Audit trail and immutable logs
+- Customer-facing compliance reporting
+
+### Model integration points (AI-safe)
+- Documentation and guidance (compliance officer talk tracks, how-to guides)
+- Test generation and coverage analysis
+- Performance benchmarking and optimization
+- Development tooling and CI/CD automation
+- Internal product design and roadmap discussion
+
+## Allowed Paths
+
+AI-assisted development is allowed in:
+
+```
+docs/
+src/tests/
+src/performance/
+src/tools/
+.github/workflows/ (except deployment/security-critical steps)
+.ai/
+README.md
+CONTRIBUTING.md
+```
+
+## Forbidden Paths
+
+Explicit human approval required before edits to:
+
+```
+src/services/evidence/ (evidence chain, validation, integrity checks)
+src/services/compliance/ (rule evaluation, scoring logic)
+src/audit/ (audit trail, immutable logs, compliance records)
+src/api/customer/ (customer-facing compliance data)
+docs/compliance-officer/ (compliance messaging - human verified)
+.env, .env.example
+secrets/, config/ (any credential-like paths)
+docker-compose.yml, Dockerfile (deployment surface)
+```
+
+## Build, Test, and Validation Commands
+
+Core validation:
+```bash
+npm test                    # full test suite
+npm run lint              # code quality checks
+npm run typecheck         # TypeScript validation
+npm run security:audit    # npm security audit
+npm run validate          # runs all core validation scripts
+```
+
+PR validation:
+```bash
+npm run validate          # all of the above plus coverage
+```
+
+## Decision Rights and Approval Policy
+
+### Human approval required before execution agent proceeds
+- Any edit to forbidden paths listed above
+- Add, remove, or upgrade dependencies
+- Schema changes or database migrations
+- New API endpoints or breaking API changes
+- Compliance messaging or customer-facing copy
+- Audit trail modifications
+- CI/CD or deployment workflow changes
+- Override of any stop rules or token budgets
+
+### Primary AI approval required
+- Edits outside the declared task scope
+- Refactors larger than the requested scope
+- Changes to test intent or coverage strategy
+- Edits to source and generated artifacts in the same pass
+- Any high-blast-radius config changes
+
+### Execution agent allowed without additional approval
+- Targeted edits inside approved file set
+- Running validation commands
+- Documentation updates explicitly in scope
+- Generated artifacts (coverage reports, test output)
+
+## Destructive Action Policy
+
+- **No deletions without explicit human approval.** If removal is needed, create a deletion proposal with:
+  - Clear rationale for removal
+  - List of dependent code or references
+  - Rollback checkpoint (commit hash or branch)
+- **No schema changes or migrations without approval.** Evidence integrity depends on precise schema versioning.
+- **No dependency downgrades or removals** without security or compliance justification.
+- **No silent refactors.** If refactoring is needed, propose it separately with clear scope boundaries.
+
+## Dependency and Migration Policy
+
+### Dependency changes
+- New dependencies: human approval required
+- Patch upgrades: allowed if CI passes
+- Minor upgrades: allowed if CI passes and no API changes
+- Major upgrades: human approval required
+- Security patches: fast-track if CI passes
+
+### Schema migrations
+- All schema changes require human approval
+- Evidence-integrity-related migrations require compliance review
+- Migrations must include rollback procedure
+- Database changes must not interrupt audit trail
+
+## Documentation Update Policy
+
+- **Allowed without approval:** README, contributing guides, internal tooling docs, API reference docs
+- **Requires human approval:** Compliance officer talk tracks, customer-facing messaging, audit procedures, security policies
+- **Cannot be auto-generated:** Customer-facing compliance guidance (must be legally reviewed)
+
+## Context Drift Controls
+
+### Version discipline
+- Canonical spec version: **1.0**
+- All adapters must cite this version: `derived_from_version: 1.0`
+- Adapter refresh triggers:
+  - Canonical spec version incremented
+  - Core service architecture changed
+  - Allowed/forbidden paths changed
+  - Build or validation commands changed
+  - Approval rules or decision rights changed
+  - New dependencies or major version changes
+  - Compliance or audit requirements change
+
+### Current source-of-truth files
+- `.ai/skills/project-spec.md` (this file)
+- `src/services/` (architecture)
+- `docs/ARCHITECTURE.md` (service design)
+- `package.json` (dependencies and build commands)
+- `.env.example` (configuration surface)
+- `src/tests/` (test strategy and coverage)
+
+### Known stale if changed
+If any of these files change, adapters should be refreshed:
+- `package.json`
+- `tsconfig.json`
+- `.github/workflows/ci.yml`
+- `src/services/*/` (any core service changes)
+- `docs/ARCHITECTURE.md`
+
+### Drift checklist
+Before starting work, verify:
+
+1. Is this canonical spec version the current one?
+2. Have core services or architecture changed since last adapter refresh?
+3. Have allowed/forbidden paths changed?
+4. Have build or test commands changed?
+5. Have approval rules or decision rights changed?
+6. Are there pending dependency updates?
+7. Has the compliance landscape changed?
+
+If "yes" to any, request a spec review before proceeding.
+
+## Token and Scope Controls
+
+### Before starting work
+- Restate current task scope and canonical spec version
+- List all files that will be touched
+- Confirm that touched files are in allowed paths
+- Check whether any high-risk surfaces are involved
+
+### During execution
+- Stop after 3 failed validations; propose human review
+- Stop if tests fail; do not override with --force
+- Stop if evidence-integrity or compliance logic is affected; escalate
+- Surface uncertainty instead of guessing
+
+### After completion
+- Summarize files touched, changes made, tests passing
+- Note any deviations from requested scope
+- Provide rollback checkpoint (commit hash)
+
+## Output and Commit Conventions
+
+### Commit messages
+Include:
+- Imperative mood: "Add", "Fix", "Update" (not "Added", "Fixed")
+- Single-line summary (< 60 chars)
+- Body: what changed and why
+- Footer: `Spec-Version: 1.0` if this repo spec was checked
+
+Example:
+```
+Add evidence integrity test for tamper detection
+
+Test coverage for the chain-of-custody validation logic.
+Verifies that out-of-order events are caught and flagged.
+Spec version checked at start of work.
+
+Spec-Version: 1.0
+```
+
+### Files touched summary
+Before merging, summarize:
+- List of files modified
+- Summary of changes by category (tests, docs, code)
+- Any validation failures or warnings
+- Rollback procedure
+
+---
+
+**Last sync:** not yet synced to adapters  
+**Next review:** 2026-05-05
diff --git a/.github/workflows/ai-skill-sync.yml b/.github/workflows/ai-skill-sync.yml
new file mode 100644
index 0000000..a83fa56
--- /dev/null
+++ b/.github/workflows/ai-skill-sync.yml
@@ -0,0 +1,153 @@
+name: TrustSignal AI Skill Sync
+
+on:
+  workflow_dispatch:
+    inputs:
+      mode:
+        description: "validate (check for drift) or refresh (regenerate adapters)"
+        required: false
+        default: "validate"
+        type: choice
+        options:
+          - validate
+          - refresh
+      target_models:
+        description: "comma-separated models to sync (openai,claude,gemini); defaults to all models"
+        required: false
+        default: "openai,claude,gemini"
+
+jobs:
+  sync:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
+        with:
+          fetch-depth: 0
+
+      - name: Set up Node.js
+        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4
+        with:
+          node-version: "20"
+
+      - name: Validate canonical spec exists
+        run: |
+          if [ ! -f ".ai/skills/project-spec.md" ]; then
+            echo "❌ CRITICAL: Canonical spec not found at .ai/skills/project-spec.md"
+            exit 1
+          fi
+          echo "✓ Canonical spec found"
+
+      - name: Extract spec metadata
+        id: spec
+        run: |
+          SPEC_VERSION=$(grep "project_state_version:" .ai/skills/project-spec.md | head -1 | cut -d: -f2 | xargs)
+          LAST_REVIEWED=$(grep "last_reviewed:" .ai/skills/project-spec.md | head -1 | cut -d: -f2 | xargs)
+          echo "version=$SPEC_VERSION" >> $GITHUB_OUTPUT
+          echo "reviewed=$LAST_REVIEWED" >> $GITHUB_OUTPUT
+          echo "Spec Version: $SPEC_VERSION"
+          echo "Last Reviewed: $LAST_REVIEWED"
+
+      - name: Validate adapter metadata (Claude)
+        if: inputs.target_models == '' || contains(inputs.target_models, 'claude')
+        run: |
+          if [ ! -f ".ai/skills/claude/adapter.md" ]; then
+            echo "⚠️  Claude adapter missing"
+          else
+            ADAPTER_VERSION=$(grep "derived_from_version:" .ai/skills/claude/adapter.md | head -1 | cut -d: -f2 | xargs)
+            if [ "$ADAPTER_VERSION" != "${{ steps.spec.outputs.version }}" ]; then
+              echo "⚠️  Claude adapter version mismatch: adapter=$ADAPTER_VERSION, spec=${{ steps.spec.outputs.version }}"
+            else
+              echo "✓ Claude adapter version matches spec"
+            fi
+          fi
+
+      - name: Validate adapter metadata (OpenAI)
+        if: inputs.target_models == '' || contains(inputs.target_models, 'openai')
+        run: |
+          if [ ! -f ".ai/skills/openai/adapter.md" ]; then
+            echo "⚠️  OpenAI adapter missing"
+          else
+            ADAPTER_VERSION=$(grep "derived_from_version:" .ai/skills/openai/adapter.md | head -1 | cut -d: -f2 | xargs)
+            if [ "$ADAPTER_VERSION" != "${{ steps.spec.outputs.version }}" ]; then
+              echo "⚠️  OpenAI adapter version mismatch: adapter=$ADAPTER_VERSION, spec=${{ steps.spec.outputs.version }}"
+            else
+              echo "✓ OpenAI adapter version matches spec"
+            fi
+          fi
+
+      - name: Validate adapter metadata (Gemini)
+        if: inputs.target_models == '' || contains(inputs.target_models, 'gemini')
+        run: |
+          if [ ! -f ".ai/skills/gemini/adapter.md" ]; then
+            echo "⚠️  Gemini adapter missing"
+          else
+            ADAPTER_VERSION=$(grep "derived_from_version:" .ai/skills/gemini/adapter.md | head -1 | cut -d: -f2 | xargs)
+            if [ "$ADAPTER_VERSION" != "${{ steps.spec.outputs.version }}" ]; then
+              echo "⚠️  Gemini adapter version mismatch: adapter=$ADAPTER_VERSION, spec=${{ steps.spec.outputs.version }}"
+            else
+              echo "✓ Gemini adapter version matches spec"
+            fi
+          fi
+
+      - name: Validate agent policies exist
+        run: |
+          if [ ! -f ".agents/primary-agent.md" ]; then
+            echo "❌ Primary agent policy missing"
+            exit 1
+          fi
+          if [ ! -f ".agents/executor-agent.md" ]; then
+            echo "❌ Executor agent policy missing"
+            exit 1
+          fi
+          echo "✓ Agent policies present"
+
+      - name: Report mode - check for spec drift
+        if: inputs.mode == 'validate'
+        run: |
+          echo "=== AI Skill Sync Validation Report ==="
+          echo ""
+          echo "Canonical Spec:"
+          echo "  Version: ${{ steps.spec.outputs.version }}"
+          echo "  Last Reviewed: ${{ steps.spec.outputs.reviewed }}"
+          echo ""
+          echo "Adapter Sync Status:"
+          echo "  [See validation steps above]"
+          echo ""
+          echo "Next steps:"
+          echo "  1. Review adapter version mismatches (if any)"
+          echo "  2. If spec was updated, run workflow with mode=refresh"
+          echo "  3. If adapters are stale, request review"
+
+      - name: Refresh mode - regenerate adapters
+        if: inputs.mode == 'refresh'
+        run: |
+          echo "⚠️  Refresh mode: Would regenerate adapters from canonical spec"
+          echo ""
+          echo "This is a placeholder. In a production setup, this would:"
+          echo "  1. Parse the canonical spec"
+          echo "  2. Generate model-specific adapters"
+          echo "  3. Update derived_from_version in each adapter"
+          echo "  4. Commit and open a PR for review"
+          echo ""
+          echo "For now: manual adapter updates are required."
+          echo "Recommended: review each adapter against the canonical spec."
+
+      - name: Generate summary
+        if: always()
+        run: |
+          echo "## AI Skill Sync Report" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "**Mode:** ${{ inputs.mode }}" >> $GITHUB_STEP_SUMMARY
+          echo "**Target Models:** ${{ inputs.target_models }}" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "**Canonical Spec Version:** ${{ steps.spec.outputs.version }}" >> $GITHUB_STEP_SUMMARY
+          echo "**Last Reviewed:** ${{ steps.spec.outputs.reviewed }}" >> $GITHUB_STEP_SUMMARY
+          echo "" >> $GITHUB_STEP_SUMMARY
+          echo "**Checks Performed:**" >> $GITHUB_STEP_SUMMARY
+          echo "- ✓ Canonical spec exists" >> $GITHUB_STEP_SUMMARY
+          echo "- ✓ Adapter metadata validated" >> $GITHUB_STEP_SUMMARY
+          echo "- ✓ Agent policies verified" >> $GITHUB_STEP_SUMMARY
diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml
new file mode 100644
index 0000000..cb94958
--- /dev/null
+++ b/.github/workflows/codeql.yml
@@ -0,0 +1,43 @@
+name: "CodeQL Analysis"
+
+on:
+  push:
+    branches: [ "master" ]
+  pull_request:
+    branches: [ "master" ]
+  schedule:
+    - cron: '27 10 * * 5'
+
+jobs:
+  analyze:
+    name: Analyze
+    runs-on: ubuntu-latest
+    permissions:
+      actions: read
+      contents: read
+      security-events: write
+
+    strategy:
+      fail-fast: false
+      matrix:
+        language: [ 'javascript-typescript', 'python' ]
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v6
+
+    # Initializes the CodeQL tools for scanning.
+    - name: Initialize CodeQL
+      uses: github/codeql-action/init@v4
+      with:
+        languages: ${{ matrix.language }}
+
+    # Autobuild attempts to build any compiled languages  (C/C++, C#, Go, or Java).
+    # If this step fails, then you should remove it and run the build manually (see below)
+    - name: Autobuild
+      uses: github/codeql-action/autobuild@v4
+
+    - name: Perform CodeQL Analysis
+      uses: github/codeql-action/analyze@v4
+      with:
+        category: "/language:${{matrix.language}}"
diff --git a/bench/results/latest.md b/bench/results/latest.md
index 6e217a1..5db2cab 100644
--- a/bench/results/latest.md
+++ b/bench/results/latest.md
@@ -6,8 +6,8 @@
 ## Environment Description
 - Node: v22.14.0
 - Platform: darwin (arm64)
-- Host: Christophers-Mac-mini.local
-- Temp database: postgresql on 127.0.0.1:64030
+- Host: localhost
+- Temp database: postgresql on localhost
 - Harness command: `npx tsx bench/run-bench.ts --scenario all --runs 15 --batch-size 10`
 
 ## Iteration / Sample Notes
diff --git a/bench/run-bench.ts b/bench/run-bench.ts
index bfc75ae..767d7f9 100644
--- a/bench/run-bench.ts
+++ b/bench/run-bench.ts
@@ -3,7 +3,7 @@ import { Buffer } from 'node:buffer';
 import { promises as fs } from 'node:fs';
 import os from 'node:os';
 import path from 'node:path';
-import { spawn, execFile as execFileCallback, type ChildProcess } from 'node:child_process';
+import { execFile as execFileCallback, type ChildProcess } from 'node:child_process';
 import { promisify } from 'node:util';
 import { performance } from 'node:perf_hooks';
 
diff --git a/package-lock.json b/package-lock.json
index 3016069..4eea128 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -8677,30 +8677,15 @@
       }
     },
     "node_modules/pdf2json": {
-      "version": "3.1.4",
-      "resolved": "https://registry.npmjs.org/pdf2json/-/pdf2json-3.1.4.tgz",
-      "integrity": "sha512-rS+VapXpXZr+5lUpHmRh3ugXdFXp24p1RyG24yP1DMpqP4t0mrYNGpLtpSbWD42PnQ59GIXofxF+yWb7M+3THg==",
-      "bundleDependencies": [
-        "@xmldom/xmldom"
-      ],
+      "version": "3.2.2",
+      "resolved": "https://registry.npmjs.org/pdf2json/-/pdf2json-3.2.2.tgz",
+      "integrity": "sha512-DgtH8GId1/+oj8n9yYEmhTq1QkxOZZzqHJhHEa1bmtV3t3/u2YsE3LSvRUNpVRWVXRcCdn+3Tu6+mD2YXKL7lA==",
       "license": "Apache-2.0",
-      "dependencies": {
-        "@xmldom/xmldom": "^0.8.10"
-      },
       "bin": {
         "pdf2json": "bin/pdf2json.js"
       },
       "engines": {
-        "node": ">=18.12.1",
-        "npm": ">=8.19.2"
-      }
-    },
-    "node_modules/pdf2json/node_modules/@xmldom/xmldom": {
-      "version": "0.8.10",
-      "inBundle": true,
-      "license": "MIT",
-      "engines": {
-        "node": ">=10.0.0"
+        "node": ">=20.18.0"
       }
     },
     "node_modules/pdfkit": {
diff --git a/wiki/API-Overview.md b/wiki/API-Overview.md
index 18fb696..74f5b5e 100644
--- a/wiki/API-Overview.md
+++ b/wiki/API-Overview.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # API Overview
 
@@ -17,7 +17,7 @@ Partners need a stable public contract that explains how TrustSignal fits into a
 
 ## Verification Lifecycle
 
-The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](/Users/christopher/Projects/trustsignal/docs/verification-lifecycle.md).
+The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](../docs/verification-lifecycle.md).
 
 TrustSignal exposes a public verification lifecycle centered on signed verification receipts, verification signals, verifiable provenance metadata, and later verification.
 
@@ -25,16 +25,16 @@ TrustSignal exposes a public verification lifecycle centered on signed verificat
 
 Start with the local developer trial for the fastest lifecycle walkthrough:
 
-- [5-minute developer trial](/Users/christopher/Projects/trustsignal/demo/README.md)
+- [5-minute developer trial](../demo/README.md)
 
 ## Integration Model
 
 Start here to try the public lifecycle:
 
-- [OpenAPI contract](/Users/christopher/Projects/trustsignal/openapi.yaml)
-- [Evaluator quickstart](/Users/christopher/Projects/trustsignal/docs/partner-eval/quickstart.md)
-- [API playground](/Users/christopher/Projects/trustsignal/docs/partner-eval/api-playground.md)
-- [Postman collection](/Users/christopher/Projects/trustsignal/postman/TrustSignal.postman_collection.json)
+- [OpenAPI contract](../openapi.yaml)
+- [Evaluator quickstart](../docs/partner-eval/quickstart.md)
+- [API playground](../docs/partner-eval/api-playground.md)
+- [Postman collection](../postman/TrustSignal.postman_collection.json)
 
 Golden path:
 
@@ -103,4 +103,4 @@ Integrators should expect these broad patterns:
 - `429` for rate limiting
 - `503` when a required dependency is unavailable
 
-The canonical public contract for the verification lifecycle is [openapi.yaml](/Users/christopher/Projects/trustsignal/openapi.yaml).
+The canonical public contract for the verification lifecycle is [openapi.yaml](../openapi.yaml).
diff --git a/wiki/Claims-Boundary.md b/wiki/Claims-Boundary.md
index 9f33d66..b1f4469 100644
--- a/wiki/Claims-Boundary.md
+++ b/wiki/Claims-Boundary.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Claims Boundary
 
diff --git a/wiki/Evidence-Integrity-Architecture.md b/wiki/Evidence-Integrity-Architecture.md
index 82e276c..79beb58 100644
--- a/wiki/Evidence-Integrity-Architecture.md
+++ b/wiki/Evidence-Integrity-Architecture.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Evidence Integrity Architecture
 
diff --git a/wiki/FAQ.md b/wiki/FAQ.md
index a072893..65f7b55 100644
--- a/wiki/FAQ.md
+++ b/wiki/FAQ.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # FAQ
 
diff --git a/wiki/Home.md b/wiki/Home.md
index 0ff9b5b..d5711bc 100644
--- a/wiki/Home.md
+++ b/wiki/Home.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # TrustSignal Wiki
 
@@ -21,29 +21,29 @@ High-loss environments create incentives for these attack paths because downstre
 
 ## Verification Lifecycle
 
-The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](/Users/christopher/Projects/trustsignal/docs/verification-lifecycle.md).
+The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](../docs/verification-lifecycle.md).
 
 TrustSignal provides signed verification receipts, verification signals, verifiable provenance metadata, and later verification capability as an integrity layer for an existing system of record.
 
 ## Start Here
 
-- [What is TrustSignal](What-is-TrustSignal)
-- [API Overview](API-Overview)
-- [Verification Receipts](Verification-Receipts)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [API Overview](API-Overview.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
 
 ## Demo
 
-- [5-minute developer trial](/Users/christopher/Projects/trustsignal/demo/README.md)
+- [5-minute developer trial](../demo/README.md)
 
 ## Integration Model
 
 Use the evaluator docs when you want to see the verification lifecycle before production integration detail:
 
-- [Evaluator quickstart](/Users/christopher/Projects/trustsignal/docs/partner-eval/quickstart.md)
-- [API playground](/Users/christopher/Projects/trustsignal/docs/partner-eval/api-playground.md)
-- [OpenAPI contract](/Users/christopher/Projects/trustsignal/openapi.yaml)
+- [Evaluator quickstart](../docs/partner-eval/quickstart.md)
+- [API playground](../docs/partner-eval/api-playground.md)
+- [OpenAPI contract](../openapi.yaml)
 
 ## Technical Details
 
diff --git a/wiki/Quick-Verification-Example.md b/wiki/Quick-Verification-Example.md
index 1283e73..4869d1c 100644
--- a/wiki/Quick-Verification-Example.md
+++ b/wiki/Quick-Verification-Example.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Quick Verification Example
 
@@ -17,7 +17,7 @@ This example is for partner engineers who want the smallest realistic TrustSigna
 
 ## Verification Lifecycle
 
-The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](/Users/christopher/Projects/trustsignal/docs/verification-lifecycle.md).
+The canonical lifecycle diagram is documented in [docs/verification-lifecycle.md](../docs/verification-lifecycle.md).
 
 This example uses the current integration-facing lifecycle to create a verification, return verification signals plus a signed verification receipt, store the receipt with the workflow record, and later verify stored receipt state during audit review.
 
@@ -25,10 +25,10 @@ This example uses the current integration-facing lifecycle to create a verificat
 
 Start here for the full evaluator path:
 
-- [Evaluator quickstart](/Users/christopher/Projects/trustsignal/docs/partner-eval/quickstart.md)
-- [API playground](/Users/christopher/Projects/trustsignal/docs/partner-eval/api-playground.md)
-- [OpenAPI contract](/Users/christopher/Projects/trustsignal/openapi.yaml)
-- [Postman collection](/Users/christopher/Projects/trustsignal/postman/TrustSignal.postman_collection.json)
+- [Evaluator quickstart](../docs/partner-eval/quickstart.md)
+- [API playground](../docs/partner-eval/api-playground.md)
+- [OpenAPI contract](../openapi.yaml)
+- [Postman collection](../postman/TrustSignal.postman_collection.json)
 
 ## Integration Model
 
diff --git a/wiki/SDK-Usage.md b/wiki/SDK-Usage.md
index 29ea1f2..6b658f2 100644
--- a/wiki/SDK-Usage.md
+++ b/wiki/SDK-Usage.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # SDK Usage
 
diff --git a/wiki/Security-Model.md b/wiki/Security-Model.md
index 47b8037..6d74c9f 100644
--- a/wiki/Security-Model.md
+++ b/wiki/Security-Model.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Security Model
 
@@ -77,4 +77,4 @@ Those details are intentionally separated from the public integration model.
 ## Related Documentation
 
 - [Threat Model](Threat-Model)
-- [Evidence Integrity Architecture](Evidence-Integrity-Architecture)
+- [Evidence Integrity Architecture](Evidence-Integrity-Architecture.md)
diff --git a/wiki/Threat-Model.md b/wiki/Threat-Model.md
index 008ba92..816452d 100644
--- a/wiki/Threat-Model.md
+++ b/wiki/Threat-Model.md
@@ -1,17 +1,17 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Threat Model
 
-Related pages: [Security Model](Security-Model) · [Evidence Integrity Architecture](Evidence-Integrity-Architecture)
+Related pages: [Security Model](Security-Model.md) · [Evidence Integrity Architecture](Evidence-Integrity-Architecture.md)
 
 This page summarizes the external threat model for TrustSignal at the public integration boundary. It is intended for developers, security reviewers, and integration partners evaluating how TrustSignal handles verification requests, receipt lifecycle operations, and downstream evidence use.
 
diff --git a/wiki/Vanta-Integration-Example.md b/wiki/Vanta-Integration-Example.md
index 9734b73..aaa2189 100644
--- a/wiki/Vanta-Integration-Example.md
+++ b/wiki/Vanta-Integration-Example.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Vanta Integration Example
 
diff --git a/wiki/Verification-Receipts.md b/wiki/Verification-Receipts.md
index 7f6c270..7fc936f 100644
--- a/wiki/Verification-Receipts.md
+++ b/wiki/Verification-Receipts.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # Verification Receipts
 
diff --git a/wiki/What-is-TrustSignal.md b/wiki/What-is-TrustSignal.md
index 583fa0e..a7d2a8d 100644
--- a/wiki/What-is-TrustSignal.md
+++ b/wiki/What-is-TrustSignal.md
@@ -1,13 +1,13 @@
 **Navigation**
 
-- [Home](Home)
-- [What is TrustSignal](What-is-TrustSignal)
-- [Architecture](Evidence-Integrity-Architecture)
-- [Verification Receipts](Verification-Receipts)
-- [API Overview](API-Overview)
-- [Claims Boundary](Claims-Boundary)
-- [Quick Verification Example](Quick-Verification-Example)
-- [Vanta Integration Example](Vanta-Integration-Example)
+- [Home](Home.md)
+- [What is TrustSignal](What-is-TrustSignal.md)
+- [Architecture](Evidence-Integrity-Architecture.md)
+- [Verification Receipts](Verification-Receipts.md)
+- [API Overview](API-Overview.md)
+- [Claims Boundary](Claims-Boundary.md)
+- [Quick Verification Example](Quick-Verification-Example.md)
+- [Vanta Integration Example](Vanta-Integration-Example.md)
 
 # What Is TrustSignal
 
@@ -25,7 +25,7 @@ TrustSignal is evidence integrity infrastructure. It provides signed verificatio
 
 The fastest local evaluator path is the 5-minute developer trial:
 
-- [5-minute developer trial](/Users/christopher/Projects/trustsignal/demo/README.md)
+- [5-minute developer trial](../demo/README.md)
 
 ## Integration