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 [email protected]',
  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

Getting Started

Core Concepts

Governance Domains

Policy Authoring

Architecture

Integrations

Deployment

API Reference

Cookbook

Compliance & GRC

Guides

Reference

Versions

Playground

Dashboard

Blog

The Core Principle

Deterministic vs Probabilistic

Deterministic (TealTiger’s Model)

Probabilistic (What We Avoid)

Why Deterministic > Probabilistic (for Governance)

1. Auditability Requires Repeatability

2. Security Enforcement Must Minimize Surprise

3. Developers Need Debuggability, Not Mystery

4. Governance Is a Contract, Not a Suggestion

5. Incident Response Depends on Deterministic Evidence

Where Probabilistic Signals Still Fit

Real-World Example

Scenario: Budget Enforcement

What About Future Versions?

Common Questions

”Doesn’t determinism limit flexibility?”

”What about ML-based guardrails?”

”Can policies adapt over time?”

Summary

Goals

Stability Guarantees

Best Practices

Anti-Patterns

​The Core Principle

​Deterministic vs Probabilistic

​Deterministic (TealTiger’s Model)

​Probabilistic (What We Avoid)

​Why Deterministic > Probabilistic (for Governance)

​1. Auditability Requires Repeatability

​2. Security Enforcement Must Minimize Surprise

​3. Developers Need Debuggability, Not Mystery

​4. Governance Is a Contract, Not a Suggestion

​5. Incident Response Depends on Deterministic Evidence

​Where Probabilistic Signals Still Fit

​Real-World Example

​Scenario: Budget Enforcement

​What About Future Versions?

​Common Questions

​”Doesn’t determinism limit flexibility?”

​”What about ML-based guardrails?”

​”Can policies adapt over time?”

​Summary

​Related Reading

Goals

Stability Guarantees

Best Practices

Anti-Patterns

The Core Principle

Deterministic vs Probabilistic

Deterministic (TealTiger’s Model)

Probabilistic (What We Avoid)

Why Deterministic > Probabilistic (for Governance)

1. Auditability Requires Repeatability

2. Security Enforcement Must Minimize Surprise

3. Developers Need Debuggability, Not Mystery

4. Governance Is a Contract, Not a Suggestion

5. Incident Response Depends on Deterministic Evidence

Where Probabilistic Signals Still Fit

Real-World Example

Scenario: Budget Enforcement

What About Future Versions?

Common Questions

”Doesn’t determinism limit flexibility?”

”What about ML-based guardrails?”

”Can policies adapt over time?”

Summary

Related Reading