tractatus/docs/i18n/ARCHITECTURE_PAGE_I18N_KEYS.md

Architecture.html I18N Translation Keys

Date: 2025-10-31 Purpose: Document new i18n keys added during architecture.html restructure Status: Needs German (DE) and French (FR) translations

---

Hero Section Updates

Changed Keys

{
  "hero": {
    "badge": "🏛️ BUILT ON LIVING SYSTEMS PRINCIPLES",
    "title": "Five Architectural Principles for AI Safety",
    "subtitle": "Tractatus governance is <strong>woven into deployment architecture</strong>, not bolted on. Five principles guide how the framework evolves, maintains coherence, and resists bypass—making it structurally more difficult (though not impossible) to circumvent through prompting.",
    "challenge_label": "The Problem:",
    "challenge_text": "Behavioral training can be manipulated through cleverly crafted prompts. AI governance based solely on internal reasoning is vulnerable to jailbreaks.",
    "approach_label": "Our Approach:",
    "approach_text": "Architectural enforcement operating in the critical execution path—governance services validate every action before it executes, independent of the AI's internal reasoning.",
    "cta_principles": "See the Five Principles"
  }
}

---

NEW: Five Principles Section

Section Header

{
  "principles": {
    "heading": "Five Architectural Principles",
    "subtitle": "These principles, adapted from Christopher Alexander's work on living systems, guide how Tractatus evolves and maintains coherence. They're not documentation—they're <strong>design criteria</strong> enforced architecturally."
  }
}

Principle 1: Not-Separateness

{
  "principles": {
    "not_separateness": {
      "title": "Not-Separateness: Governance in the Critical Path",
      "principle": "Governance woven into deployment architecture, not bolted on",
      "description": "Tractatus governance services operate <strong>in the critical execution path</strong>—every action passes through validation before executing. This isn't monitoring after-the-fact, it's architectural enforcement that cannot be bypassed.",
      "example_label": "Example: PreToolUse Hook",
      "example": "When the AI attempts to edit a file, the PreToolUse hook intercepts <em>before execution</em>. BoundaryEnforcer, CrossReferenceValidator, and other services validate the action. If any service blocks, the edit never happens—architecturally impossible to bypass.",
      "contrast": "<strong>Contrast:</strong> Bolt-on compliance systems monitor actions after they occur, creating separation between governance and execution. An AI agent could theoretically disable monitoring or exploit gaps. Tractatus eliminates that separation."
    }
  }
}

Principle 2: Deep Interlock

{
  "principles": {
    "deep_interlock": {
      "title": "Deep Interlock: Services Reinforce Each Other",
      "principle": "Coordinated governance, not isolated checks",
      "description": "The six governance services don't operate in silos—they coordinate through mutual validation. High context pressure intensifies boundary checking. Instruction persistence affects cross-reference validation. Service outputs feed into each other, creating resilience through redundancy.",
      "example_label": "Example: The 27027 Incident",
      "example": "AI attempted to use default database port despite HIGH persistence instruction specifying port 27027. InstructionPersistenceClassifier flagged the instruction. ContextPressureMonitor detected 53.5% pressure. CrossReferenceValidator caught the conflict. BoundaryEnforcer blocked the action. Four services working together prevented the error.",
      "benefit": "<strong>Why it matters:</strong> Single service bypass doesn't compromise governance. An attacker would need to circumvent multiple coordinated services simultaneously—exponentially harder than defeating isolated checks."
    }
  }
}

Principle 3: Gradients Not Binary

{
  "principles": {
    "gradients": {
      "title": "Gradients Not Binary: Nuanced Responses",
      "principle": "Intensity levels, not yes/no switches",
      "description": "Governance operates on gradients: NORMAL → ELEVATED → HIGH → CRITICAL. Context pressure, security impact, and validation rigor all scale with intensity. This mirrors how living systems adapt—gradual responses, not mechanical on/off.",
      "example_label": "Example: Context Pressure Monitoring",
      "example": "At NORMAL pressure (0-25%), routine operations proceed smoothly. At ELEVATED (25-50%), validation becomes more thorough. At HIGH (50-75%), human review triggers more frequently. At CRITICAL (>75%), framework recommends session closedown. Graduated response prevents both alert fatigue and catastrophic failures.",
      "contrast": "<strong>Contrast:</strong> Binary \"allowed/blocked\" systems create brittleness—either everything passes or nothing does. Gradients enable natural adaptation to varying risk levels."
    }
  }
}

Principle 4: Structure-Preserving

