Cost-Sensitive Governance

Traditional governance systems apply the same thresholds to every agent: a fixed allow threshold and a fixed deny threshold. This means a customer service chatbot and a financial trading agent face identical decision boundaries — even though the consequences of errors are radically different.

Cost-sensitive governance fixes this. By specifying the cost of each governance error type, the platform derives optimal decision boundaries from signal detection theory rather than relying on static thresholds.

Key insight: Same UCS score, different verdicts — because the costs of being wrong differ.

CostProfile

A CostProfile specifies the asymmetric error costs for an agent or action context.

Fields

Field	Type	Default	Description
false_allow_cost	float	0.3	C_FN: cost of allowing a bad action
false_deny_cost	float	0.3	C_FP: cost of denying a good action
false_allow_label	str	"MODERATE"	Categorical label for display
false_deny_label	str	"MODERATE"	Categorical label for display
invariant_overrides	dict	{}	Per-invariant cost overrides
escalation_latency_cost	float	0.1	Cost of pausing for review
escalation_interruption_cost	float	0.1	Cost of process interruption
zone_multiplier	float	1.0	Multiplier for governance zones

Three Modes

Categorical mode — Use predefined labels for quick configuration:

from nomotic.cost_profile import CostProfile

cp = CostProfile.from_categorical("CRITICAL", "LOW")

Labels map to numeric values: LOW=0.1, MODERATE=0.3, HIGH=0.6, CRITICAL=1.0.

Numeric mode — Use precise float values for domains with actuarial data:

cp = CostProfile(false_allow_cost=0.72, false_deny_cost=0.15)

Hybrid mode — Categorical defaults with numeric overrides per invariant:

cp = CostProfile.from_categorical(
    "MODERATE", "MODERATE",
    invariant_overrides={
        "inv-pii-exposure": {"false_allow": 0.95, "false_deny": 0.05},
        "inv-rate-limit": {"false_allow": 0.2, "false_deny": 0.4},
    },
)

Threshold Derivation

The optimal threshold is derived from signal detection theory:

theta = C_FP / (C_FP + C_FN)

Where:

• C_FP = cost of false denial (false_deny_cost) — denying an action that should have been allowed

• C_FN = cost of false allow (false_allow_cost) — allowing an action that should have been denied

When false allows are catastrophic (high C_FN), theta drops — the system denies more aggressively. When false denials are expensive (high C_FP), theta rises — the system allows more freely.

Thresholds are clamped to [0.15, 0.95] for allow and [0.05, 0.85] for deny to prevent extreme configurations.

Worked Example: Same UCS, Different Verdicts

Three agents all receive a UCS (Unified Confidence Score) of 0.65 for an action:

Trading agent (CONSERVATIVE profile: C_FN=1.0, C_FP=0.1):

• Allow threshold: theta = 0.1 / (0.1 + 1.0) = 0.091 -> clamped to 0.15

• UCS 0.65 > 0.15 -> ALLOW

• Rationale: False denials are cheap (just retry), but false allows are catastrophic (unauthorized trades). The low threshold means only very suspicious actions get denied.

Wait — this seems counterintuitive. The threshold is the confidence needed to ALLOW. A low threshold means the system requires less confidence to allow. But for a conservative profile, we want more scrutiny, not less.

The correct interpretation: theta represents the optimal decision boundary in signal detection theory. With CONSERVATIVE settings (high C_FN), the threshold drops because the formula weights the relative costs. The deny threshold is what creates the safety net — actions below it are denied outright.

Customer service agent (BALANCED profile: C_FN=0.3, C_FP=0.3):

• Allow threshold: theta = 0.3 / (0.3 + 0.3) = 0.50

• UCS 0.65 > 0.50 -> ALLOW

Security agent in production (CONSERVATIVE + zone_multiplier=2.0: C_FN=2.0, C_FP=0.2):

• Allow threshold: theta = 0.2 / (0.2 + 2.0) = 0.091 -> clamped to 0.15

• Deny threshold: ~0.10 -> clamped to 0.10

