Pick a guided case and click Run evaluation.
The uncomfortable truth
Prohibited activity can still technically happen. Escalation is often calendar-driven, not risk-driven. QA usually detects after the fact.
Most collections stacks have policy, training, and some suppression. They rarely have structural prevention: a single place that knows active protections, scores obligation risk in advance, and refuses the wrong action at execution time with evidence you can replay.
If an action should not happen, it cannot happen.
Day 15 is not a risk model.
Start with : load the guided case, run evaluation, then try to send a demand letter. Watch it blocked with trace, scoring, and arbitration made visible.
Run locally
This demo uses the real Python state engine. Reference data (ref_cof_*) loads from PostgreSQL when DATABASE_URL is set (Railway); otherwise from repo CSVs. Open a terminal in the COF folder (parent of demo/) and run:
cd path\to\docs\COF py demo\serve.py
Open http://127.0.0.1:8765/demo/index.html (or http://127.0.0.1:8765/). Use 127.0.0.1, not localhost, if the page does not load (IPv6 vs IPv4).
Or run run-demo.ps1 from the COF folder. Optional: py demo\serve.py --port 8766 if the port is busy.
What you can do here
- Business: Marketing story with sub-tabs (Overview, Old vs new, The shift, Layers & proof), plus links to live samples.
- Solution map: Diagrams for CGF → REA → COP and data flow.
- State & gate logic: See how business states are defined, then browse the live sample tables (state catalogue and prohibition matrix).
- Live proof (was Try entity): Guided case, obligation scoring, big action buttons, block or allow verdict, arbitration, regulator-style trace, simple SLA simulation.
- Demo reports: Sample HTML reports under
reporting/.
Control Orchestration Framework (COF)
From interpretive policy to engineered execution
Most organisations can demonstrate compliance. Few can demonstrate structural prevention. COF moves compliance from interpretive process toward engineered determinism: obligations become executable, prohibited actions are blocked at execution time, and breach risk is visible before it materialises.
Embed obligation into execution. Map your risk states and controls to COF. Compliance, stabilised.
This page mirrors the What COF Is story: use the tabs below for the full marketing narrative, then open technical tabs for diagrams and live data.
If you strip it back, the platform does three things: converts obligations into executable logic, blocks prohibited actions in real time, and forecasts breach risk before it materialises. It turns compliance from reactive monitoring into engineered prevention. COF does not only automate controls: it restructures how compliance is executed, governed, and evolved.
Same uncomfortable truth
Prohibited activity can still happen in many stacks. Escalation is often calendar-driven, not risk-driven. QA often finds issues after the fact.
If an action should not happen, it cannot happen.
Day 15 is not a risk model.
for the guided case and the block moment.
What the platform delivers (three outcomes)
Concepts first; expand each block for how it works technically.
1. Executable logic
Marketing line: Rules become logic your systems can run, not slides people interpret differently.
Business: Regulatory and policy obligations are expressed as configuration (not ad hoc interpretation).
How it works (technical)
- A state catalogue lists logical states (for example hardship active, hardship under assessment, complaint open, on arrangement, with DCA). Each state has entry and exit rules written against host fields (dates, flags, product context).
- Parameters in configuration (thresholds, bands, clock lengths) turn policy into testable conditions. The state engine evaluates one entity snapshot and returns which states are currently active.
- Multi-state is normal: several states can be active together. Downstream rules use a resolved view after arbitration, not a single flag.
2. Real-time blocking
Marketing line: If an action should not happen, it cannot happen, with evidence.
Business: High-risk actions (for example demand, enforcement, referral) are validated against active protections before they run.
How it works (technical)
- A prohibition matrix ties active states to blocked activities and reason codes for audit.
- Production uses a gate; this demo mirrors the idea on Live proof.
- Priority and arbitration resolve overlaps so the gate is deterministic.
3. Breach risk foresight
Marketing line: See where risk is rising before it becomes a breach headline.
Business: Teams see green / amber / red / black style posture and buffer signals before a breach lands in a report.
How it works (technical)
- Obligation clocks and breach bands encode SLA posture.
- Buffer rules support early intervention.
- Outputs feed Demo reports; full solution adds simulation and stress.
States: what they are and how they drive the rest
A state is a named business condition for a customer, account, or case. Examples often include hardship request / under assessment, hardship active, complaint open, legal or pre-legal hold, vulnerability, on arrangement, with external DCA, and arrears stage (early / late) where you define them. Life-event flags such as bankruptcy or deceased sit on the host model and join the same catalogue when configured.
Each state is defined by parameters. Multi-state is expected. The active set drives which SLA clocks, prohibited activities, and mandatory obligations apply, after arbitration.
Old vs new: is your compliance interpretive or engineered?
Typical collections and hardship environments rely on policy, training, and after-the-fact checks. COF is built so evidence shifts from policy reference to execution trace, and from monitoring to structural prevention.
Enforcement during hardship
Before
Policy on file, training, suppression in some paths, QA after the fact. Enforcement can still be technically possible. Prevention depends on memory and discipline.
After (COF)
Hardship activates in the model. A real-time gate blocks enforcement-class actions. Blocked attempts log with trace IDs. New reality: while protected, enforcement is structurally blocked, not merely discouraged.
Hardship decision SLA
Before
Timer in the system, escalation at a fixed day (for example day 15), calendar-driven queues. Breaches surface late; escalation is time-based, not risk-weighted.
After (COF)
Obligation clocks with pause and resume, buffer zones before breach, exposure-weighted risk. Escalation when risk rises (exposure, vulnerability, backlog), not only when a date ticks over.
Prohibited activities
Before
Suppression flags and manual checks. Overrides possible; state collisions handled inconsistently.
After (COF)
Central matrix plus activity gate, dominance when states collide, structured override with QA hooks. Deterministic control, not partial automation only.
Control assurance
Before
Periodic testing, sample QA, spreadsheet attestations. Coverage of automated vs manual often unknown.
After (COF)
Coverage registry, automation ratio, recertification cadence, decision trace replay, policy vs config drift views. Integrity is monitored continuously.
Automation and maturity
Before
“We have automation in some workflows” without a definitive coverage number. Manual dependency stays high.
After (COF)
Maturity is expressible as % mapped to executable controls and % deterministic. COF targets high automation at maturity Level 4, toward Level 5 with simulation.
Regulatory change
Before
Policy update, change request, manual testing, hope for no side effects. Impact often unknown until after deployment.
After (COF)
Versioned parameters, where-used, impact simulation, projected breach exposure, stability delta. Know the impact before you deploy the change.
Regulator-style question: “How do you prevent this?” Traditional answer: policy and training. COF answer: execution trace: state snapshot, clock position, parameter version, arbitration outcome, allow or block, all replayable.
The bigger shift
COF evolves compliance into something that is:
Engineered
Predictive
Quantifiable
Translatable across jurisdictions
Trusted by regulators
Safer for customers & staff
Adaptable to change
Future-proofed
It moves compliance from a control function to an operational architecture. From monitoring breaches to engineering stability. Most organisations can demonstrate compliance. Few can demonstrate structural prevention. COF makes compliance executable. That changes the conversation entirely.
Policy compliance vs engineered compliance
From
Policy reference
To execution trace and deterministic runs.
From
Manual controls
To engineered controls in registers and engines.
From
Reactive monitoring
To deterministic prevention and foresight.
From interpretive to deterministic. From static day-15 style thresholds to predictive scoring. From fragmented rules to orchestrated state, gate, and trace. From reactive reporting to trusted explainability. From change risk to change simulation.
Strategic differentiation (not “more reporting”)
| Typical environment | With COF |
|---|---|
| Rules scattered across documents and workflows | Executable obligations in registers and engines |
| Inconsistent handling when states overlap | Deterministic arbitration and governing obligation |
| Hard-coded SLA day thresholds | Versioned clock governance and buffer banding |
| After-the-fact breach discovery | Proactive breach posture and decision trace |
| Most environments have rules | Few have executable obligations, deterministic arbitration, versioned clock governance, exposure-weighted breach modelling, stress-tested regulatory simulation together |
Maturity: designed for Level 4 deterministic execution, moving toward Level 5 predictive and simulation-led assurance. Detail in the COF Three Layers material.
Three integrated layers
One line for executives and architecture reviews:
We have developed a Control Governance Framework (CGF), implemented through a Regulatory Execution Architecture (REA), delivered via a configurable Control Orchestration Platform (COP).
| Layer | Business question | Role |
|---|---|---|
| CGF | What should exist? | Design authority: obligation taxonomy, state model, arbitration philosophy. |
| REA | How does it work technically? | Blueprint: data shapes, engines, integration to PCC or other hosts. |
| COP | Does it run? | Platform: state evaluation, gate, scoring, reporting, simulation in full rollout. |
flowchart LR
subgraph b [Business view]
P[Policy and obligations] --> C[COF]
C --> O[Prevention and trace]
end
subgraph t [Technical view]
SD[State catalogue] --> SE[State engine]
SE --> ST[Active states]
PM[Prohibition matrix] --> GA[Gate decision]
ST --> GA
end
What COF does not do
COF guardrails your decision engine. It does not replace it. It does not allocate work, assign delegated authority, or redesign host workflows. It emits structured signals (scores, blocks, traces) that plug into PCC, Pega, or your operational stack.
Strategic elevation: collections moves from operational compliance alone to engineered compliance: executable obligations, deterministic arbitration, versioned clock governance, exposure-weighted breach modelling, stress-tested regulatory simulation.
Proof in this demo
Open the technical tabs to go deeper: Solution map for diagrams, State & gate logic for live catalogue and matrix samples, Live proof for evaluation, Demo reports for sample dashboards.
Three layers
From interpretive policy to engineered execution: Framework (CGF), Architecture (REA), Platform (COP).
flowchart LR
subgraph design [Design]
CGF["COF Framework (CGF)"]
end
subgraph blueprint [Blueprint]
REA["COF Architecture (REA)"]
end
subgraph run [Execution]
COP["COF Platform (COP)"]
end
CGF --> REA
REA --> COP
Host["Host SoR / PCC"] -->|entity snapshot| COP
COP --> Out["slarisk · gate · trace"]
Control flow (simplified)
flowchart TB
E[Entity snapshot from host] --> SE[State engine]
SD[State catalogue config] --> SE
SE --> AS[Active states multi-state]
AS --> PM[Prohibition matrix]
PM --> G{Gate allow / block}
CLK[SLA clocks & breach bands] --> SL[Proactive score / risk band]
AS --> SL
State catalogue (sample data)
What you are seeing: Each row is one state definition in the configured catalogue. Business-facing names map to internal codes (state_id). Entry and exit columns are the parameterised rules: when host-supplied fields satisfy them, the engine treats that state as active or inactive. That same active set drives which clocks, prohibited actions, and mandatory obligations apply (via separate matrix and register configuration). Multiple states can be active at once; arbitration orders them for gate and reporting.
Sample rows below are live from this demo’s configuration (same idea as production: catalogue + parameters, not code changes per rule). Toggle inactive rows to compare superseded definitions. For a narrative explanation, see the Business tab, section “States: what they are and how they drive the rest.”
| state_id | state_name | Account | Case | Customer | Status | entry_condition | exit_condition |
|---|
Prohibition matrix (sample data)
What you are seeing: Each row ties one or more active state codes to a prohibited activity (for example send demand, outbound dialler, enforcement). The gate uses this with the resolved active state set. Use Live proof after you compute states to run an illustrative allow or block check.
| prohibition_id | if_states_active | prohibited_action | reason_code |
|---|
Three proofs in one flow
Prevention · Prediction · Proof
This panel is the demo. Load the guided case, run evaluation, then attempt a high-risk action. You should feel the block before you read the footnotes. Obligation scoring shows why this case can go red before a calendar escalation day. The trace block is what you would show a regulator.
- Prevention: a prohibited action does not execute.
- Prediction: breach posture is visible before the breach.
- Proof: every outcome is timestamped, explained, and tied to active protections.
Case story
Active Obligations
We do not stop activity. We redirect it to next best compliant actions. Multiple clocks can run in parallel; risk is not a single calendar day.
Run evaluation to see the obligation stack.
What-if: policy SLA length
Move the slider to change the hardship decision SLA length (days). The demo recalculates days remaining and risk band for the guided case without pretending to be a full production model.
Attempt a high-risk action
Same activities your host would send to a gate. The demo shows BLOCKED or ALLOWED, governing obligation, and next best compliant actions.
How multiple states resolve
Several protections can apply at once. COF resolves which concern governs each class of decision.
Run evaluation to see governance lines.
Decision trace (regulator-ready)
What you would put in front of an audit: outcome, rationale, protections, parameters.
Trigger an action after evaluation to populate trace.
Sample reports
HTML dashboards with a Data source toggle: static sample_slarisk.csv or live Postgres treatment scores.
For live config use admin;
for live evaluation use Live proof.