CEE — what actually ran
A business-agnostic protocol for deterministic-first execution, where the LLM is an edge tool rather than the driver.
- 26packages passing
- 313tests
- 0external dependencies
Changing a rule, before you ship it
The dividend of a deterministic engine, and the one thing no agent can offer: replay last quarter's decisions against a proposed rule and see exactly which ones flip. The plan an agent follows exists only while it runs, so there is nothing to replay. Note that one refund inside the affected range does not flip — probe verdicts come from the recording rather than a live check, so an account that was closed at the time stays closed, and the rule is the only thing that moved.
Last quarter, under the rule in force (auto-approve at or under $100):
37 refunds -- 29 paid, 8 held
Proposed change: tighten the limit to $50.
Replaying the same 37 refunds against the new rule:
15 of 37 decisions flip
r-0005 $63 paid -> held
r-0006 $95 paid -> held
r-0009 $74 paid -> held
r-0011 $88 paid -> held
r-0015 $57 paid -> held
r-0016 $99 paid -> held
r-0018 $68 paid -> held
r-0020 $52 paid -> held
r-0022 $85 paid -> held
r-0025 $61 paid -> held
r-0026 $91 paid -> held
r-0028 $72 paid -> held
r-0033 $66 paid -> held
r-0035 $55 paid -> held
r-0036 $97 paid -> held
6 more were held before and are held now. The outcome stands; only the
reason given to the operator changes, for example:
r-0004 output.cee.failure_reason: requirement not met: field "amount" (220) lte 100 -> requirement not met: field "amount" (220) lte 50
One refund did not flip that the amounts alone say should have. The probe
verdicts come from the recording rather than a live check, so an account that
was closed at the time stays closed, and the rule is the only thing that moved.Code audit — an AI PR reviewer, re-cast
The loop CodeRabbit, GitHub Copilot code review and Qodo PR-Agent run — find an issue and decide what to do about it — with the decision taken back from the model. The model only extracts a finding into structured fields, stamped model-derived; a deterministic workflow classifies severity and refuses to auto-block on a guessed one. A sandbox probe rehearses the action first, so blocking the hotfix that ends an incident, or autofixing generated code, routes to a human instead of executing. The final line is the error side of the batch: intent miss, probe refusal.
PR FINDING review this scanner result on the diff
source=scanner (real SQL injection on an ordinary path — block it)
-> merge blocked; changes requested
action: block_merge on internal/auth/login.go
trace: [classify require_confidence check_needs_gate require_verified_severity apply_gate]
PR FINDING audit this pull request change for security issues
source=scanner (same severity, but this PR is the hotfix ending a live incident)
-> held_for_human_review
because: the pull request is the hotfix for an active incident; blocking it keeps the fix from shipping
trace: [classify require_confidence check_needs_gate require_verified_severity apply_gate hold_for_human]
PR FINDING review this code finding in the pull request
source=llm (the model guessed 'critical' from prose — a guess must not auto-block)
-> held_for_human_review
because: refusing to act on model-derived severity: extracted values are not verified facts
trace: [classify require_confidence check_needs_gate require_verified_severity hold_for_human]
PR FINDING triage this static analysis finding
source=scanner (trivial style issue on hand-written code — safe to autofix)
-> autofix applied
action: apply_autofix on internal/util/format.go
trace: [classify require_confidence check_needs_gate require_verified_severity apply_gate]
PR FINDING triage this static analysis finding
source=scanner (same autofix, but the file is generated)
-> held_for_human_review
because: internal/pb/service.pb.go is generated; an autofix there is overwritten on the next build and hides the real source
trace: [classify require_confidence check_needs_gate require_verified_severity apply_gate hold_for_human]
PR FINDING check this scanner result on the diff
source=scanner (informational — a comment is enough)
-> commented (non-blocking)
trace: [classify require_confidence check_needs_gate post_comment]
PR FINDING audit this pull request change for security issues
source=scanner (high severity but the scanner is unsure — no auto-action on a maybe)
-> held_for_human_review
because: requirement not met: field "finding_confidence" (0.4) gte 0.6
trace: [classify require_confidence hold_for_human]
PR FINDING the office coffee machine is out of beans again
source=scanner (not a code finding at all — no intent matches)
-> no review intent matched (best score 0.07); would fall through to extraction
diagnostics: intent miss 12% (1 of 8), probe refusal 50% (2 of 4), escalation 0% (0 of 8 runs), 9 breaker tripsCrypto market surveillance — live data
Fixed thresholds over live quotes, swept hourly. This is anomaly flagging, not investment advice: every rule is a constant in a manifest or in deterministic Go, and no model is asked whether anything is worth buying. The guardrail is that a correct rule can still fire on data not worth acting on — a quote minutes stale describes a market that has moved on, and a large percentage move on a thin book is noise. A probe checks both before anything is raised.
== crypto market surveillance ==
Fixed thresholds over live quotes. Anomaly flagging, not investment advice.
Rules: move >= 2.0% · stablecoin peg +/- 0.5% · liquidity floor $250M · quotes younger than 15m0s
swept 8 assets at 2026-08-05 23:18 UTC
bitcoin $64605 nothing material (0.25% over 24h)
ethereum $1907 nothing material (1.53% over 24h)
solana $73.89 nothing material (0.42% over 24h)
dogecoin $0.0699 nothing material (0.76% over 24h)
tether $0.9992 nothing material (holding peg (0.08% off))
usd-coin $0.9996 nothing material (holding peg (0.04% off))
chainlink $8.14 nothing material (0.56% over 24h)
litecoin $45.25 nothing material (0.39% over 24h)Network intrusion detection
Alerts are matched to MITRE ATT&CK techniques and contained automatically — unless containment would do more damage than the intrusion. This is the reason detection teams distrust automated response: the dangerous case is not a wrong detector, it is a right one whose response takes the company off the internet. A pre-execution probe assesses the blast radius first, so blocking an address that turns out to be our own VPN egress, or isolating the jump host the responders log in through, routes to an analyst instead of executing.
ALERT horizontal port scan detected from internal host
peer=203.0.113.55 host=ws-4471 confidence=0.94
(ordinary workstation, nothing depends on it — safe to isolate)
-> matched network-detection.T1046_service_discovery (1.00)
-> contained automatically
action: isolate_host on ws-4471
trace: [require_confidence select_response contain record_contained]
ALERT password spray against the vpn gateway
peer=203.0.113.11 host=vpn-gw01 confidence=0.97
(the 'attacker' address is our own VPN egress)
-> matched network-detection.T1110_password_spray (1.00)
-> held for an analyst: containment would have hit something it must not
because: 203.0.113.11 is our VPN concentrator — about 900 remote workers egress here — blocking it hits us, not the attacker
trace: [require_confidence select_response contain hold_for_analyst]
ALERT periodic outbound connections with fixed interval
peer=198.51.100.7 host=build-07 confidence=0.88
(the beacon destination is a shared CDN node)
-> matched network-detection.T1071_c2_beaconing (1.00)
-> held for an analyst: containment would have hit something it must not
because: 198.51.100.7 is shared CDN edge — also fronts the payment callback endpoint — blocking it hits us, not the attacker
trace: [require_confidence select_response contain hold_for_analyst]
ALERT lateral movement over rdp
peer=10.4.2.19 host=jump01 confidence=0.91
(the host to isolate is the responders' own way in)
-> matched network-detection.T1021_lateral_movement (1.00)
-> held for an analyst: containment would have hit something it must not
because: jump01 is a responder jump host — isolating it would cut off 60 dependents
trace: [require_confidence select_response contain hold_for_analyst]
ALERT unusually large outbound transfer over dns
peer=203.0.113.90 host=ws-8802 confidence=0.96
(genuine exfiltration to an unrelated address)
-> matched network-detection.T1048_exfiltration (1.00)
-> contained automatically
action: block_address on 203.0.113.90
trace: [require_confidence select_response contain record_contained]
ALERT beaconing to an unclassified external host
peer=203.0.113.77 host=ws-4471 confidence=0.42
(technique matches, but the detector is unsure — no action on a maybe)
-> matched network-detection.T1071_c2_beaconing (1.00)
-> queued for review: detector confidence below the auto-action threshold
because: requirement not met: field "detector_confidence" (0.42) gte 0.8
trace: [require_confidence queue_for_review]
ALERT printer firmware update failed twice
peer=10.1.1.5 host=ws-4471 confidence=0.99
(not an intrusion at all — no technique matches)
-> no ATT&CK technique matched (best score 0.08); would fall through to extractionSecurity monitoring — a plugin with Go code
An alert matches a brute-force technique, and a sandbox probe runs before the containment action rather than after it. Against an ordinary workstation the action proceeds. Against a domain controller the probe refuses, and the circuit breaker downgrades to human approval instead of isolating a critical asset. Both paths below are the same workflow.
== Scenario 1: brute-force against an ordinary workstation ==
matched technique security.T1110_brute_force (confidence 0.62) -> entering workflow security.contain_threat
outcome: threat auto-contained (host isolated by deterministic action)
trace: [classify contain]
scorecard[security.contain_threat]: determinism 100% (2 deterministic steps, 0 LLM calls), 1 sandbox probes, 0 breaker trips, 47µs; vs a per-step agent this eliminated 2 LLM calls
== Scenario 2: the same technique, but against a domain controller ==
matched technique security.T1110_brute_force (confidence 0.62) -> entering workflow security.contain_threat
outcome: containment held for human approval (breaker downgraded, critical asset protected)
trace: [classify contain hold_for_human_approval]
scorecard[security.contain_threat]: determinism 100% (2 deterministic steps, 0 LLM calls), 1 sandbox probes, 1 breaker trips, 14µs; vs a per-step agent this eliminated 2 LLM calls
== Aggregate diagnostics across a batch ==
diagnostics: intent miss 20% (1 of 5), probe refusal 25% (1 of 4), escalation 0% (0 of 5 runs), 1 breaker tripsExpense approval — no Go at all
The entire DAG is a JSON manifest; there is not one line of Go behind it. Under the threshold it settles immediately. Over it, the run suspends for a manager and hands back a resume pointer; the decision arrives later and execution continues from where it stopped. The trace spans the pause as one continuous run, and the pointer cannot be used twice.
matched expense-approval.review (confidence 1.00) -> workflow expense-approval.review
== Scenario 1: under the threshold, no human needed ==
outcome: auto-approved
trace: [check_threshold record_auto_approved]
== Scenario 2: over the threshold, parked for a manager ==
suspended, resume pointer issued (74c4485d...)
trace: [check_threshold hold_for_human]
pending: amount exceeds the auto-approval threshold; awaiting manager decision
context preserved across the pause: claimant=wei amount=4800
== Scenario 2 continued: the manager approves ==
outcome: approved by manager
trace: [check_threshold hold_for_human apply_decision record_approved]
== The same pointer cannot be used twice ==
second resume refused: no suspended workflow for pointer "74c4485dc9d26ec5b16ebd8bf8f31836"Three more scenarios
An N-way switch assembled from steps that have only two outbound edges each; scheduling on an engine that owns no clock, where deferral is a suspension and something else resumes it; and a batch, where the loop lives in the caller because the DAG rejects cycles outright.
== ticket routing: an N-way switch from binary edges ==
T-1 (urgent/bug) -> pager-duty trace [check_urgent route_pager]
T-2 (normal/billing) -> finance-ops trace [check_urgent check_billing route_finance]
T-3 (normal/crash) -> engineering trace [check_urgent check_billing check_bug route_engineering]
T-4 (normal/how-do-i) -> general-support trace [check_urgent check_billing check_bug route_general]
== scheduling: deferral is suspension, not a timer ==
inside the window: applied=true trace [check_window apply]
outside the window: parked, applied=<nil> trace [check_window wait_for_window]
a scheduler holds: outside the maintenance window; deferred until it opens
window opens: applied=true trace [check_window wait_for_window apply]
== data sync: the loop lives in the caller, not the DAG ==
row-1 synced, target now at v8
row-2 held: the pre-write check refused
because: target row "row-2" moved from 3 to 7
rejected: no record_id
because: requirement not met: field "record_id" () neq
row-9 held: the pre-write check refused
because: target has no row "row-9"
1 of 4 records synced; the rest were held, not retriedPlugin catalog
Plugins are distributed as manifests and ranked by how many model calls they remove, measured against a baseline agent that would call a model once per step. The full leaderboard has the detail.
sla-guard L1 v0.1.0 Marks a support ticket as within SLA or breached based on a response-time threshold.
access-review L1 v0.1.0 Flags an account for recertification when it has not been reviewed within the allowed window.
refund-guard L1 v0.1.0 Auto-approves a refund under a threshold and routes larger ones to a manager.
payment-fraud-screen L1 v0.1.0 Bands a payment by risk score into approve, step-up authentication, or decline.
pr-size-gate L1 v0.1.0 Gates a pull request by lines changed: auto-mergeable, request review, or split it.
log-retention L1 v0.1.0 Retains, preserves under legal hold, or flags a record for deletion past its retention window.rank plugin determinism events errors LLM calls eliminated vs agent
1 log-retention 100% 4 0 11 of 11
2 payment-fraud-screen 100% 4 0 10 of 10
3 pr-size-gate 100% 4 0 10 of 10
4 access-review 100% 4 0 8 of 8
5 refund-guard 100% 4 0 8 of 8
6 sla-guard 100% 4 0 8 of 8Every shipped manifest, statically validated
examples/manifests/change-window.json ok: no issues
examples/manifests/code-audit.json [warning] workflow "codeaudit.triage" step "classify": action_ref "codeaudit.classify" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "codeaudit.triage" step "apply_gate": action_ref "codeaudit.apply_gate" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "codeaudit.triage" step "post_comment": action_ref "codeaudit.post_comment" is not a standard action; its existence is verified against Go hooks at load time
examples/manifests/crypto-surveillance.json [warning] workflow "crypto-surveillance.screen" step "enrich": action_ref "crypto.enrich" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "crypto-surveillance.screen" step "assess": action_ref "crypto.assess" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "crypto-surveillance.screen" step "raise": action_ref "crypto.raise_alert" is not a standard action; its existence is verified against Go hooks at load time
examples/manifests/expense-approval.json ok: no issues
examples/manifests/expense-guard.json ok: no issues
examples/manifests/local-netwatch.json [warning] workflow "local-netwatch.screen" step "enrich": action_ref "netwatch.enrich" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "local-netwatch.screen" step "assess": action_ref "netwatch.assess" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "local-netwatch.screen" step "raise": action_ref "netwatch.raise" is not a standard action; its existence is verified against Go hooks at load time
examples/manifests/network-detection.json [warning] workflow "network-detection.triage_and_contain" step "select_response": action_ref "netdet.select_response" is not a standard action; its existence is verified against Go hooks at load time
[warning] workflow "network-detection.triage_and_contain" step "contain": action_ref "netdet.apply_containment" is not a standard action; its existence is verified against Go hooks at load time
examples/manifests/onboarding-checks.json ok: no issues
examples/manifests/record-sync.json [warning] workflow "record-sync.push" step "write": action_ref "sync.write_to_target" is not a standard action; its existence is verified against Go hooks at load time
examples/manifests/ticket-routing.json ok: no issues
catalog/plugins/access-review/manifest.json ok: no issues
catalog/plugins/log-retention/manifest.json ok: no issues
catalog/plugins/payment-fraud-screen/manifest.json ok: no issues
catalog/plugins/pr-size-gate/manifest.json ok: no issues
catalog/plugins/refund-guard/manifest.json ok: no issues
catalog/plugins/sla-guard/manifest.json ok: no issues