Two competing approaches

This doc compares two architectural approaches to modeling and computing entertainment deals:

• Deal Engine (deal-type programs + governed models): deal types are implemented as versioned programs/services; instances are data; compute is deterministic and auditable; contingent tracking uses event/evidence services.
• State Machine system (clause-block + spreadsheet-like engine): deals are containers of versions; working versions hold inputs/states/clauses and calculation strings; dependency graph recalculates reactively; submitted versions are immutable.

The goal here is not to “pick a winner” in the abstract. It’s to surface what each approach optimizes for, what it risks, and where hybridization is realistic.

Summary comparison

Where each approach shines

Deal Engine is strongest when you need:

• finance-grade determinism and replay (years later)
• uniform integration with Client Processing (obligation identity, deltas, baselines)
• governed evolution (versioning, migrations, fixtures, canary rollout)
• consistent cross-deal analytics and comparability
• long-running contingent tracking with evidence sources, adapters, watches, and overrides

State Machine is strongest when you need:

• a spreadsheet-like, reactive authoring experience (“as I type, everything recalcs”)
• easy branching (“working” versions) for multiple what-if scenarios
• transparent overrides (preserve user values while showing calculated values)
• clause-block composition that naturally matches touring “per show + tour summary” structures

The key architectural difference

The Deal Engine approach keeps business logic in versioned models/programs and keeps deal instances as pure data.

The State Machine approach, as currently written, keeps significant logic inside the deal/version as expression strings.

That difference is the main driver of governance, determinism, and operational safety trade-offs.

The Deal Engine approach (deal-type programs + governed models)

Core idea

• A deal type is defined by a versioned model/program (schema + behavior).
• A deal instance stores inputs and immutable revisions.
• The runtime computes snapshots deterministically (inputs + evidence + model hash → outputs/obligations).
• Contingent tracking is handled via a dedicated event/evidence/watch architecture.
• Client Processing relies on stable obligation keys and explicit deltas, including amendments vs corrections.

Why this fits finance-grade operations

• Determinism: no wall-clock time in compute; evidence and FX are part of the snapshot.
• Auditability: snapshots and traces are immutable and replayable.
• Governance: model versions ship with fixtures; breaking changes require migrations; canary rollout reduces blast radius.
• CP safety: baseline pinning + deltas prevent silent retroactive obligation changes.

Costs / downsides

• More upfront “platform” work (registry, runtime, evidence service, projections, etc.).
• Authoring is harder unless you invest in good UX and strong LLM-assisted tooling.
• You must maintain primitive catalogs and compatibility rules carefully.

The State Machine approach (clause blocks + reactive engine)

Core idea

• A deal contains many versions (working/submitted).
• A version contains clause blocks. Each block contains:
  • inputs (user/sourced data)
  • states (calculated values with statuses)
  • clauses (financial obligations) with triggers and calculations
• An expression parser builds a dependency graph; changes trigger incremental recompute.
• Override status preserves user-entered values but still calculates a “would-be” value.

Why it feels compelling to users

• Interactive: immediate recalculation as inputs change.
• Branching: multiple working versions capture what-ifs naturally.
• Override: transparent difference between manual estimate and calculated value.
• Touring fit: per-show blocks plus summary aggregation maps well to real workflows.

Costs / downsides

• Without strong constraints, it becomes “a programming language in every deal.”
• It is easy to get semantic drift (100 slightly different NBOR formulas).
• Long-running contingent tracking requires substantial additional architecture not defined in the proposal.

Key risks and gaps in the State Machine spec (as written)

1) “Calculations run only in working versions” breaks real-world processing

If submitted versions never compute, then:

• obligations can’t change as evidence arrives
• long-running deals can’t produce updated obligations over time
• CP cannot rely on the model for ongoing receivables

A finance-grade system needs immutable versions but recomputable snapshots over time.

2) today() breaks determinism

The expression language includes today(). If this reads wall-clock time:

• replay becomes impossible
• outputs change depending on when recompute occurs

A deterministic system must use an explicit asOf time.

3) Non-blocking error handling is unsafe for CP paths

“Preserve previous value on error” can be acceptable in draft UX. It is not acceptable when CP will invoice/pay based on results.

You need a strict policy:

• draft mode: tolerate errors
• CP-reliant mode: error blocks obligation generation

4) Money and FX are underspecified and currently unsafe

The JSON schemas use numeric types for amounts and variables. That implies floating point. For finance-grade operations you need:

• decimal strings or a Money object { amount: "…", currency: "…" }
• explicit rounding and FX determinism

5) Event/evidence architecture is missing

Contingent compensation in the enterprise requires:

• evidence sources + schema versioning adapters
• watches + polling/timers + dormancy
• manual override + dispute handling
• provenance and audit trails

The state machine proposal references internal “statuses,” but does not define a durable evidence system.

6) Governance and comparability degrade if logic lives in instances

If each deal version includes custom calculations:

• you lose standardized semantics across deals
• analytics becomes “computed outputs only” with no semantic comparability
• fixes become “N instances edited” instead of “one model upgraded with migration”

If this approach is pursued, it needs:

• a governed, versioned clause library
• strict expression language constraints
• fixture requirements that apply to libraries, not per-deal expressions

7) Performance will be unpredictable without bounded evaluation

Dependency graphs and incremental recompute are great, but only if:

• graphs are compiled and cached (not rebuilt from scratch on every edit)
• expression complexity is bounded
• cross-deal reads are disallowed or tightly controlled

Otherwise, interactive latency will degrade quickly as deals scale.

What the State Machine approach gets right (and Deal Engine should steal)

Branching UX and override transparency

• Working versions as what-if branches is a strong mental model.
• Override that preserves user value and shows “calculated_value” builds trust.

This can be layered on top of a governed model system by:

• treating “working versions” as drafts
• treating overrides as explicit, audited values (with computed comparison)

Clause-block composition for touring

• A “show block” repeated N times + a summary block is natural.
• Aggregations across blocks are a must-have UX feature.

In Deal Engine terms, this is best expressed as:

• reusable templates / clause-block macros inside the model
• repeated instances with stable identifiers for obligationKey generation

Validation on submit

Their validation checklist (references, cycles, required inputs, cross-deal reference pinning) is good. A governed system should incorporate these checks as part of authoring-time validation.

A realistic hybrid (if you want “best of both worlds”)

Use State Machine as authoring UX, not as the authoritative semantics

A safe hybrid is:

• Authoring UI feels like the State Machine:
  • clause blocks
  • states and inputs
  • overrides
  • branching what-ifs
  • incremental recalculation for feedback
• Under the hood:
  • calculations compile to a typed IR constrained by a primitive catalog
  • the authoritative semantics live in versioned models/programs
  • snapshots are deterministic and replayable
  • evidence/watches/CP deltas follow the finance-grade architecture

This preserves:

• user delight and interactive speed
• operational safety
• analytics comparability
• multi-year contingent tracking

Non-negotiables for any hybrid

• explicit money/FX determinism
• evidence provenance and adapters
• obligation identity and CP delta semantics
• determinism (no wall-clock) and replay
• governance gates with fixtures and canary rollout

Recommendation framing for stakeholders

If the core objective is “interactive UX and flexibility,” the State Machine direction is promising as a UI and drafting layer.

If the core objective is “enterprise-grade correctness and longevity,” Deal Engine’s governed models and evidence/CP architecture remain the better backbone.

The right path is likely:

• keep Deal Engine as the backbone
• adopt State Machine patterns where they improve authoring experience and transparency
• prohibit instance-defined arbitrary expressions from becoming the canonical, deployed semantics unless they compile into governed libraries with tests and versioning.