Control Orchestration Framework

Compliance enforced by design — not detected after the fact.

From compliance overlay to execution architecture

Control Orchestration Framework

From compliance overlay to execution architecture

Most organisations overlay compliance onto operational workflows. COF flips the model: compliance becomes the core execution architecture, and workflow operates inside that governed structure.

Obligations become active states, clocks, gates, arbitration rules, evidence traces and risk signals — so regulated operations can prevent, explain and evidence compliant execution.

  • Prevent
  • Explain
  • Evidence
Explore the problem
01

The problem

Organisations rarely lack policies or controls. Controls sit outside the process — so the operating system can still allow the wrong action.

Controls sit outside execution

Policy and QA wrap the workflow instead of governing each step at the moment of action.

Compliance is interpreted

Staff and systems infer what is allowed from documents, training and judgement calls.

Protected states collide

Multiple obligations apply at once with no single arbitration view before execution.

Risk is detected late

Dashboards and breach reports surface problems after the fact, not before harm.

Evidence is reconstructed

Proof is assembled from logs and narratives, not captured at the gate.

Change creates hidden exposure

Process changes bypass controls until the next audit or incident.

02

Traditional vs COF

Same business outcome — fundamentally different control geometry.

Outside-in Traditional

Policy SOP Workflow Manual control QA / dashboard Breach report

Inside-out COF

Obligation State activation Clock / gate / arbitration Allowed / blocked / escalated Evidence · dashboard · simulation

Traditional compliance controls the process from the outside. COF governs execution from the inside.

03

Control Overlay X-Ray

Reveal where overlay controls fail — and where COF governs before harm.

Traditional

Policy
SOP
Workflow
Manual control
QA / dashboard
Breach report

COF

Obligation
State activation
Gate
Arbitration
Allowed / blocked / escalated
Trace
04

State Collision Playground

Select protections to see how multiple active states collide — and how arbitration picks a dominant path.

Select one or more chips to simulate overlapping protections.

05

Regulator Question Mode

Compare the answer regulators usually hear with the answer COF can evidence.

06

The COF pivot

Conventional

How do we add controls to this process?

COF

What obligations and states must govern execution before any process step is allowed?

07

What COF is

Three integrated layers — from design to execution.

1

Framework CGF

Defines the obligation, state and control model.

Risk · Compliance · Policy
2

Architecture REA

Connects the model to systems, workflow, data, decisioning and reporting.

Technology · EA · Engineering
3

Platform COP

Executes, simulates and evidences the control logic.

CRO · COO · Operations · Board

Extended collections narrative:

08

See it work — the simulator

The proof environment before COF is embedded in PCC, SM, Data Apps or your operational platform.

Prevention Wrong actions do not execute
Prediction Risk visible before breach
Proof Trace ready for audit

Load the guided case, run evaluation, try a demand letter — watch blocked outcomes with scoring, arbitration and regulator-ready trace.

Ready for technical depth?

Solution maps, state catalogues, live proof and reports sit in the tabs marked Technical proof. Developer runbooks are in the appendix.

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.

Evaluation “as of” date for this demo: 2026-03-15 (fixed so the story stays repeatable).

Case story

Pick a guided case and click Run evaluation.

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.

Open reports hub →

Technical appendix

Local run instructions, database configuration, and developer orientation for this demo environment.

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\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

  • Overview: Sales narrative, X-Ray, state collision playground, regulator Q&A, layers, simulator introduction.
  • Business depth: Extended marketing story with sub-tabs and collections examples.
  • Solution map: Diagrams for CGF → REA → COP and data flow.
  • State & gate logic: Business state definitions and live sample tables.
  • Live proof: Guided case, obligation scoring, gate verdict, arbitration, trace, SLA simulation.
  • Demo reports: Sample HTML reports under reporting/.
  • Config admin: Editable reference tables when auth is configured.