Skip to main content
Version: v1.1.0
This page explains TealTiger’s core design philosophy.

​
Decision Philosophy

TealTiger makes a fundamental choice: deterministic enforcement over probabilistic decisions. This page explains why and what it means for you.

​
The Core Principle

Governance decisions must be reproducible.
If the same inputs produce different outcomes, you don’t have governance — you have uncertainty.
TealTiger guarantees that the same input + same policy version = same decision. Every time. This isn’t a limitation. It’s a safety feature.

​
Deterministic vs Probabilistic

Let’s compare the two approaches:

​
Deterministic (TealTiger’s Model)

// Same input always produces same output
const decision1 = engine.evaluate({
  action: 'tool.execute',
  tool_name: 'file_delete',
  context: { user_id: 'user-123' }
});

const decision2 = engine.evaluate({
  action: 'tool.execute',
  tool_name: 'file_delete',
  context: { user_id: 'user-123' }
});

// Guaranteed: decision1 === decision2
// decision1.action === 'deny'
// decision1.reason_code === 'POLICY.TOOL.NOT_ALLOWED'
Characteristics:
  • Same inputs → same decision
  • Decisions traceable to explicit policy conditions
  • Failures explainable with reason codes
  • Audits are meaningful and defensible

​
Probabilistic (What We Avoid)

// ❌ What TealTiger does NOT do
const decision1 = aiGovernanceSystem.evaluate(context);
// decision1.action === 'allow' (confidence: 0.73)

const decision2 = aiGovernanceSystem.evaluate(context);
// decision2.action === 'deny' (confidence: 0.68)

// Same input, different output!
// Why? Model confidence changed, thresholds shifted, etc.
Characteristics:
  • Same inputs → sometimes different decisions
  • Decisions depend on confidence scores, hidden heuristics, or adaptive learning
  • Explanations are incomplete or post-hoc
  • Audits become “best effort”

​
Why Deterministic > Probabilistic (for Governance)

​
1. Auditability Requires Repeatability

The problem: Governance systems must produce evidence. 
// ✅ Deterministic: Can replay incidents
// January 15: User blocked for exceeding budget
const decision = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 15.00,
  context: { user_id: 'user-123', budget_limit: 10.00 }
});
// decision.action === 'deny'
// decision.reason_code === 'COST.BUDGET.EXCEEDED'

// March 20: Replay the same event for investigation
const replay = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 15.00,
  context: { user_id: 'user-123', budget_limit: 10.00 }
});
// replay === decision (guaranteed)
Why it matters:
  • Incident investigations require reproducible evidence
  • Compliance audits need defensible records
  • Debugging requires consistent behavior
  • Regulators expect deterministic systems

​
2. Security Enforcement Must Minimize Surprise

The problem: Probabilistic enforcement creates “decision drift.” 
// ❌ Probabilistic: Unpredictable enforcement
// Monday: Request passes
const monday = aiSystem.evaluate({ input: 'Delete user data' });
// monday.action === 'allow' (confidence: 0.72)

// Tuesday: Identical request fails
const tuesday = aiSystem.evaluate({ input: 'Delete user data' });
// tuesday.action === 'deny' (confidence: 0.68)

// Why did it change? Model updated? Threshold shifted?
// Users lose trust, developers bypass controls

// ✅ Deterministic: Predictable enforcement
const monday = engine.evaluate({
  action: 'tool.execute',
  tool_name: 'delete_user_data'
});
// monday.action === 'deny'

const tuesday = engine.evaluate({
  action: 'tool.execute',
  tool_name: 'delete_user_data'
});
// tuesday.action === 'deny' (guaranteed same)
Why it matters:
  • Developers can trust the system
  • Security teams can rely on enforcement
  • Users understand what’s allowed
  • No surprises during incidents

​
3. Developers Need Debuggability, Not Mystery