{
  "principles": {
    "structure_preserving": {
      "title": "Structure-Preserving: Audit Continuity",
      "principle": "Changes enhance without breaking",
      "description": "Framework changes must preserve wholeness—audit logs remain interpretable, decisions remain valid, institutional memory survives evolution. Version 4.2 logs are readable in version 4.4. Six-month-old audit decisions still make sense. Structure-preserving transformations maintain coherence across time.",
      "example_label": "Example: Adding Framework Fade Detection",
      "example": "When inst_064 (framework fade detection) was added, it monitored all six services without changing their core definitions. Pre-existing audit logs remained valid. Service behavior evolved, but historical decisions stayed interpretable. Enhancement without fracture.",
      "regulatory": "<strong>Regulatory advantage:</strong> Regulators need stable audit trails. Structure-preserving evolution lets the framework adapt while maintaining compliance continuity—no need to re-interpret old decisions every version."
    }
  }
}

Principle 5: Living Process

{
  "principles": {
    "living_process": {
      "title": "Living Process: Evidence-Based Evolution",
      "principle": "Grows from real failures, not theory",
      "description": "Framework changes emerge from observed reality, not predetermined plans. When services went unused, we added fade detection. When selective verification reduced noise, we evolved triggering criteria. Real operational experience drives evolution—no building solutions to theoretical problems.",
      "example_label": "Example: MetacognitiveVerifier Selective Mode",
      "example": "Audit logs showed MetacognitiveVerifier activating on trivial operations, creating noise. Rather than theorize about thresholds, we analyzed real trigger patterns. Selective mode emerged from data—verify only complex operations (3+ file modifications, 5+ sequential steps). Performance improved based on evidence, not guesswork.",
      "contrast": "<strong>Contrast:</strong> Over-engineered systems solve imagined problems. Living process builds only what reality proves necessary—lean, effective, grounded in operational truth."
    }
  }
}

How They Work Together

{
  "principles": {
    "together": {
      "title": "How the Five Principles Work Together",
      "description": "These principles aren't independent—they form an interlocking pattern. <strong>Not-separateness</strong> requires <strong>deep interlock</strong> between services. <strong>Gradients</strong> enable natural adaptation. <strong>Living process</strong> drives changes that must be <strong>structure-preserving</strong> to maintain wholeness.",
      "flow_1": "Not-Separateness (governance in critical path)",
      "flow_2": "Deep Interlock (services coordinate)",
      "flow_3": "Gradients (nuanced responses)",
      "flow_4": "Living Process (evidence-based evolution)",
      "flow_5": "Structure-Preserving (audit continuity)",
      "result": "System Wholeness"
    }
  }
}

---

Six Services Section Update

{
  "services": {
    "heading": "Six Governance Services",
    "subtitle": "These services implement the five principles in practice. Each service embodies <strong>not-separateness</strong> (operating in the critical path), <strong>deep interlock</strong> (coordinating with others), and <strong>gradients</strong> (intensity-based responses)."
  }
}

---

Translation Notes

Technical Terms to Preserve

These terms should remain in English across all translations for consistency:

• Tractatus (framework name)
• PreToolUse Hook (technical component)
• BoundaryEnforcer, CrossReferenceValidator, InstructionPersistenceClassifier, ContextPressureMonitor, MetacognitiveVerifier (service names)
• inst_064, inst_027 (instruction IDs)
• NORMAL, ELEVATED, HIGH, CRITICAL (pressure levels)
• 27027 Incident (historical reference)

Style Guidelines (from inst_085-089)

1. Grounded Language (inst_085): Use operational examples, avoid abstract theory
2. Evidence-Based (inst_086): Reference audit logs, real incidents
3. Anti-Consultant (inst_087): Avoid "comprehensive," "holistic," "best practices"
4. Candid About Limitations (inst_088): Position as "adapted from" Alexander, "more difficult (though not impossible)"
5. Architectural Focus (inst_089): Emphasize structure over training

Translation Priority

HIGH: Hero section (user-facing, first impression) HIGH: Principle titles and principles (core messaging) MEDIUM: Descriptions and examples (technical but important) MEDIUM: Contrasts and benefits (supporting arguments) LOW: Flow diagram text (visual aid, less critical)

---

Files to Update

1. public/locales/de/architecture.json - Add German translations
2. public/locales/fr/architecture.json - Add French translations
3. public/locales/en/architecture.json - Add these English keys as baseline

---

Validation Checklist

• All keys have English baseline in en/architecture.json
• German translations added to de/architecture.json
• French translations added to fr/architecture.json
• Technical terms remain in English
• HTML tags preserved in translated strings (<strong>, <em>)
• Cultural DNA guidelines followed (grounded, evidence-based, anti-consultant)
• Page tested in all 3 languages
• No broken placeholders (missing translations show keys)

---

Total New Keys: ~50 keys across hero + principles + services sections Estimated Translation Time: 2-3 hours per language (technical content) Next Steps: Add baseline English keys, then translate to DE/FR