Policies

Policies in TraceMem answer one core question:

"Under what conditions is this action allowed to happen?"

They do not execute workflows, mutate data, or replace business logic. They act as decision constraints that are evaluated at execution time and recorded as evidence.

What Policies Are (and Are Not)

A policy is:

• A deterministic decision rule
• Evaluated at execution time
• Versioned and immutable once published
• Recorded as part of the decision trace
• Allowed to return exceptions, not just yes/no

A policy is not:

• A workflow
• A script with side effects
• A model prompt
• A replacement for application logic
• A post-hoc compliance check

Policies define whether an action may proceed, not how it proceeds.

Where Policies Sit in the Flow

Decision Envelope
    ↓
Data reads (purpose-bound)
    ↓
Policy evaluation(s)
    ↓
[ Optional approval ]
    ↓
Write / mutation
    ↓
Decision outcome + snapshot

Policies are evaluated after context is gathered and before any mutation is committed.

Policy Lifecycle

1. Policy Authoring (Admin)

Policies are created by administrators via:

• The Admin Dashboard
• The Admin API

They are not created dynamically by agents.

Status: draft - Not used by agents yet

2. Policy Publishing

Once published:

• A policy becomes immutable
• It receives a version identifier and hash
• It can be referenced by Data Products or decisions
• New decisions automatically use the latest published version

Status: published - Available for agent use

3. Policy Evaluation (Runtime)

During a decision:

• The agent requests a policy evaluation
• TraceMem evaluates the policy using execution-time inputs
• The result is recorded as a policy_eval decision event

4. Policy Evidence Retention

The policy version and evaluation outcome are:

• Stored in the decision trace
• Included in the decision-time snapshot

This ensures "why" remains answerable even if the policy changes later.

Policy Definition Model

1. Metadata

• policy_id (stable name)
• Version / hash
• Description
• Scope (which Data Products / actions it applies to)
• Owner (team or role)

2. Inputs

Policies operate on explicit inputs, such as:

• Values from prior reads
• Derived metrics (counts, flags)
• Parameters passed by the agent

Policies do not fetch data themselves.

Example inputs:

{
  "proposed_discount": 0.20,
  "account_tier": "enterprise",
  "open_sev1_count": 3
}

3. Evaluation Logic

Policies are deterministic.

Conceptually:

inputs → evaluation → outcome

4. Outcomes

TraceMem policies return one of:

• allow - Policy permits the action
• deny - Policy blocks the action
• requires_exception - Human approval required

They do not return "maybe" or free-form text.

This strictness is what makes decisions auditable.

5. Rationale

Every evaluation produces a rationale, stored as structured data + short text.

Examples:

• "proposed_discount 20% exceeds cap 10%"
• "no approval route configured for exception"
• "override allowed by role FinanceVP"

Rationale is part of the trace.

Exception Routes

A key TraceMem innovation: exceptions are expected, not failures.

What an exception means:

• The policy cannot allow the action automatically
• The policy does not block permanently
• The decision must escalate to human judgment

Exception route definition:

When a policy returns requires_exception, it references an Approval Route that defines:

• Which integration to use (Slack, email, webhook)
• Where to send the approval request
• Whether rationale is required
• Expiration time

Example: "Discounts over 10% require Finance approval via Slack #finance-approvals."

This is configured by attaching an Approval Route to the policy. The Approval Route references an Integration (Slack) and specifies the destination (#finance-approvals).

For more details, see Approval Routes and Integrations.

Policy Attachment Points

Policies can be attached at different levels:

A) Data Product-Level Policies

Applies to all access to a Data Product.

Examples:

• "PII fields require purpose = support or compliance"
• "Writes to finance data require approval"

B) Action-Specific Policies

Applied explicitly during a decision.

Examples:

• "Discount must be ≤ 10% unless exception approved"
• "Escalations require SEV-1 incident present"

C) Composite Policies

Multiple policies may be evaluated in one decision.

Each evaluation is recorded separately.

How Agents Use Policies

From the agent's perspective:

• Policies are named
• Evaluated explicitly or implicitly
• Results are structured and actionable

Example flow:

1. Read context
2. Evaluate policy
3. If allow → continue
4. If requires_exception → request approval
5. If deny → abort

Agents do not interpret policy semantics beyond the outcome.

Policy Evaluation as a Decision Event

Each evaluation produces a policy_eval event with:

• policy_id
• Policy version/hash
• Input references
• Outcome
• Rationale
• Timestamp

This event is immutable.

This is critical:

TraceMem records how the rule was applied, not just that a rule exists.

Decision-Time Snapshots

As part of committing a decision, TraceMem captures:

• The exact policy versions evaluated
• Their hashes
• Any configuration that affected evaluation

This allows:

• Replaying the decision later
• Explaining behavior after policies evolve
• Auditing past exceptions fairly

Common Policy Examples

Discount Cap

• Input: proposed_discount
• Rule: ≤ 10% → allow
• Else: → requires_exception

Data Sensitivity

• Input: data_classification
• Rule: PII + purpose not in allowed list → deny

Escalation Routing

• Input: incident_severity, customer_tier
• Rule: SEV-1 + enterprise → requires_exception

Best Practices

1. Policies must be boring - boring = reliable = trusted
2. Policies must be versioned - no silent edits
3. Policies must never fetch data - inputs are explicit
4. Policies must not mutate state - they only decide
5. Every evaluation must leave evidence - no black boxes

Why Policies Are Not Prompts or Models

This is intentional.

Policies must be:

• Deterministic
• Explainable
• Auditable
• Replayable

Using LLMs inside policies would:

• Break determinism
• Make audit impossible
• Undermine trust

LLMs may help author or suggest policies later—but never evaluate them at runtime.