Specification-Driven Development (SDD) and Data-Driven Design converge on a single architectural principle: separation of behavioral specification from stateful execution. Both paradigms relocate mutable state outside the primary logic modules, treating state as an external resource managed by a dedicated shell. The specification defines what the system must compute, while the implementation processes data streams without retaining internal state.
This separation yields three measurable properties:
FCIS partitions a system into two layers with strict dependency direction (shell → core).
| Layer | Responsibility | State Interaction |
|---|---|---|
| Functional Core | Pure business logic transformations | Zero internal state; operates on passed data |
| Imperative Shell | Side effects (I/O, persistence, network) | Manages external state stores |
The core receives data, computes results, and returns outputs. The shell fetches state, invokes core functions, and applies side effects. Unit testing the core requires no mocks; integration testing the shell verifies orchestration correctness.
DOP treats data as immutable, generic structures separate from behavior. Functions operate on collections rather than encapsulated objects. This aligns with FCIS by ensuring logic modules receive complete state snapshots rather than references to mutable entities.
Hexagonal Architecture generalizes FCIS to system boundaries. Ports define abstract interfaces for external interactions. Adapters implement ports with concrete technologies. The core remains agnostic to infrastructure, enabling specification-to-code generation from port definitions alone.
Contemporary SDD toolchains explicitly model the separation of current state and proposed changes.
OpenSpec structures repositories into:
specs/: Versioned snapshots of current system specification (state).changes/: Proposed modifications to the specification (actions).This mirrors FCIS at the project management level: specs/ is the current state, changes/ are inputs to a transformation process that yields updated specifications.
BMAD enforces three specification layers as machine-readable contracts:
| Layer | Format | Purpose |
|---|---|---|
| API | OpenAPI | Interface boundaries |
| Data | JSON Schema | Structural constraints |
| Behavior | Gherkin | Functional scenarios |
AI agents generate implementation code that conforms to these contracts. The contracts contain no implementation state, enabling deterministic verification.
Systems like Specwork and Spryker encode workflow logic as state machine definitions stored in databases or configuration files. The execution engine (core) computes next actions from current state and event inputs; the agent runtime (shell) performs side effects. Workflow modifications require only data updates, not code redeployment.
From Event Sourcing, the Decider pattern expresses business logic as three pure functions:
decide: (command: Command, state: State) => Event[]
evolve: (state: State, event: Event) => State
initialState: () => State
State resides entirely outside the functions, passed as immutable arguments. This pattern guarantees deterministic replay and simplifies testing.
An orchestrator layer within the Imperative Shell composes core function calls to fulfill use cases. It manages transactional boundaries, fetches state from repositories, and persists results. The orchestrator contains no business logic, only coordination.
Event Sourcing persists state changes as an append-only event log. Current state derives from folding events through evolve. This architecture treats the event log as the single source of truth and enables temporal querying.
Game development adopted data-driven design in the 1990s, preceding formal SDD by decades. The motivation differed (performance and designer iteration speed), yet the resulting structures are isomorphic to modern SDD principles.
ECS separates game objects into three orthogonal concerns:
| Element | Definition | Equivalent in FCIS |
|---|---|---|
| Entity | Identifier (integer) | Reference token |
| Component | Pure data (position, health) | External state |
| System | Pure logic operating on component sets | Functional Core |
Systems iterate over component archetypes stored in contiguous memory (SoA layout). This design enables deterministic lockstep networking and hot-reloading of game logic.
Game engines (e.g., Hiro, Space Station 14) define entity behaviors in YAML/JSON prototypes. Designers modify these data files to adjust balance, spawn patterns, and visual effects without recompilation. The engine (core) interprets configuration (specification) and drives runtime behavior.
Multiplayer games require identical simulation across clients. ECS achieves determinism by:
This mirrors SDD requirements for reproducible builds from versioned specifications.
The affinity between SDD and data-driven design creates a self-reinforcing loop:
Deep Coding and similar methodologies exploit this affinity. The human role compresses to:
AI handles:
The approach scales to large codebases because context windows contain only the specification, not the full implementation.
Specification-Driven Development and Data-Driven Design share a foundational commitment to separating behavioral specification from stateful execution. This separation manifests architecturally as Functional Core / Imperative Shell, ECS, and Hexagonal Architecture. The gaming industry provides empirical validation of these principles across decades of production use under stringent performance and determinism requirements. The affinity between the two paradigms enables AI-assisted development workflows where specification artifacts serve as both human-readable contracts and machine-executable data, reducing context requirements and increasing generation precision.