Zone-specific interface constraints in three-zone architectures
- The Monitor, Analyze, Plan, Execute, over shared Knowledge (MAPE-K) autonomic-computing loop specifies that raw monitored data must pass through a distinct Analyze stage before the shared Knowledge base or the Plan stage acts on it, so unfiltered sensor output never directly triggers a corrective actionKephart (2003)
- Blackboard architectures restrict every knowledge source to posting a candidate contribution rather than committing it directly, and a separate control shell component decides which candidate is applied to the shared blackboardCorkill (1991)
- The actor-critic reinforcement-learning architecture converts a raw environment transition into a scalar temporal-difference error before that signal is permitted to update the actor's policy parameters, keeping raw experience and consolidated feedback structurally distinctIncompleteideas (n.d.)
- The National Institute of Standards and Technology (NIST) Zero Trust Architecture separates the Policy Decision Point that evaluates access from the Policy Administration Point that executes the decision and the Policy Enforcement Point that touches the live connection, so no single component both decides and acts unilaterally on governed trafficNational (n.d.)
- GitOps reconciliation loops and Kubernetes admission-policy loops operate as two independently authoritative control loops over the same live cluster objects, with the policy loop able to veto or mutate any change regardless of whether it originated from the reconciler or another actorBugwadia (2024)
- Team Topologies formalises cross-team interface constraints through three named interaction modes, collaboration, X-as-a-Service, and facilitating, so that a platform team's internal work is never directly editable by a stream-aligned team and an enabling team's guidance is explicitly temporary rather than a standing control relationshipSkelton (n.d.)
- Sociotechnical systems theory establishes that a technical subsystem and a social subsystem must be jointly optimised rather than independently optimised, because improving one subsystem in isolation was empirically found to degrade the combined system's performance in the coal-mining case studies that originated the theoryNewcastle (n.d.)
- Across five independently sourced technical architectures, MAPE-K, blackboard systems, actor-critic reinforcement learning, Zero Trust, and GitOps/admission-policy loops, the recurring structural pattern is that a distinct resolution or decision component, not the execution environment and not the verification mechanism directly, holds sole write authority over the shared content poolKephart (2003)Corkill (1991)Incompleteideas (n.d.)National (n.d.)Bugwadia (2024)
Research Question
How do existing multi-layer architectures across systems engineering, cognitive science, organisational design, and related fields define interfaces and feedback pathways among a mediated content pool, an active execution environment, and independent verification mechanisms, and what interface constraints keep content, harness, and validation influence methods properly zone-specific?
Findings
(Populated from §6 Synthesis above.)
Executive Summary
The clearest interface constraint that recurs across systems engineering, artificial intelligence, reinforcement learning, and organisational-design literatures is asymmetric write access: every zone may read the shared content pool, but only a distinct resolution step, not the execution environment's raw output and not the verification mechanism's raw signal, is authorised to write into it. Five independently developed technical architectures, the Monitor-Analyze-Plan-Execute-over-shared-Knowledge (MAPE-K) autonomic-computing loop, blackboard artificial intelligence systems, actor-critic reinforcement learning, Zero Trust security architecture, and GitOps reconciliation paired with Kubernetes admission-policy control, converge on this same shape without citing one another. Two organisational-design frameworks, Team Topologies and sociotechnical systems theory, extend the same asymmetric-influence logic from technical systems to human team boundaries, and both add that the interface constraint must be jointly designed across technical and social dimensions to hold under real operating pressure. Verification can be positioned either before execution completes or after it completes without breaking the constraint, because the property being preserved is which component holds write authority over the pool, not the timing of verification. The strongest remaining gap is that this generalisation is this item's own synthesis across independently-sourced architectures rather than a claim stated directly by any single cited source.
Key Findings
- The Monitor, Analyze, Plan, Execute, over shared Knowledge (MAPE-K) autonomic-computing loop specifies that raw monitored data must pass through a distinct Analyze stage before the shared Knowledge base or the Plan stage acts on it, so unfiltered sensor output never directly triggers a corrective action.
- Blackboard architectures restrict every knowledge source to posting a candidate contribution rather than committing it directly, and a separate control shell component decides which candidate is applied to the shared blackboard.
- The actor-critic reinforcement-learning architecture converts a raw environment transition into a scalar temporal-difference error before that signal is permitted to update the actor's policy parameters, keeping raw experience and consolidated feedback structurally distinct.
- The National Institute of Standards and Technology (NIST) Zero Trust Architecture separates the Policy Decision Point that evaluates access from the Policy Administration Point that executes the decision and the Policy Enforcement Point that touches the live connection, so no single component both decides and acts unilaterally on governed traffic.
- GitOps reconciliation loops and Kubernetes admission-policy loops operate as two independently authoritative control loops over the same live cluster objects, with the policy loop able to veto or mutate any change regardless of whether it originated from the reconciler or another actor.
- Team Topologies formalises cross-team interface constraints through three named interaction modes, collaboration, X-as-a-Service, and facilitating, so that a platform team's internal work is never directly editable by a stream-aligned team and an enabling team's guidance is explicitly temporary rather than a standing control relationship.
- Sociotechnical systems theory establishes that a technical subsystem and a social subsystem must be jointly optimised rather than independently optimised, because improving one subsystem in isolation was empirically found to degrade the combined system's performance in the coal-mining case studies that originated the theory.
- Across five independently sourced technical architectures, MAPE-K, blackboard systems, actor-critic reinforcement learning, Zero Trust, and GitOps/admission-policy loops, the recurring structural pattern is that a distinct resolution or decision component, not the execution environment and not the verification mechanism directly, holds sole write authority over the shared content pool.
- Verification can be positioned either before execution completes (Zero Trust admission-style gating, Kubernetes admission policy) or after execution completes (MAPE-K Analyze, actor-critic TD-error computation), and both timing choices preserve the same asymmetric-write-access constraint even though the intervention point differs.
- The Universal Entity Lifecycle Governance Framework (UELGF) runtime feedback loop already implements the raw-signal-versus-resolved-lesson distinction found across the external literatures by separating individual Policy Enforcement Point signals from the aggregated, machine-readable structured demand signal that is permitted to modify governed rail specifications.
Assumptions
This synthesis assumes that architectures explicitly designed for machine systems (MAPE-K, actor-critic, Zero Trust, GitOps/admission control) transfer meaningfully to the three-zone model's mixed human-and-machine content, harness, and validation zones. The justification is that the prior control-plane-architecture item in this repository already established that Zero Trust's PDP/PEP/PAP decomposition applies successfully to Artificial Intelligence (AI) agent governance, so the transfer step from pure infrastructure to AI-agent-adjacent governance has repository precedent even though this item does not independently re-verify that transfer.
This synthesis assumes that "verification" in cognitive-science and reinforcement-learning contexts (a control shell, a critic) is functionally comparable to "verification" in the three-zone model's independent validation zone, despite the former typically running inside the same computational process as execution. The justification is that both sources describe the verification component as structurally distinct in its inputs, outputs, and update rule even when co-located in the same runtime, so process co-location does not by itself collapse the zone boundary that this item is investigating.
Analysis
The strongest evidence for a transferable interface constraint is the convergence of five independently developed technical architectures, spanning autonomic computing (2003), classical AI blackboard systems (1980s, formalised 1991), reinforcement learning (RL) theory (2018 edition of a much older tradition), Zero Trust security architecture (2020 standard), and modern cloud infrastructure (2024 blog post), on the same asymmetric-write-access shape without citing one another. A plausible rival explanation is that this apparent convergence is an artifact of selection: this item searched for architectures that already separate content, execution, and verification concerns, so finding that separation is unsurprising and does not prove the pattern is a fundamental property of well-designed systems rather than a property of the search criteria used. This rival explanation is only partly resolved. The technical architectures were selected for relevance, but the organisational-design sources (Team Topologies, sociotechnical systems theory) were selected independently for a different reason (cross-domain applicability) and still exhibit the same pattern. This weakens the pure selection-artifact explanation without eliminating it, because both organisational sources were themselves selected for already describing team or subsystem boundaries.
The verification-timing tension identified in §4 (pre-execution gating in Zero Trust and GitOps admission control versus post-execution evaluation in MAPE-K and actor-critic) is best read as a genuine design trade-off rather than an inconsistency in the underlying pattern: pre-execution gating trades latency for certainty (nothing unauthorised ever executes), while post-execution evaluation trades certainty for lower latency and richer signal (the verifier can evaluate a completed action's actual consequences rather than only its declared intent). Both positions are compatible with the three-zone model because the constraint being preserved is which component holds write authority over the content pool, not when in the execution timeline verification occurs.
A prior repository item on hybrid architecture design reaches a compatible conclusion from a different starting question: it argues for pairing a probabilistic Large Language Model (LLM) interpretation layer with a deterministic governance-enforcement layer specifically because the deterministic layer's enforcement decision must not be produced by the same probabilistic process it is meant to check. That prior finding is a special case of the asymmetric-write-access pattern identified here: the probabilistic layer is the execution zone, the deterministic layer is the verification zone, and the item's rationale for keeping them structurally separate mirrors the same reasoning found in Zero Trust's PDP/PEP/PAP split and in the actor-critic architecture's separation of policy and critic.
Risks, Gaps, and Uncertainties
- The GitOps/admission-policy evidence rests on a single secondary practitioner source (a Cloud Native Computing Foundation (CNCF) blog post by a Kyverno maintainer); no independent academic or standards-body source was located that makes the same reconciliation-loop-versus-policy-loop distinction explicitly, so this finding is held at medium rather than high confidence.
- The Team Topologies finding is sourced from Martin Fowler's secondary summary rather than the original Skelton and Pais book; the summary was treated as accurately representing the book's model, but nuances of the book's own worked examples were not independently checked.
- The cross-cutting "asymmetric write access" generalisation (Key Finding 8) is this item's own synthesis across five sources; no single cited source states the generalisation directly, so it should be treated as this item's interpretive contribution rather than an established fact in any one field.
- This item did not locate or examine a primary cognitive-architecture source beyond blackboard systems (for example ACT-R or Soar); the Approach's reference to "cognitive science" is therefore represented only by the blackboard tradition. The blackboard architecture originated in artificial intelligence research on knowledge-based systems (the Hearsay-II speech-understanding system) rather than in psychology proper, so a fuller cognitive-science comparison (dual-process theory, global workspace theory) remains a gap.
- A search for a freely accessible primary text of Hayes-Roth's 1985 "A Blackboard Architecture for Control" (Artificial Intelligence journal) using the query "A Blackboard Architecture for Control Hayes-Roth 1985 Artificial Intelligence journal pdf free access" returned no accessible result; Corkill's 1991 secondary account was used instead and is clearly attributed as such throughout this item.
Open Questions
- How should the resolution step that grants write access to the content pool itself be governed, who decides what counts as a valid resolution, and does that decision require its own further verification layer, risking infinite regress?
- What quantitative latency and throughput trade-offs distinguish pre-execution gating from post-execution evaluation in production-scale systems, beyond the qualitative trade-off identified in this item's Analysis?
- Does the sociotechnical systems theory's joint-optimisation requirement imply a specific organisational role or accountability structure for a three-zone architecture's interface boundaries, and if so, what would that role's mandate look like in an enterprise governance context?
- Would a direct comparison against ACT-R or Soar cognitive architectures (not investigated in this item) surface interface constraints not present in the blackboard tradition, given that both explicitly separate declarative memory, procedural memory, and a conflict-resolution mechanism?
sources
- [x] GitHub issue #653: Four research questions - canonical statement of the research request and the integrative framing
- [x] Aligned Decision-Making: Context Architecture for AI Agents in Organisations - prior repository item on layered context and decision interfaces
- [x] Layered reasoning stack interfaces: state abstraction and Large Language Model (LLM) ↔ Energy-Based Model (EBM) protocols - prior repository item on interface contracts between distinct reasoning layers
- [x] What control-plane architecture is required to manage Artificial Intelligence (AI) agents and low-code systems as distributed, semi-autonomous actors within enterprise environments? - prior repository item on layered governance and control planes; established the National Institute of Standards and Technology (NIST) Zero Trust Policy Decision Point / Policy Enforcement Point / Policy Administration Point decomposition reused here
- [x] Universal Entity Lifecycle Governance Framework (UELGF): policy architecture, Policy Administration Point, Policy Decision Point, Policy Enforcement Point, Policy Information Point component design, the 8-layer organisational context model, policy independence guarantee, scope boundary mechanism, and kill switch - prior repository item with explicit layer boundaries and policy-independence constraints
- [x] Universal Entity Lifecycle Governance Framework (UELGF): runtime feedback loop, signal taxonomy, automated response taxonomy, feedback closure to the rail system, and feedback closure to the systems capability debt programme - prior repository item distinguishing raw runtime signal from resolved, structured feedback
- [x] Hybrid Architecture Design: Probabilistic Large Language Models (LLMs) for Interpretation, Deterministic Layers for Governance Enforcement - prior repository item arguing that a deterministic enforcement layer must stay structurally separate from the probabilistic layer it checks
- [x] Kephart, J.O. and Chess, D.M. (2003) "The Vision of Autonomic Computing" - primary source defining the Monitor, Analyze, Plan, Execute, over shared Knowledge (MAPE-K) autonomic-computing reference architecture
- [x] Corkill, D.D. (1991) "Blackboard Systems" - authoritative secondary source on blackboard architecture: knowledge sources, shared blackboard, and an independent control shell
- [x] Sutton, R.S. and Barto, A.G. (2018) "Reinforcement Learning: An Introduction" (2nd ed.) - primary textbook source for the actor-critic architecture and the distinction between raw experience replay and consolidated temporal-difference feedback
- [x] National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 - Zero Trust Architecture - primary source for the Policy Decision Point (PDP) / Policy Enforcement Point (PEP) / Policy Administration Point (PAP) separation and the control-plane/data-plane split
- [x] Bugwadia, J. (2024) "GitOps and mutating policies: the tale of two loops" - Cloud Native Computing Foundation (CNCF) blog post distinguishing the GitOps reconciliation control loop from the admission-time policy control loop
- [x] Skelton, M. and Pais, M. - "Team Topologies" summarised by Martin Fowler - secondary source on the four team types and three interaction modes (collaboration, X-as-a-Service, facilitating) that formalise cross-team interface contracts
- [x] Newcastle University TheoryHub - "Socio-Technical Theory" (Trist and Bamforth) - secondary academic source on joint optimisation of technical and social subsystems
| version | date | commit | summary |
|---|---|---|---|
| 1.0 | 2026-09-15 | a2e3e9e | Initial completion |