The TDD Cascade for Business Operations
The Organizational Schema Theory applies Test-Driven Development to business operations. Designed top-down from customer experience. Validated bottom-up through CI/CD.
The Six-Level TDD Cascade
Every business can be decomposed into six specification levels. Each level is a test suite that validates the level below it. Design flows downward (what should the customer experience?). Validation flows upward (does this sourcing decision satisfy the input spec?).
What customers should perceive and feel. Three contract types: experience (customer-derived), constraint (regulation/law), commitment (self-imposed values).
What signals the business must emit to create the desired perception. Uses Spectral Brand Theory's 8 dimensions as the specification language.
What processes must achieve to emit the required signals. Contracts define outcomes, not methods. Executor-invariant.
How a specific executor achieves the contract. Different executors (human, machine, hybrid) have different procedures for the same contract.
Materials, equipment, training, and other inputs required by procedures. Each input traces upward to the contract it serves.
Supply chain specifications. Where inputs come from, quality criteria, supplier requirements. The foundation of the cascade.
Contract-Procedure Separation
The core TDD principle: contracts (tests) don't change when you swap the executor (implementation). An espresso must extract between 25-30 seconds regardless of whether a human barista or an automated machine pulls the shot. The contract is the same. The procedure differs.
In the Spectra Coffee demo — a synthesized specialty coffee shop used as the reference implementation — approximately 75% of the specification is executor-invariant. Only L3 (procedures) changes when you swap executor type. This is why businesses specified in orgschema are forkable: copy the test suite, rewrite the implementation.
Executor Topology
Every process contract can be executed by one of three executor types:
| Executor | Signal Mode | Key Property |
|---|---|---|
| Machine | Reproduction | Spec-faithful. Emits L1 signals exactly as specified. No secondary signals. |
| Human | Reprocessing | Renders through personal priors. Emits secondary analogue signals (unspecifiable). The human premium. |
| Hybrid | Mixed | Machine handles precision; human handles judgment. L1/L2 gap management. |
Quality control is L1-L2 gap management: the difference between the signal specified (L1) and the signal actually produced (L2). Machine executors minimize the gap. Human executors create surplus value in the gap.
Three L0 Contract Types
Not all acceptance tests come from customers. The top level has three distinct contract sources:
| Type | Source | Example |
|---|---|---|
| Experience | Desired customer perception | "Customers should perceive craft expertise and attention to detail" |
| Constraint | Regulation, law, standards | "Food safety temperature logs maintained per EU 852/2004" |
| Commitment | Self-imposed organizational values | "All coffee sourced from farms with living wage certification" |
Regulation is a first-class acceptance test, not waste. Compliance is a feature, not overhead.
CI/CD as Satisfaction Validation
The orgschema validation pipeline runs six levels of checks, from syntax to business satisfaction:
- Schema validation — syntax correctness (does the YAML parse?)
- Cross-reference integrity — imports resolve (do referenced files exist?)
- Contract satisfaction — unit tests (does each process satisfy its contract?)
- Signal coverage — integration tests (are all required signals produced?)
- Experience traceability — acceptance tests (does every parameter trace to an L0 goal?)
- Waste detection — dead code (are there processes with no upward trace?)
Observer-Agnostic Design
The TDD cascade does not require the customer to be human. When the customer is a machine (an API consumer, a procurement algorithm, an AI shopping agent), L0 becomes a formal specification and L1 collapses — the signal IS the specification. No perception gap to model.
| Customer Type | L0 Character | L1 Character | Perception Layer |
|---|---|---|---|
| Human | Perceptual target (fuzzy) | 8 SBT dimensions | Full SBT analysis |
| Hybrid | Spec + perception | Functional translation | AI translates perceptual desires into functional parameters |
| Machine | Formal specification | Collapses into L0 | Dimensions become functional parameters directly |
L2-L5 are customer-type-invariant. The same process contracts, procedures, inputs, and sourcing serve all customer types. For hybrid customers (the most common case), the machine narrows and the human decides.
Connection to Spectral Brand Theory
Organizational Schema Theory uses Spectral Brand Theory as its perception layer. SBT's 8 perceptual dimensions become the specification language for L0 (what should customers perceive?) and L1 (what signals produce that perception?). SBT is the external view (observer-dependent perception). Organizational Schema Theory is the internal view (operator-dependent specification). Neither is complete alone.