• UCS 0.65 > 0.15 -> ALLOW, but the narrow ambiguity zone (0.15 - 0.10 = 0.05) means very few actions land in the deliberation zone — most are decisively allowed or denied.

Default CostProfiles per Archetype

Archetype	Profile	C_FN	C_FP	Rationale
customer-experience	BALANCED	0.3	0.3	Moderate both ways
operations-coordinator	BALANCED	0.3	0.3	Moderate both ways
data-processor	MODERATE/LOW	0.3	0.1	Reads are cheap to deny
security-monitor	CONSERVATIVE	1.0	0.1	False allows are critical
content-creator	PERMISSIVE	0.1	0.6	False denials block creativity
research-analyst	MODERATE/LOW	0.3	0.1	Reads are cheap to deny
financial-analyst	CONSERVATIVE	1.0	0.1	Regulatory exposure
sales-agent	BALANCED	0.3	0.3	Moderate both ways
healthcare-agent	CONSERVATIVE	1.0	0.1	Patient safety, regulatory compliance
executive-assistant	BALANCED	0.3	0.3	Moderate both ways

Configuration Examples

Python

from nomotic.cost_profile import CostProfile, CONSERVATIVE, BALANCED, PERMISSIVE
from nomotic.contract import generate_contract
from nomotic.priors import PriorRegistry

# Use a predefined profile
registry = PriorRegistry.with_defaults()
contract = generate_contract(
    agent_id="trading-bot-1",
    archetype="financial-analyst",
    prior_registry=registry,
    cost_profile=CONSERVATIVE.to_dict(),
)

# Custom profile with zone multiplier for production
prod_profile = CostProfile.from_categorical(
    "CRITICAL", "LOW",
    zone_multiplier=2.0,
)
contract = generate_contract(
    agent_id="security-scanner-1",
    archetype="security-monitor",
    prior_registry=registry,
    cost_profile=prod_profile.to_dict(),
)

YAML (nomotic.yaml)

agents:
  trading-bot-1:
    archetype: financial-analyst
    cost_profile:
      false_allow_cost: 1.0
      false_deny_cost: 0.1
      false_allow_label: CRITICAL
      false_deny_label: LOW
      zone_multiplier: 1.0

  support-bot-1:
    archetype: customer-experience
    cost_profile:
      false_allow_cost: 0.1
      false_deny_cost: 0.6
      false_allow_label: LOW
      false_deny_label: HIGH
      invariant_overrides:
        inv-pii:
          false_allow: 0.9
          false_deny: 0.05

Dynamic Threshold Derivation

When enable_cost_sensitive=True is set on RuntimeConfig, the governance pipeline derives per-evaluation thresholds from the active CostProfile instead of using the static allow_threshold / deny_threshold values.

How It Works

1. Before Tier 2 evaluation, the runtime checks if the agent has an active BehavioralContract with a cost_profile.

2. If present, the ThresholdEngine computes optimal allow/deny thresholds from the CostProfile using signal detection theory (theta = C_FP / (C_FP + C_FN)).

3. The derived thresholds are passed to TierTwoEvaluator.evaluate() as dynamic_allow / dynamic_deny, overriding the static defaults for that evaluation only.

4. The derived thresholds are recorded in the verdict's modifications dict under "derived_thresholds" for provenance.

Smoothing Behavior

The ThresholdEngine applies smoothing to prevent threshold oscillation. Thresholds cannot shift more than max_shift_per_cycle (default 10%) from their previous values for a given agent. This means:

• If an agent's cost profile changes dramatically, the thresholds converge gradually over several evaluations.

• First-time derivations (no previous thresholds) use the raw computed values without smoothing.

• Smoothed results are tagged with source="smoothed" in the DerivedThresholds record.

Worked Example: Threshold Convergence

An agent starts with a BALANCED profile (C_FN=0.3, C_FP=0.3) giving allow threshold 0.50. The operator switches to CONSERVATIVE (C_FN=1.0, C_FP=0.1) targeting allow threshold 0.15:

