Customer Action Control Plane

Ultra CSM is a work-in-progress, eval-first customer action control plane. It turns tenant-scoped CRM, onboarding, product, support, and communication evidence into a proposed next action while keeping that draft from becoming an unauthorized customer commitment.

The repository is a synthetic reference build, not a production customer system. It computes priority with deterministic rules, drafts a bounded next action, and stops at a configured approval boundary. In credentialed paths, a bearer token maps to a principal stored as human-kind and distinct from the proposing actor. The software verifies that mapping, not whether a person is behind the token. The local no-auth demo uses a labeled stand-in.

Open the live read-only demo. Synthetic data, no login, customer sends disabled. Deterministic receipt: 24/24 hard gates pass for evidence, consent, tenant separation, grounding, injection defense, reproducibility, and proposal-only behavior. Governance receipts: tests/test_action_gate_machine.py covers identity kind, actor separation, consent, and payload binding; tests/test_action_control_sandbox.py covers tamper refusal, idempotent retry, and simulated commit.

Why this exists

Customer teams can inspect CRM, onboarding, product, support, and communication systems one at a time. The harder job is to reconcile those records into one explainable action without letting a generated draft become permission. Ultra CSM makes the evidence path inspectable and keeps authorization in code and durable state.

Start here

Your job	Start here
Run the fixture-backed system	Quickstart
Follow the local or hosted UI	Demo walkthrough
Inspect the input-to-receipt code path	Representative reading path
Understand the trust boundary	Security posture
Check what remains unproven	Current limits
Navigate the rest of the documentation	Documentation index

Run the read-only demo in 90 seconds

Open the hosted demo, select Trailhead Logistics, and inspect four stages:

1. tenant-scoped source records supply the evidence;
2. deterministic rules compute priority;
3. a bounded fixture writer proposes a draft with cited evidence, labeled by its actual source (example, model-generated, or template fallback — never asserted as AI-written by default);
4. the interface stops at the configured approval boundary.

The hosted build has no write path: approve, deny, and edit run entirely as browser state, never as a network call. Clicking Approve does not call the gate, run a committer, or send a message — the receipt panel labels every one of those steps "simulated" and says so explicitly. Reloading the page clears all simulated decisions and restores the full pending queue; nothing persists past the tab. A non-read-only local build can record real approve, deny, and revise verdicts, but an approved verdict there is not labeled sent or committed without a separate committer receipt.

The /ui/action-control/ route makes the boundary inspectable. The hosted build shows frozen output from the executable proof and names its sandbox backend as unavailable. A local sandbox can approve one synthetic payload, commit it to a temporary outbox, retry idempotently, and refuse tampering. See the sandbox contract.

The control path

tenant-scoped evidence
  -> deterministic value model and priority
  -> bounded draft (live model or labeled fixture/fallback)
  -> pending action proposal
  -> configured approval identity: verdict record
  -> payload-bound committer
  -> commit receipt

The system uses one shared customer value model rather than independent agents that can disagree about account truth. Time-to-value, retention, and expansion are lenses over that model. Product and Engineering handoffs share the evidence spine but do not bypass the customer-action gate.

Verify the claim

Run make scorecard-csm-check and make eval. The quickstart lists the remaining local gates and prerequisites. None needs cloud credentials or customer data; credentialed connector and model lanes stay separate.

Customer-outcome comparison eval

eval/customer_outcome_comparison.py compares the unchanged Ultra sweep (run_time_to_value_sweep behind the real ActionGate, on an EphemeralCluster local Postgres) against a small, independently implemented rules baseline, over 24 model-authored accounts (eval/customer_outcome_cases.py, 12 stories x 2 decision points). The job: choose a justified customer action, internal review/escalation, or hold from account facts at a point in time -- specifically whether a claimed completed change actually establishes the customer's stated objective. Neither policy sees the expected decisions; the oracle lives in a section of customer_outcome_cases.py that the scenario builder never reads.

PYTHONPATH=src:. python eval/customer_outcome_comparison.py \
    --out-json /path/to/result.json --out-md /path/to/report.md

Both output paths are required explicitly and are never overwritten silently (pass --force to overwrite). The Markdown report lists each case's allowed decisions, both policies' normalized decisions, and any forbidden-consequence violation. Cases and labels were revised after an invalid first run. These paired snapshots are development fixtures; they do not measure longitudinal recovery or independent generalization. The report records that exposure and source hashes.

Claim boundary

The static demo, dev and trial connector receipts, single-labeler judge, and synthetic renewal outcomes do not prove a production deployment or customer impact. The canonical limits page states each boundary with its direct evidence.

Apache-2.0 — see LICENSE.