Skip to content

Philosophy: The Analog Twin (Policy-First Architecture)

"The Data leads, the Code follows."

1. The Core Concept

Traditional software hardcodes business rules into if/else statements. This creates a rigid system where changing a "Business Rule" (e.g., Lease Duration) requires a "Code Deployment".

The Policy Engine Philosophy inverts this:

  1. The "Analog Twin": We capture the Organization's Rules in a human-readable, machine-parseable format (JSON/YAML).
  2. The AI/Code Enforcer: The software is merely an engine that reads these rules and applies them.

2. AI as an Active Logic Component

We do not just use AI to write the code. We use AI to be the logic layer.

  • Traditional: Programmer writes REGEX to parse a Deed.
  • Policy-Driven: Policy says "Must be a Deed". AI reads the document and answers "Is this a Deed?".

This allows the system to handle Human Ambiguity ("Is this really a valid utility bill?") without fragile code logic.

3. The Three Layers of Sovereignty

A. The Constitution (The Analog Twin)

  • Format: JSON / Markdown.
  • Content: "Owners exist in perpetuity."
  • Role: The immutable source of truth.
  • Example: generated/policies.json

B. The Engine (The Digital Enforcer)

  • Format: TypeScript / Rust.
  • Content: policyEngine.enforce(rule).
  • Role: The dumb muscle that executes the Constitution.

C. The Intelligence (The AI Arbiter)

  • Format: LLM / Cognitive Services.
  • Content: "Analyze this document against Policy X."
  • Role: The judge that interprets complex, unstructured reality against the rigid rules.

4. Development Protocol

When implementing a new Feature:

  1. Don't write logic first.
  2. Define the Policy first. (Add to policies.json).
  3. Build the Adapter. (Teach the code to read the policy).
  4. Auto-Generate the Docs. (Prove the policy exists).

5. The Decision Framework: When to Use Policy vs. Code

This architecture is powerful, but it is not a silver bullet. Using a Policy Engine (especially with AI) introduces latency and indeterminism. Use this rubric to decide.

✅ Where It Shines (Applicability)

  • Variable Business Logic: Rules that change faster than the compiled code release cycle (e.g., "Voting Quorum %", "Guest Pass Limits").
  • Human Ambiguity: Problems where "Code" fails to capture nuance.
  • Example: "Is this photo appropriate for the directory?" -> Code fails. AI Policy excels.
  • Example: "Is this a valid Lease Agreement?" -> Code struggles with formats. AI Policy excels.
  • Regulatory & Compliance Visibility: When rules must be audited by non-coders (Lawyers, Board Members). Code is opaque; JSON Rulebooks are transparent.
  • Complex State Transitions: When If/Else chains become unreadable spaghetti code.

⛔ The Danger Zone (Risks & Anti-Patterns)

  • Deterministic Integrity (The Ledger): NEVER use AI/Policy for core math.
  • Bad: asking AI "Is the balance correct?".
  • Good: Code calculates balance; Policy decides if that balance allows a specific action.
  • High-Frequency / Real-Time: The Policy Engine adds overhead. Do not use it for render loops, networking packets, or high-frequency trading.
  • Security Primitives (AuthN): NEVER let AI decide "Is this password correct?" or "Is this JWT valid?". Authentication must be rigid, binary code.
  • Simple Logic (Over-Engineering): If a rule is if (status === 'active'), writing a JSON Policy is waste. Keep it in code.

⚖️ The Evaluation Rubric

Criteria Lean towards CODE (Hard Logic) Lean towards POLICY (Analog Twin)
Change Frequency Static / Rare (Years) Dynamic / Frequent (Weeks/Months)
Ambiguity Binary (True/False) Nuanced (Probabilistic / Contextual)
Audience Developers only Stakeholders (Legal, Product, Users)
Latency Tolerance Microseconds Seconds / Minutes (Async)
Consequence of Error System Crash / Data Corruption Incorrect Decision (Reviewable)

Golden Rule: Use Code for Mechanics (How to move data). Use Policy for Governance (Why/When to move data).

6. Taxonomy of Enforcement (The Spectrum of Control)

To capture the "Truth" accurately, we must classify who governs each rule. We define three distinct levels of enforcement:

Level 1: HARD_CODE (The Physics)

  • Governor: The Compiler / Runtime Environment.
  • Nature: Immutable without deployment. deterministic.
  • Example: "A User ID must be a UUID."
  • Use Case: Data integrity, type safety, security boundaries.

Level 2: RUNTIME_POLICY (The Law)

  • Governor: The Policy Engine (reading policies.json).
  • Nature: Configurable, enforced algorithmically at runtime.
  • Example: "Owners must recertify every 2 years."
  • Use Case: Business logic, time-based rules, variable thresholds.

Level 3: AI_ARBITER (The Judgement)

  • Governor: The AI Model (LLM / Vision).
  • Nature: Probabilistic, contextual, subject to "Review".
  • Example: "Is this document a valid Deed of Trust?"
  • Use Case: Unstructured data parsing, subjective moderation, intent analysis.

Documentation Standard: All Rules in the "Analog Twin" (Rulebook) MUST specify their enforcement_source. This clarifies whether changing the rule requires a Developer (Code), an Admin (Policy), or Training (AI).

Version History

Version Date Author Change
0.1.0 2026-01-26 Antigravity Initial Audit & Metadata Injection