Three-Layer Dependency Framework
- The framework formalizes composition by delineating function, expected behavior, and structure across top-level model and subcomponent layers.
- It employs formal propagation maps, consistency checks, and distributive laws to ensure acyclic dependency and precise constraint reformulation.
- Applications span engineering design, evidence synthesis, and software architecture, offering modularity and robust automation in system development.
The Three-Layer Dependency Framework formalizes system composition, modular inference, and multi-effect programming by strictly isolating concerns into three interacting layers. The approach recurs in engineering, evidence synthesis, software architecture, and semantics. Each instantiation enforces clear downward inheritance, cycle-free cross-layer dependencies, and precise criteria for propagation, consolidation, and reformulation of constraints, whether functional, methodological, or algebraic.
1. Formal Layer Definitions and Interaction Modalities
In design theory, the framework emerges via layered instances of John Gero’s @@@@2@@@@ (Function–Behaviour–Structure) model (Diertens, 2015). Each layer specifies:
- Function (): requirements to be realized
- Expected Behaviour (): behavioral anticipation given
- Structure (): components and interrelations designed to instantiate
- Structure Behaviour (): actual behavior resulting from
- Description (): complete documentation of
Three layers—top-level model and two subcomponents—are composed so that functions, behaviours, and structures propagate via formal maps, e.g., (function decomposition), upward reformulation maps (, ), and documentation integration (). Only abstracted methodological insight is permitted to flow upward; all other information transmission is strictly downward or inherited.
Similarly, in evidence synthesis, the RECAP architecture defines Grandparent (methodological laws), Parent (domain abstraction), and Child (project implementation) layers. Each layer inherits immutable constraints from above and provides auditable, context-specific reasoning below (Lee, 10 Dec 2025).
In programming language semantics, the framework manifests as a sequence of monads capturing layered computational effects. Each layer embodies a monad: base imperative computations, nondeterminism, and probabilistic choice. Layer composition is governed by distributive laws; algebraic obstacles determine the best-approximation strategy (Dahlqvist et al., 2017).
2. Dependency Propagation, Reformulation, and Consistency
Design propagation is a staged process. At the top layer, function maps to expected behaviour, synthesized into structure, analyzed for actual behaviour, and iteratively evaluated. Once stable, decomposition provides sub-component functions and requirements:
- Stepwise propagation:
- Decomposition: for Layer 1 and Layer 2
- Each sub-layer executes parallel FBS processes (), with mismatch handling via local reformulation or upward triggers (if requirements inherited from parent are affected)
RECAP formalizes these rules as auditable functions for tiering (assignment to Core/Supplement/Excluded), routing (committing to exactly one inferential route per project), and contamination control (strict governance of cross-layer and cross-project leakage).
Tabular summary of propagation operators:
| Layer | Decomposition Map | Upward Reformulation | Documentation Integration |
|---|---|---|---|
| Top | |||
| Component | local , , |
Consistency is guaranteed by enforcing that any sub-framework reformulation affecting parent-inherited requirements must occur in the parent layer, and if a sub-structure cannot achieve required behaviour locally, a parent-level reformulation is triggered. RECAP’s dependency-graph constraint (no-cycle property) ensures acyclic, well-founded inheritance.
3. Formal Separation Criteria and Interface Governance
In three-tier software systems, the framework is concretized by enforcing strict language-purity (no SQL/HTML fragments directly embedded in Java, and vice versa), layer-independence (orthogonal modification of GUI, server, or database), strong interface contracts (XML-based specification of bean and operation interfaces), and code-generation facilities (Sadikov et al., 2014). Each interface is described in DSL-form and used to generate plumbing code, isolating cross-tier control flow and data exchange.
Formally, the system is modeled as a DAG :
- : GUI/Front-end
- : Application Server
- : Database
Edges only permit downward traversal (). Only interface contracts specified in compiled DSLs bridge layer boundaries.
Code examples demonstrate the transition from mixed-language, tightly coupled code to completely separated, auto-generated stubs, wrappers, and templates, supporting parallel development and robust maintenance practices.
4. Algebraic Layering and Distributive Laws
In categorical semantics, each language layer corresponds to a monad on Set:
- : Free monoid (imperative sequencing)
- : Finite powerset (nondeterminism)
- : Finitely-supported distributions (probabilistic choice)
Compositionality requires distributive laws, e.g., , proven to exist for nondeterminism over sequencing. Algebraic obstacles arise in extending nondeterminism by probability: distributive law fails due to non-preservation of idempotency and distributivity, traced to residual diagrams which do not commute. The “best approximant” method selects a quotient theory () discarding conflicting axioms, yielding a composite monad with sequential, nondeterministic, and probabilistic effects but without idempotency or cross-distributivity (Dahlqvist et al., 2017).
Comparison with ProbNetKAT shows the best approximant aligns structurally with its -free, test-free fragment, justifying specific algebraic choices from the failure of distributive laws.
Criteria for compositionality:
| Monad property | Implies | Layering outcome |
|---|---|---|
| Commutativity | Exchange | Admits distributive law for sequencing |
| Relevance | Weakening | Permits variable duplication |
| Affineness | Contraction | Permits variable deletion |
5. Meta-Governance, Automation, and Limitations
RECAP’s meta-architecture imposes governance at every layer: Grandparent (constitutional laws) are immutable below, Parent translates these laws concretely for a domain, and Child executes project-level routing and tiering, always versioned, logged, and audited. Automation is facilitated by explicit rule systems, dependency graphs, and versioned corrections for contamination events (Lee, 10 Dec 2025).
Limitations include added overhead for standalone projects, reliance on precise construct definitions (tiering cannot operate without them), potential reduction to checklist compliance, and risks in partial or inconsistent adoption. Notably, three-layer frameworks do not govern statistical models, effect-size interpretations, or domain estimates—only the structure and flow of reasoning and dependencies.
6. Applications Across Domains and Design Implications
Three-layer frameworks are applied in:
- Modular system design via FBS composition (engineering, product architecture)
- Evidence synthesis meta-architecture (methodological stability, reproducibility in research ecosystems)
- Clean separation of application, business logic, and data persistence (enterprise software)
- Layered programming-language semantics via distributive laws and monadic combinators
Across domains, benefits include modularity, lower maintenance, propagation of global constraints, prevention of drift or contamination, and support for cumulative infrastructure and automation.
A plausible implication is that, as systems increase in complexity, well-defined three-layer dependency structures offer a scalable foundation for cumulative reasoning, formal governance, and resilient modular composition. However, achieving full separation and inheritance discipline necessitates rigorous interface definition, auditable processes, and formal acyclicity constraints at all levels.