The problem: Probabilistic systems are hard to debug. 
// ❌ Probabilistic: Mystery debugging
// Support ticket: "It failed randomly"
const decision = aiSystem.evaluate(context);
// Why did it fail? Confidence too low? Threshold changed?
// Can't reproduce locally, works in staging, fails in prod

// ✅ Deterministic: Clear debugging
const decision = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 15.00,
  context: { user_id: 'user-123' }
});

if (decision.action === 'deny') {
  console.log('Blocked:', decision.reason_code);
  // Output: "Blocked: COST.BUDGET.EXCEEDED"
  
  console.log('Details:', decision.metadata);
  // Output: { budget_limit: 10.00, current_spend: 15.00 }
  
  // Clear: User exceeded budget by $5
}
Why it matters:
  • Developers can debug issues quickly
  • Support teams can explain failures
  • No “works on my machine” problems
  • Clear mental model

​
4. Governance Is a Contract, Not a Suggestion

The problem: Probabilistic outcomes turn governance into uncertainty. 
// ❌ Probabilistic: Governance as suggestion
// "It might block" (confidence: 0.65)
// "It might redact" (confidence: 0.72)
// "It might downgrade risk" (confidence: 0.58)

// Regulated systems can't accept "might"

// ✅ Deterministic: Governance as contract
const policy = {
  tools: {
    file_delete: { allowed: false }  // Contract: NEVER allowed
  },
  cost: {
    budget_limit: { perUser: { daily: 10.00 } }  // Contract: ALWAYS enforced
  }
};

// If policy says "not allowed", it's NEVER allowed
// If policy says "budget limit", it's ALWAYS enforced
Why it matters:
  • Compliance requires certainty
  • Regulated industries need guarantees
  • Mission-critical systems can’t tolerate “maybe”
  • Contracts are enforceable, suggestions are not

​
5. Incident Response Depends on Deterministic Evidence

The problem: Post-incident analysis requires reproducible decisions. 
// ❌ Probabilistic: Can't reproduce incident
// Security incident: User leaked PII
// Try to replay: Can't reproduce the decision
// Was it blocked? Was it allowed? Confidence changed?
// Post-incident analysis becomes opinion, not evidence

// ✅ Deterministic: Forensic confidence
// Security incident: User leaked PII on Jan 15
const incident = {
  timestamp: '2026-01-15T10:30:00Z',
  action: 'llm.call',
  input: 'My email is john@example.com',
  context: { user_id: 'user-123' }
};

// Replay the exact decision
const decision = engine.evaluate(incident);
// decision.action === 'redact' (guaranteed)
// decision.reason_code === 'SECURITY.PII.DETECTED'

// Forensic evidence: System DID detect PII and redact it
// If PII leaked, the issue is elsewhere (not governance)
Why it matters:
  • Incident investigations need facts, not guesses
  • Root cause analysis requires reproducibility
  • Compliance audits need defensible evidence
  • Legal proceedings require certainty

​
Where Probabilistic Signals Still Fit

TealTiger can consume probabilistic signals as inputs without making enforcement probabilistic. 
// ✅ GOOD: Probabilistic signals, deterministic enforcement
const toxicityScore = await toxicityClassifier.score(input);
// toxicityScore = 0.72 (probabilistic)

const decision = engine.evaluate({
  action: 'llm.call',
  input: input,
  context: {
    toxicity_score: toxicityScore  // Probabilistic signal as input
  }
});

// Policy evaluates deterministically
if (toxicityScore > 0.70) {
  // decision.action === 'deny' (deterministic)
  // decision.reason_code === 'SECURITY.CONTENT.TOXIC'
}
The pattern:
  • Signals may be probabilistic (ML classifiers, anomaly detectors)
  • Decisions are deterministic (policy-based thresholds)
This keeps enforcement explainable and stable.

​
Real-World Example

Here’s how determinism helps in practice:

​
Scenario: Budget Enforcement

