MMSelected work
INDEPENDENT SYSTEMS CONCEPT
/
CRM / DECISIONING / 2026CASE 02

GOVERNED LIFECYCLE AUTOMATION

Decision
Engine

The model can write.
It never gets to decide.

A decisioning prototype that turns lifecycle intent into an inspectable route: eligibility first, risk gates before generation, offers resolved before content, and every outcome logged and measurable.

01SIGNAL
02GATE
03RESOLVE
04GENERATE
05VALIDATE
06ACT / STOP
07MEASURE
SYNTHETIC DATA · LOCAL DECISION LOGIC · SIMULATED GENERATION
01

SYSTEM ARCHITECTURE

One profile layer.
One rulebook.
Many outputs.

Campaign logic often gets distributed across journeys, templates and channel rules. This prototype puts the decision layer in front of them. The channel becomes an output of the system, not the place where strategy is defined.

PROFILE LAYERstate · value · reachability · consent · risk
DECISION
ENGINE
deterministic first
OUTPUT ALifecycle route
OUTPUT BContent state
OUTPUT CNo action
OUTPUT DService route

INTERACTIVE PROTOTYPE

Run the decision,
not the campaign.

Three synthetic profiles exercise the same rule set. A demonstrates a normal route, B an authorized offer, and C a hard stop. The trace exposes why each outcome happened.

DECISION LAB / LOCAL PROTOTYPEIDLE
signalgateresolvegeneratevalidateact / stopmeasure
USER_CONTEXT

            
DECISION OUTPUT
Run a profile to inspect the route.
DECISION TRACE0 events
02

GOVERNANCE + MEASUREMENT

Unsafe output should fail
before it exists.

PRE

Eligibility is deterministic

Consent, contact-risk and service-state checks happen before any generative step can run.

MID

Offers are resolved before content

The content layer may describe an authorized offer; it cannot create one.

POST

Validation is a second boundary

Schema, grounding, offer integrity and channel constraints are checked before action.

MEASUREMENT

A send is not success.

The system needs control groups, outcome data and an exception queue so decisions can be compared against doing nothing and ambiguous cases become visible work.

TREATMENTobserved outcome
INCREMENTAL EFFECT
CONTROLwhat would have happened anyway
01Holdouts

Persistent control groups to separate incremental effect from observed response.

02Outcome joins

Action metadata returns to the warehouse and is matched with later behavior.

03Exception queue

Ambiguous or high-impact cases become visible work instead of hidden automation.

PUBLIC BOUNDARY

The logic is visible.
Private context is not.

This version is intentionally sector- and brand-neutral. It contains no client, employer, platform, user or campaign names. All profiles and outputs are synthetic. The interface runs deterministic local decision logic; it is not connected to a live CRM, offer system or language model.

Back to selected work