The Core Loop

One workflow that runs continuously — not on a calendar. Signal → Evaluation → Exception → Decision → Evidence.

1. Sense: Signal Ingestion

Signals flow into the system continuously. Each signal represents an observed change in reality:

• A position update from the trading system
• A volatility spike from market data
• A client withdrawal request
• A credit rating change from an external provider

Signals are validated, canonicalized, and stored with full provenance:

• Source — Where did this come from?
• Reliability — How confident are we in this data?
• Timestamp — When was this observed?

2. Evaluate: Policy Application

When signals arrive, they're evaluated against active policies. This evaluation is deterministic — the same inputs always produce the same outputs.

Evaluation results:

• Pass — All signals comply with policy. System may take automated action within bounds.
• Fail — Policy violation detected. Exception raised for human judgment.
• Inconclusive — Missing or low-confidence data prevents determination. Exception raised.

Each evaluation is hashed and stored. This enables:

• Replay — Re-run historical signals against current or modified policies
• Audit — Prove that evaluation was correct at the time
• Policy tuning — Compare exception rates before/after policy changes

3. Act or Escalate

Based on evaluation results, the system either acts autonomously or escalates for human judgment:

Within Policy (Act)

When evaluation passes, the system may take predefined actions automatically:

• Log the compliant state
• Update monitoring dashboards
• Trigger downstream notifications

Automated actions are constrained by explicit policy bounds. The system never acts outside defined parameters.

Outside Policy (Escalate)

When evaluation fails or is inconclusive, an Exception is raised:

• Assigned severity (Critical, High, Medium, Low)
• Deduplicated against existing exceptions (no spam)
• Grouped with context from contributing signals
• Presented with symmetric options for resolution

4. Decide: Human Judgment

The decision UI presents the exception on one screen with three columns:

Left: Context	Center: Options	Right: Decision
Impacted policy Contributing signals Uncertainty flags Related history	Option A Option B Option C Option D (all presented symmetrically)	Selected option Rationale (required) Assumptions Commit button

Key constraints on the decision surface:

• No recommendations — Options are visually equivalent
• No scrolling — Everything fits on one screen
• Rationale required — Can't commit without explaining why
• Uncertainty visible — Low-confidence signals are flagged

When the human commits, the decision becomes immutable. They cannot be edited, only superseded by new decisions in response to new exceptions.

5. Record: Evidence Pack Generation

After each decision, an Evidence Pack is generated automatically. This bundle answers: "Why did we do this?"

{
  "decision": {
    "chosen_option": "escalate_to_cfo",
    "rationale": "Given critical severity and 5-hour duration...",
    "decided_by": "treasurer@company.com",
    "decided_at": "2026-01-15T14:32:00Z"
  },
  "exception": {
    "title": "BTC position exceeds approved limit",
    "severity": "critical",
    "context": { ... }
  },
  "evaluation": {
    "result": "fail",
    "policy_version_id": "pol_v1_abc123",
    "signal_ids": ["sig_001", "sig_002"]
  },
  "signals": [ ... ],
  "policy": {
    "name": "Position Limit Policy",
    "version": 1,
    "rule_definition": { ... }
  },
  "content_hash": "sha256:abc123..."
}

Evidence packs are:

• Deterministic — Same decision produces same pack
• Hashed — SHA-256 for integrity verification
• Exportable — JSON, HTML, or PDF formats
• Audit-ready — Designed for regulatory examination

The Loop Continues

After a decision is recorded, the system continues sensing. New signals may trigger new evaluations, which may produce new exceptions, which require new decisions.

Outcomes are captured over time:

• What happened after we made this decision?
• Did our assumptions hold?
• Should this policy be tuned?

This creates institutional memory — not just a log, but a learning system that improves policies based on real outcomes.

Replay Capability

Because the kernel is deterministic, you can replay historical scenarios:

• Policy testing — "What if we change the limit from 10% to 15%?"
• Root cause analysis — "Given these signals, why did we get this exception?"
• Training — Run new team members through historical exceptions
• Regression testing — Ensure policy changes don't break expected behavior