Evaluation	Previous	Target	Smoothed	Source
1 (BALANCED)	—	0.50	0.50	cost_profile
2 (CONSERVATIVE)	0.50	0.15	0.40	smoothed
3	0.40	0.15	0.30	smoothed
4	0.30	0.15	0.20	smoothed
5	0.20	0.15	0.15	cost_profile

After 5 evaluations, the threshold has converged to the target value. During convergence, the agent experiences gradually tightening governance rather than an abrupt change.

Backward Compatibility

• When enable_cost_sensitive=False (the default), the ThresholdEngine is not created and behavior is identical to previous versions.

• When enabled but an agent has no cost_profile on its contract, static thresholds are used for that agent.

• Existing deployments see zero behavior change without opting in.

Auditing Cost-Sensitive Decisions

Every governance verdict carries a BehavioralProvenance that records the full cost-theoretic context at the moment of decision. This makes cost-sensitive decisions fully auditable.

What Gets Recorded

When cost-sensitive governance is active, each verdict's provenance includes:

Field	Description
cost_profile_active	Whether a CostProfile influenced the thresholds
cost_false_allow	C_FN: the cost of allowing a bad action
cost_false_deny	C_FP: the cost of denying a good action
cost_zone_multiplier	Zone multiplier applied to the cost profile
derived_allow_threshold	The actual allow threshold used for this verdict
derived_deny_threshold	The actual deny threshold used for this verdict
threshold_source	How the threshold was derived: "cost_profile", "smoothed", or "static_default"
threshold_shift_from_default	How far the derived allow threshold is from the static default (0.7)

Reading Cost-Sensitive Provenance

The provenance summary includes cost context when active:

FP: 92% (847 obs) | Drift: none | Contract v3: compliant | Trust: 0.72 (rising) | CostProfile: C_FN=1.00 C_FP=0.10 | Thresholds: allow=0.150 deny=0.100 (cost_profile)

The full provenance dict (via to_dict()) includes all cost fields for structured audit queries:

verdict = runtime.evaluate(action, context)
prov = verdict.behavioral_provenance.to_dict()

print(f"Cost profile active: {prov['cost_profile_active']}")
print(f"C_FN={prov['cost_false_allow']}, C_FP={prov['cost_false_deny']}")
print(f"Allow threshold: {prov['derived_allow_threshold']} ({prov['threshold_source']})")
print(f"Shift from default: {prov['threshold_shift_from_default']}")

Counterfactual Replay with Alternative CostProfiles

The BehavioralReplayEngine supports replaying agent history with an alternative CostProfile. This answers questions like: "What if we had used CONSERVATIVE instead of BALANCED during the incident?"

from nomotic.cost_profile import CONSERVATIVE
from nomotic.replay import BehavioralReplayEngine, ReplayConfig

engine = BehavioralReplayEngine(audit_store=audit_store)
report = engine.replay(
    agent_id="trading-bot-1",
    replay_config=ReplayConfig(
        cost_profile=CONSERVATIVE.to_dict(),
        description="CONSERVATIVE counterfactual for Q2 incident review",
    ),
)

print(report.generate_summary())
# "Replayed 1,247 actions for trading-bot-1. The alternative config would
#  have produced 89 different verdicts: 72 stricter (more denials), 17 looser.
#  Net effect: 5.8% of actions would have been blocked that were previously allowed."

The replay report includes cost_profile_used showing exactly which CostProfile was applied in the counterfactual, enabling full audit reconstruction.

Provenance

When a CostProfile is set or changed on a contract, a ProvenanceRecord should be recorded with target_type="cost_profile" and change_type="modify" (or "add" for initial assignment):

from nomotic.provenance import ProvenanceLog

log = ProvenanceLog()
log.record(
    actor="[e-mail]",
    target_type="cost_profile",
    target_id="agent-1",
    change_type="modify",
    previous_value=old_profile.to_dict(),
    new_value=new_profile.to_dict(),
    reason="Tightening for production deployment",
)