Repository navigation
2026 08 20 three zone interface feedback constraints
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?
In scope:
- Frameworks that explicitly separate knowledge or content layers, execution or work layers, and assurance, control, or evaluation layers
- Interface rules for how material moves from a mediated pool into active work, and how verification signals or resolved lessons flow back
- Comparative extraction of feedback-path constraints, state-boundary rules, and anti-leakage principles that preserve zone-specific responsibilities
- Transferable design principles from systems engineering, cognitive science, organisational design, and adjacent architecture literatures
Out of scope:
- Designing a vendor-specific implementation blueprint for one platform
- Evaluating one zone's internal techniques in isolation except where needed to clarify interface behavior
- Domain-specific governance policies whose validity depends on one application context
Constraints: Focus on architectures with explicit boundary definitions and reusable interface logic. Distinguish raw feedback signals from resolved lessons, and prioritise frameworks that make it possible to stress-test whether content, harness, and validation methods stay confined to the correct zone.
This item informs whether the three-zone model is structurally coherent, where the interfaces should sit, and what feedback rules are needed to preserve zone-specific leverage while still allowing useful learning across layers.
- Aligned Decision-Making: Context Architecture for Artificial Intelligence (AI) Agents in Organisations
- Layered reasoning stack interfaces: state abstraction and Large Language Model (LLM) ↔ Energy-Based Model (EBM) protocols
- What control-plane architecture is required to manage Artificial Intelligence (AI) agents and low-code systems as distributed, semi-autonomous actors within enterprise environments?
- Identify reference architectures that separate content, execution, and verification or control concerns across the target literatures.
- Extract the interface contracts that govern pool-to-execution transfer, verification-to-execution feedback, and verification-to-pool learning.
- Compare how each architecture constrains cross-zone influence, escalation, and boundary leakage.
- Evaluate what kinds of feedback should remain raw signals versus what should only re-enter the content pool after resolution or consolidation.
- Synthesize a transferable set of interface constraints and feedback rules for stress-testing the three-zone model.
- GitHub issue #653: Four research questions - canonical statement of the research request and the integrative framing
- Aligned Decision-Making: Context Architecture for AI Agents in Organisations - prior repository item on layered context and decision interfaces
- 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
- 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
- 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
- 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
- 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
- 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
- Corkill, D.D. (1991) "Blackboard Systems" - authoritative secondary source on blackboard architecture: knowledge sources, shared blackboard, and an independent control shell
- 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
- 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
- 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
- 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
- Newcastle University TheoryHub - "Socio-Technical Theory" (Trist and Bamforth) - secondary academic source on joint optimisation of technical and social subsystems
(Full output from running the research skill - retained verbatim in the completed item. §§0–5 are the investigation; §6 seeds the Findings section below.)
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? Scope: in scope are architectures with explicit boundary definitions and reusable interface logic that separate a knowledge/content layer, an execution/work layer, and an assurance/control/evaluation layer; out of scope is a vendor-specific implementation blueprint, single-zone internal technique evaluation, and application-specific governance policy. Constraints: prioritise frameworks that distinguish raw feedback signals from resolved lessons and that make cross-zone leakage testable. Prior repository work: three items are cited directly. [fact; source: https://davidamitchell.github.io/Research/research/2026-03-15-context-layers-aligned-decisions-synthesis.html] "Aligned Decision-Making" separates a context/knowledge layer from a decision layer in AI agent architectures for organisations. [fact; source: https://davidamitchell.github.io/Research/research/2026-05-17-layered-reasoning-state-abstraction-interfaces.html] "Layered reasoning stack interfaces" defines state-abstraction interface contracts between a generative Large Language Model (LLM) layer and an Energy-Based Model (EBM) evaluation layer, treating the abstraction boundary itself as the object of design. [fact; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-control-plane-architecture-enterprise.html] "AI agent control plane architecture for enterprise" adopts the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207 Zero Trust separation of a Policy Decision Point (PDP), Policy Enforcement Point (PEP), and Policy Administration Point (PAP), and defines a control-plane feedback loop distinct from the data plane it governs. Two further Universal Entity Lifecycle Governance Framework (UELGF) items are directly relevant: the policy-architecture item is thematically related but not directly cited, while the runtime-feedback-loop item is cited directly. [fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html] The UELGF policy-architecture item specifies PAP, PDP, PEP, and a fourth Policy Information Point (PIP) component, plus a policy-independence guarantee that keeps policy evaluation separated from the entities it governs. [fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html] The UELGF runtime-feedback-loop item already distinguishes raw Policy Enforcement Point signals from a resolved, machine-readable structured demand signal that re-enters governed rail specifications, which is the same raw-signal-versus-resolved-lesson distinction this item generalises across other literatures.
- Content-pool-to-execution interface 1a. What determines which content-pool material an execution environment is permitted to draw on, and how is that transfer contract expressed? 1b. What prevents an execution environment from writing directly back into the content pool without passing through a resolution step?
- Verification-to-execution feedback 2a. What is the minimal unit of feedback verification returns to execution (a scalar signal, a diagnosis, a denial), and how does that differ from the execution environment's raw output? 2b. What latency or intervention pattern do verification mechanisms use to influence execution in-flight versus after the fact?
- Verification-to-pool learning 3a. What consolidation step separates a raw verification signal from a lesson that is allowed to modify the content pool? 3b. What governs how repeated verification signals escalate from local correction to structural change in the pool?
- Cross-zone anti-leakage principles 4a. What structural mechanism (not merely a convention) stops one zone's raw output from acting as another zone's authoritative input? 4b. Is the anti-leakage mechanism symmetric across all three zone-pairs, or asymmetric (e.g., read access permitted, write access restricted)?
- Transferable interface constraints 5a. Which constraints recur across systems engineering, cognitive-architecture, reinforcement learning, and organisational-design examples, and which are field-specific?
- [fact; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf] Kephart and Chess's 2003 "Vision of Autonomic Computing" defines the Monitor-Analyze-Plan-Execute-over-shared-Knowledge (MAPE-K) loop as the reference architecture for self-managing systems: an autonomic manager continuously monitors a managed element, analyzes the monitored data against stored models to detect symptoms, plans a corrective or adaptive action, and executes that action through effectors, with all four functions reading from and writing to one shared knowledge base.
- [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf] The MAPE-K structure enforces a zone-specific interface because Monitor output (raw sensor and log data) is not itself an actionable plan; it must pass through Analyze, which classifies the data against stored models before Plan can act, so the knowledge base only receives a diagnosed symptom, not the unfiltered stream.
- [fact; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf] Kephart and Chess distinguish the "Managed Element" (the system component being governed) from the "Autonomic Manager" (the controller running the MAPE-K loop), keeping the governed execution environment and the governing control loop as separate architectural entities connected only through defined sensor and effector interfaces.
- [fact; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] Corkill's 1991 "Blackboard Systems" describes blackboard architectures as composed of independent knowledge sources (KSs), a shared blackboard data structure that holds the evolving partial solution, and a control shell that decides which knowledge source is allowed to act next based on the blackboard's current state.
- [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] The control shell is the interface-enforcing zone in this architecture: a knowledge source cannot unilaterally commit its proposed contribution to the blackboard; it can only post a candidate action, and the control shell schedules which candidate is applied, which keeps individual knowledge sources (execution-like contributors) from directly overriding the shared content pool.
- [fact; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] The canonical example architecture, Hearsay-II, applied this pattern to speech understanding, where acoustic, lexical, and syntactic knowledge sources each read and wrote to the shared blackboard but were arbitrated by a separate scheduling component rather than communicating directly with one another.
- [fact; source: http://incompleteideas.net/book/the-book-2nd.html] Sutton and Barto's "Reinforcement Learning: An Introduction" (2nd edition, 2018) defines the actor-critic architecture as a policy component (the actor, which selects actions) paired with a value-estimating component (the critic), where the critic computes a temporal-difference (TD) error from observed transitions and that scalar TD error, not the raw transition itself, is what updates the actor's policy parameters.
- [inference; source: http://incompleteideas.net/book/the-book-2nd.html] This is a direct instance of the raw-signal-versus-resolved-lesson distinction: the environment transition (state, action, reward, next state) is the raw feedback, and the TD error is the consolidated lesson; the actor's policy update interface only accepts the consolidated form, not the unprocessed transition.
- [fact; source: http://incompleteideas.net/book/the-book-2nd.html] Later actor-critic variants that incorporate experience replay buffers store raw transitions separately from the value/critic computation, and the critic re-derives its evaluative signal from sampled raw transitions on each update rather than the replay buffer directly modifying the actor's parameters.
- [fact; source: https://csrc.nist.gov/pubs/sp/800/207/final] NIST SP 800-207 defines a Zero Trust Architecture in which a Policy Engine (functioning as a Policy Decision Point, PDP) evaluates whether to grant access, a Policy Administrator (PAP) executes that decision by establishing or severing the communication path, and a Policy Enforcement Point (PEP) enables, monitors, and terminates the connection between subject and resource; these logical components communicate over a control plane that is architecturally separate from the data plane carrying the governed traffic.
- [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final] This decomposition prevents the decision function (verification-like) from directly executing an action on the resource: the PDP only produces a decision, the PAP is the sole component authorized to act on that decision, and the PEP is the sole component authorized to touch the live data-plane connection, so no single component both evaluates and acts unilaterally.
- [fact; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html] The UELGF policy-architecture item adopts this same PAP/PDP/PEP separation and adds a Policy Information Point (PIP) supplying contextual attributes to the PDP, plus an explicit "policy independence guarantee" that the entity being governed cannot supply its own governance inputs.
E. Systems engineering / cloud infrastructure: GitOps reconciliation loop versus admission policy loop
- [fact; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] Bugwadia's Cloud Native Computing Foundation (CNCF) blog post describes two distinct Kubernetes control loops that both act on the same live cluster objects but hold different authority: the GitOps reconciliation loop reconciles the live cluster state toward the desired state declared in a version-controlled Git repository, while the policy control loop (implemented by admission controllers such as Kyverno or Open Policy Agent (OPA) Gatekeeper) intercepts each resource change at admission time to validate, block, or mutate it according to declarative policy, independently of whether the change originated from the GitOps controller or another actor.
- [inference; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] The Git repository functions as the content pool (the authoritative desired-state record), the reconciliation controller functions as the execution zone (it is the only component permitted to write toward that desired state into the live cluster), and the admission policy controller functions as an independent verification zone that can veto or alter any write regardless of its source, which keeps verification authority structurally separate from execution authority even though both act on the same objects.
- [fact; source: https://martinfowler.com/bliki/TeamTopologies.html] Skelton and Pais's Team Topologies model, summarised by Fowler, defines four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes (collaboration, X-as-a-Service, facilitating) that formally constrain how one team is permitted to influence another's work.
- [inference; source: https://martinfowler.com/bliki/TeamTopologies.html] The X-as-a-Service interaction mode is the organisational-design analogue of an execution-to-content-pool interface contract: a platform team exposes a defined, consumable service boundary so that stream-aligned teams (execution-like, delivering business outcomes) draw on platform capability without directly modifying the platform team's internal work, while the facilitating mode used by enabling teams is explicitly temporary and advisory rather than a delivery or ownership relationship, preventing an enabling team's guidance from being mistaken for direct control.
- [fact; source: https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf] Trist and Bamforth's sociotechnical systems theory, developed from studies of British coal mining in the 1950s, holds that a technical subsystem (tools, processes, technology) and a social subsystem (roles, relationships, group norms) must be jointly optimised, because optimising one subsystem in isolation degrades the other and the combined system as a whole.
- [inference; source: https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf] Applied to a three-zone content/execution/verification architecture, joint optimisation implies that interface constraints between zones cannot be specified as a purely technical contract (message schemas, access-control rules) without also specifying the social or organisational rule for who is accountable for each zone's boundary, otherwise the technical boundary erodes under organisational pressure even if it is architecturally sound.
- [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] Across all five technical architectures surveyed (MAPE-K, blackboard, actor-critic, Zero Trust, GitOps/policy loops), the recurring structural pattern is asymmetric write access: any zone may read the content pool's current state, but writes into the pool are gated behind a distinct resolution or decision step performed by a component that is not the same component producing the raw candidate content, execution result, or verification signal.
- [inference; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html] This matches the UELGF runtime-feedback-loop item's existing distinction between raw Policy Enforcement Point signals and the resolved, aggregated structured demand signal that is permitted to modify rail specifications, indicating the pattern is not specific to any one field but recurs wherever a mediated pool, an active execution environment, and an independent verification mechanism co-exist.
Six architectures converge on a common shape: a mediated pool of authoritative content (knowledge base, blackboard, replay buffer, Git repository, rail specification), an execution environment that consumes pool content and produces candidate outputs (effectors, knowledge-source proposals, actor policy actions, reconciler writes, stream-aligned team deliverables), and an independent verification mechanism that evaluates candidates against pool-derived criteria without itself being the execution environment (Analyze stage, control shell, critic, PDP/admission controller, enabling-team facilitation). [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final] The interface constraint that keeps these zones from leaking into one another is a structural pattern applied consistently across all six architectures. Neither the execution environment's raw output nor the verification mechanism's raw signal becomes an authoritative content-pool entry on its own. Both require passage through a distinct resolution step (Plan in MAPE-K, the control shell's scheduling decision in blackboard architectures, the critic's TD-error computation in actor-critic, the PAP's action in Zero Trust, and the UELGF's structured-demand-signal aggregation). [inference; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html] Team Topologies and sociotechnical systems theory extend this pattern from technical systems to organisations, showing that the same asymmetric-write logic applies to human team boundaries (a platform team's internal work is not directly editable by a stream-aligned team) and that the interface constraint must be jointly designed across the technical and social dimensions to hold under real operating pressure. [inference; source: https://martinfowler.com/bliki/TeamTopologies.html; https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf]
contradiction_scan: resolved
confidence_adjustment: cross-cutting asymmetric-write-access claim kept at medium because it is an inference synthesised across five independent technical sources rather than a claim any single source states directly
scope_guardrail: maintained; no vendor-specific implementation blueprint produced
acronym_audit: passed on second pass
One apparent tension was identified and resolved: the GitOps/policy-loop example (§2.E) shows verification (the admission controller) acting with lower latency and higher intervention power than execution (the reconciler can be blocked entirely), whereas the actor-critic example (§2.C) shows verification (the critic) acting only after execution (the actor already took the action in the environment). [inference; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/; http://incompleteideas.net/book/the-book-2nd.html] This is not a contradiction in the underlying pattern; it reflects a genuine design choice available within the three-zone model: verification can be positioned as a pre-execution gate (admission control, Zero Trust PDP) or as a post-execution evaluator (TD-error critic, MAPE-K Analyze), and both positions preserve the same asymmetric-write-access constraint even though their intervention timing differs. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf]
Technical lens: [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://csrc.nist.gov/pubs/sp/800/207/final] The technical implementations converge on separating a control plane (MAPE-K's autonomic manager, Zero Trust's PDP/PAP pairing) from a data plane (the managed element, the governed application traffic), which is a stronger and more testable form of the content/execution/verification split than a purely logical separation, because a control-plane/data-plane split can be enforced with network- or process-level isolation rather than relying only on code discipline within one process.
Economic lens: [inference; source: https://martinfowler.com/bliki/TeamTopologies.html] The X-as-a-Service interaction mode in Team Topologies is partly an economic design: it minimises the cognitive load and coordination cost that a stream-aligned team would otherwise pay to negotiate directly with a platform team on every change, by converting a negotiated interface into a standing, self-service one; this suggests that zone interfaces which reduce ongoing coordination cost are more durable in practice than ones that require repeated negotiation.
Regulatory/governance lens: [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-policy-architecture-8-layer-context.html] The Zero Trust and UELGF examples show that a regulator-facing or audit-facing architecture benefits from making the verification zone's decision function explicitly non-bypassable and independently logged (the PDP's decision is always mediated by the PAP and monitored by the PEP), which is a stronger requirement than mere logical separation because it supports external audit of whether the boundary was actually respected at runtime, not only whether it was designed correctly on paper.
Historical lens: [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf] Blackboard architectures (1980s artificial intelligence) and sociotechnical systems theory (1950s organisational design) independently arrived at a shared insight decades before autonomic computing or Zero Trust architecture existed: that a shared, evolving pool of state benefits from an explicit, separately-motivated arbiter of contribution rather than allowing every contributing component equal, unmediated write access; this suggests the pattern is not an artifact of modern distributed-systems engineering but a recurring solution to a general coordination problem.
Behavioural lens: [inference; source: https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf; https://martinfowler.com/bliki/TeamTopologies.html] Sociotechnical systems theory's finding that technology-only optimisation degrades the social subsystem implies that a purely code-level interface constraint (an application programming interface (API) boundary, a schema validator) will not by itself keep zones from leaking into one another if the humans operating the system are incentivised to route around it; Team Topologies' explicit temporariness of the facilitating interaction mode is one concrete mechanism for preventing informal, unaccountable cross-zone influence from becoming permanent.
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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/]
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. ([fact]; medium confidence; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf)
- 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. ([fact]; medium confidence; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf)
- 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. ([fact]; medium confidence; source: http://incompleteideas.net/book/the-book-2nd.html)
- 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. ([fact]; medium confidence; source: https://csrc.nist.gov/pubs/sp/800/207/final)
- 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. ([inference]; medium confidence; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/)
- 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. ([fact]; medium confidence; source: https://martinfowler.com/bliki/TeamTopologies.html)
- 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. ([fact]; medium confidence; source: https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf)
- 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. ([inference]; low confidence; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/)
- 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. ([inference]; low confidence; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/; https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; http://incompleteideas.net/book/the-book-2nd.html)
- 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. ([fact]; medium confidence; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html)
Evidence map:
| Claim | Source | Confidence | Notes |
|---|---|---|---|
| [fact] MAPE-K gates raw monitor data through an Analyze stage before the knowledge base or Plan stage acts | https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf | medium | Primary source (Kephart & Chess 2003); single source |
| [fact] Blackboard knowledge sources post candidates; a separate control shell decides which is applied | https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf | medium | Authoritative secondary source (Corkill 1991); single source |
| [fact] Actor-critic converts raw transitions into a TD error before updating the actor | http://incompleteideas.net/book/the-book-2nd.html | medium | Primary textbook source (Sutton & Barto 2018); single source |
| [fact] Zero Trust separates PDP decision, PAP execution of decision, and PEP enforcement | https://csrc.nist.gov/pubs/sp/800/207/final | medium | Primary standards-body source (NIST SP 800-207); single source |
| [inference] GitOps reconciliation and admission-policy loops are independently authoritative over the same objects | https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/ | medium | Single secondary practitioner source; no independent corroborating source located |
| [fact] Team Topologies formalises three interaction modes constraining cross-team influence | https://martinfowler.com/bliki/TeamTopologies.html | medium | Secondary summary of the Skelton & Pais book; book itself not directly consulted |
| [fact] Sociotechnical systems theory requires joint optimisation of technical and social subsystems | https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf | medium | Secondary academic summary of Trist & Bamforth's original coal-mining studies |
| [inference] Asymmetric write access recurs across five independent technical architectures | https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/ | low | Synthesis across independently-sourced architectures; no single source states the cross-cutting generalisation |
| [inference] Verification timing (pre- or post-execution) varies but does not change the asymmetric-write constraint | https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/; https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; http://incompleteideas.net/book/the-book-2nd.html | low | Cross-source comparative claim; each source supports its own timing pattern, not the general comparison itself |
| [fact] UELGF's runtime feedback loop already separates raw PEP signal from resolved structured demand signal | https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html | medium | Prior repository item; single internal source |
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. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-control-plane-architecture-enterprise.html] 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. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-control-plane-architecture-enterprise.html]
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. [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html] 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. [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html]
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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] 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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf] 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. [inference; source: https://martinfowler.com/bliki/TeamTopologies.html; https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf]
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). [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html] 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. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html]
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. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-09-hybrid-architecture-probabilistic-llm-deterministic-governance.html] 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. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-09-hybrid-architecture-probabilistic-llm-deterministic-governance.html; https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html]
Risks, gaps, 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. [inference; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/]
- 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. [assumption; source: https://martinfowler.com/bliki/TeamTopologies.html]
- [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] 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. [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] 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. [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf]
- [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] 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?
review_result: pass
acronym_audit: passed (LLM, EBM, NIST, SP, PDP, PEP, PAP, PIP, UELGF, MAPE-K, KS, TD, OPA, CNCF, API all expanded at first prose use)
domain_term_audit: passed (blackboard architecture, control shell, TD error, control plane / data plane, X-as-a-Service, joint optimisation defined at first use)
parity_check: pending Findings mirror in Step 3
(Populated from §6 Synthesis above.)
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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] 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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] 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. [inference; source: https://martinfowler.com/bliki/TeamTopologies.html; https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf] 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. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html] 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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/]
- 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. ([fact]; medium confidence; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf)
- 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. ([fact]; medium confidence; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf)
- 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. ([fact]; medium confidence; source: http://incompleteideas.net/book/the-book-2nd.html)
- 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. ([fact]; medium confidence; source: https://csrc.nist.gov/pubs/sp/800/207/final)
- 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. ([inference]; medium confidence; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/)
- 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. ([fact]; medium confidence; source: https://martinfowler.com/bliki/TeamTopologies.html)
- 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. ([fact]; medium confidence; source: https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf)
- 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. ([inference]; low confidence; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/)
- 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. ([inference]; low confidence; source: https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/; https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; http://incompleteideas.net/book/the-book-2nd.html)
- 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. ([fact]; medium confidence; source: https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html)
| Claim | Source | Confidence | Notes |
|---|---|---|---|
| [fact] MAPE-K gates raw monitor data through an Analyze stage before the knowledge base or Plan stage acts | https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf | medium | Primary source (Kephart & Chess 2003); single source |
| [fact] Blackboard knowledge sources post candidates; a separate control shell decides which is applied | https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf | medium | Authoritative secondary source (Corkill 1991); single source |
| [fact] Actor-critic converts raw transitions into a TD error before updating the actor | http://incompleteideas.net/book/the-book-2nd.html | medium | Primary textbook source (Sutton & Barto 2018); single source |
| [fact] Zero Trust separates PDP decision, PAP execution of decision, and PEP enforcement | https://csrc.nist.gov/pubs/sp/800/207/final | medium | Primary standards-body source (NIST SP 800-207); single source |
| [inference] GitOps reconciliation and admission-policy loops are independently authoritative over the same objects | https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/ | medium | Single secondary practitioner source; no independent corroborating source located |
| [fact] Team Topologies formalises three interaction modes constraining cross-team influence | https://martinfowler.com/bliki/TeamTopologies.html | medium | Secondary summary of the Skelton & Pais book; book itself not directly consulted |
| [fact] Sociotechnical systems theory requires joint optimisation of technical and social subsystems | https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf | medium | Secondary academic summary of Trist & Bamforth's original coal-mining studies |
| [inference] Asymmetric write access recurs across five independent technical architectures | https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/ | low | Synthesis across independently-sourced architectures; no single source states the cross-cutting generalisation |
| [inference] Verification timing (pre- or post-execution) varies but does not change the asymmetric-write constraint | https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/; https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; http://incompleteideas.net/book/the-book-2nd.html | low | Cross-source comparative claim; each source supports its own timing pattern, not the general comparison itself |
| [fact] UELGF's runtime feedback loop already separates raw PEP signal from resolved structured demand signal | https://davidamitchell.github.io/Research/research/2026-04-27-uelgf-runtime-feedback-loop.html | medium | Prior repository item; single internal source |
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. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-control-plane-architecture-enterprise.html] 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. [assumption; source: https://davidamitchell.github.io/Research/research/2026-04-26-ai-agent-control-plane-architecture-enterprise.html]
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. [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html] 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. [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html]
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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] 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. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf] 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. [inference; source: https://martinfowler.com/bliki/TeamTopologies.html; https://open.ncl.ac.uk/theory-library/socio-technical-theory.pdf]
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). [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html] 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. [inference; source: https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html]
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. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-09-hybrid-architecture-probabilistic-llm-deterministic-governance.html] 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. [inference; source: https://davidamitchell.github.io/Research/research/2026-05-09-hybrid-architecture-probabilistic-llm-deterministic-governance.html; https://csrc.nist.gov/pubs/sp/800/207/final; http://incompleteideas.net/book/the-book-2nd.html]
- 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. [inference; source: https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/]
- 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. [assumption; source: https://martinfowler.com/bliki/TeamTopologies.html]
- [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf; http://incompleteideas.net/book/the-book-2nd.html; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/] 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. [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] 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. [inference; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf]
- [assumption; source: https://mas.cs.umass.edu/Documents/Corkill/ai-expert.pdf] 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.
- 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?
(Fill in when completing - what was produced as a result of this research?)
- Type: knowledge
- Description: A transferable interface-constraint pattern, asymmetric write access to a shared content pool, synthesised across five independent technical architectures (autonomic computing, blackboard artificial intelligence systems, actor-critic reinforcement learning, Zero Trust security architecture, GitOps/admission-policy control loops) and two organisational-design frameworks (Team Topologies, sociotechnical systems theory), intended to stress-test whether a three-zone content/harness/validation model keeps zone-specific responsibilities properly separated. [inference; source: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://csrc.nist.gov/pubs/sp/800/207/final; https://martinfowler.com/bliki/TeamTopologies.html]
- Links: https://www.cs.tufts.edu/comp/250SA/papers/kephart2003.pdf; https://csrc.nist.gov/pubs/sp/800/207/final; https://www.cncf.io/blog/2024/01/18/gitops-and-mutating-policies-the-tale-of-two-loops/
Navigation
By Tag
agentic-ai
- Alignment limits from missing shared background
- Higher-order operational patterns in production agentic AI
bureaucracy
change-management
coase
consciousness-cognition
constraint-analysis
control-model
decision-rights
delegation
- Q4: Decision rights that should move closer to execution
- Q5: Control model for the best throughput-risk trade-off
delivery-risk
- Operating model synthesis for split-authority delivery systems
- Q6: Leading indicators of instability in split-authority flow systems
demand-segmentation
enterprise
enterprise-adoption
exception-handling
execution
flow
flow-design
flow-metrics
governance
- Operating model synthesis for split-authority delivery systems
- Q1: Dominant flow constraint in split-authority delivery systems
- Q2: Demand segmentation for fast-path vs controlled-path flow
- Q4: Decision rights that should move closer to execution
- Conditions under which internal governance controls minimise coordination costs in regulated enterprises
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
- Barriers to governance reform, leadership failure modes, and reform mechanisms in regulated enterprises
governance-patterns
governance-policy
- Alignment limits from missing shared background
- Higher-order operational patterns in production agentic AI
human-ai-interaction
incentives
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
- Barriers to governance reform, leadership failure modes, and reform mechanisms in regulated enterprises
instability
institutional-economics
- Conditions under which internal governance controls minimise coordination costs in regulated enterprises
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
- Barriers to governance reform, leadership failure modes, and reform mechanisms in regulated enterprises
leading-indicators
mlops-deployment
operating-model
organisation
- Conditions under which internal governance controls minimise coordination costs in regulated enterprises
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
- Barriers to governance reform, leadership failure modes, and reform mechanisms in regulated enterprises
organisational-design
queue-design
queueing
regulated-enterprise
- Conditions under which internal governance controls minimise coordination costs in regulated enterprises
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
- Barriers to governance reform, leadership failure modes, and reform mechanisms in regulated enterprises
routing
throughput
throughput-risk
tools-infrastructure
transaction-costs
- Conditions under which internal governance controls minimise coordination costs in regulated enterprises
- Failure mechanisms of internal governance controls: bureaucratic inefficiency and informal circumvention in regulated enterprises
triage
- Q2: Demand segmentation for fast-path vs controlled-path flow
- Q3: Routing design that isolates exceptions from routine flow
williamson