// Policy: Users have $10/day budget
const engine = new TealEngine({
  policies: {
    cost: {
      budget_limit: { perUser: { daily: 10.00 } }
    }
  }
});

// Monday 9am: User makes request
const request1 = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 2.50,
  context: { user_id: 'user-123', current_spend: 8.00 }
});
// request1.action === 'allow' (8.00 + 2.50 = 10.50, under budget)

// Monday 10am: User makes another request
const request2 = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 3.00,
  context: { user_id: 'user-123', current_spend: 10.50 }
});
// request2.action === 'deny' (10.50 + 3.00 = 13.50, over budget)
// request2.reason_code === 'COST.BUDGET.EXCEEDED'

// Tuesday: Replay Monday's events for investigation
const replay1 = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 2.50,
  context: { user_id: 'user-123', current_spend: 8.00 }
});
// replay1 === request1 (guaranteed)

const replay2 = engine.evaluate({
  action: 'llm.call',
  estimated_cost: 3.00,
  context: { user_id: 'user-123', current_spend: 10.50 }
});
// replay2 === request2 (guaranteed)
Benefits:
  • User understands why request was blocked
  • Developer can debug the issue
  • Finance team can verify budget enforcement
  • Auditor can confirm compliance

​
What About Future Versions?

Future versions may introduce:
  • Richer signals (better PII detection, smarter anomaly detection)
  • Improved policy authoring (easier to write complex policies)
  • Enhanced risk models (more sophisticated risk scoring)
But TealTiger will always treat enforcement as:
  • Explicit
  • Deterministic
  • Explainable
  • Reproducible
We may evolve the inputs, but never the requirement for reproducible decisions.

​
Common Questions

​
”Doesn’t determinism limit flexibility?”

No. Determinism provides predictability, not rigidity. 
// You can still have flexible policies
const engine = new TealEngine({
  policies: {
    cost: {
      budget_limit: {
        perUser: {
          daily: 10.00,  // Default
          overrides: {
            'user-premium': 50.00,  // Flexible per user
            'user-trial': 5.00
          }
        }
      }
    }
  }
});

// Flexible, but deterministic
// Same user + same budget = same decision

​
”What about ML-based guardrails?”

ML classifiers can provide signals, but policies make decisions. 
// ML classifier provides signal
const piiScore = await piiClassifier.score(input);
// piiScore = 0.85 (probabilistic)

// Policy makes deterministic decision
const decision = engine.evaluate({
  action: 'llm.call',
  input: input,
  context: { pii_score: piiScore }
});

// If pii_score > 0.80, always block (deterministic)
if (piiScore > 0.80) {
  // decision.action === 'deny' (guaranteed)
}

​
”Can policies adapt over time?”

Yes, but explicitly, not automatically. 
// ❌ WRONG: Automatic adaptation
// Policy learns that user-123 needs more budget
// (This never happens - policies don't learn)

// ✅ CORRECT: Explicit updates
// Week 1: Observe usage patterns
const stats = analyzeUsage('user-123');
// stats.avgDailySpend = 15.00

// Week 2: Update policy explicitly
const policies_v2 = {
  cost: {
    budget_limit: {
      perUser: {
        daily: 10.00,
        overrides: {
          'user-123': 20.00  // Explicit increase based on data
        }
      }
    }
  }
};

​
Summary

TealTiger chooses determinism because governance requires: ✅ Consistency - Same input = same output
✅ Explainability - Clear reason codes
✅ Audit-grade evidence - Reproducible decisions
✅ Developer trust - No surprises Probabilistic “AI-like” enforcement may seem attractive, but for security, cost, and reliability governance, it’s a liability. Deterministic decisions keep governance boring — and boring is safe.

Goals

What TealTiger is designed to achieve

Stability Guarantees

What’s guaranteed stable

Best Practices

How to use TealTiger effectively

Anti-Patterns

Common mistakes to avoid