Drifting Signals I'm just trying to keep up.

The Anchor Model

Organizational architecture

By Brenden Portolese

An Organizational Architecture for AI-Enabled Work

Concept White Paper — Version 0.1

Humans own truth. AI authors its representation.

Anchors define. Orchestrators direct. Agents execute. Guardians verify. Humans decide.

Abstract

Artificial intelligence is making execution dramatically more abundant. Organizations can increasingly use AI to draft, analyze, build, research, communicate, test, and operate at a scale that would previously have required far more human labor. The resulting constraint is no longer simply execution capacity. It is alignment: keeping rapidly produced work attached to business intent, organizational policy, risk appetite, brand standards, architecture, and human accountability.

The Anchor Model is a proposed organizational architecture for AI-enabled work. It separates durable human-owned truth from AI authorship and execution. Anchors represent authoritative organizational intent. Orchestrators determine how work should proceed and which context, actors, controls, and approval gates apply. Agents perform bounded work. Guardians independently evaluate outputs for drift from relevant Anchors. Humans retain authority over truth, consequential decisions, exceptions, and evolution of the Anchors themselves.

The model is intended to create bounded autonomy: more AI execution without surrendering organizational accountability.

1. The Problem: Execution Is Becoming Abundant

Traditional organizations are structured around scarce human execution capacity. Processes, teams, queues, reviews, and documentation evolved partly because producing work was expensive.

AI changes that economic assumption.

When a small number of people can direct large amounts of machine execution, organizations can produce more code, analysis, content, decisions, and operational work. But increasing throughput without increasing alignment creates a new failure mode: faster drift.

AI can efficiently produce work that is internally coherent yet inconsistent with the organization's actual intent.

The critical question therefore changes from:

How do we make AI do more work?

to:

How do we allow AI to do substantially more work while keeping humans in control of what is true, acceptable, valuable, and accountable?

2. The Core Principle

Humans own truth. AI authors its representation.

Ownership and authorship are different.

A human Product leader may own the truth of a customer problem while AI authors the PRD that represents it. Security may own the truth of an organizational control while AI converts that control into machine-readable policy. Finance may own a forecasting methodology while AI authors reports and analyses based on it.

The party that generates an artifact does not automatically own its meaning.

This distinction provides the foundation for scalable human governance of AI-enabled work.

3. The Five Elements

3.1 Anchors Define

An Anchor is a durable, authoritative, human-owned representation of organizational truth.

Anchors can represent:

  • strategy;
  • product intent;
  • policy;
  • architecture;
  • security requirements;
  • risk appetite;
  • brand standards;
  • accounting policy;
  • legal constraints;
  • operating procedures;
  • data governance;
  • quality standards.

Anchors should increasingly be machine-consumable. Natural-language explanation may coexist with structured rules, schemas, policy-as-code, examples, and testable constraints.

Documentation therefore becomes part of the control plane for AI execution.

3.2 Orchestrators Direct

An Orchestrator determines how a unit of work moves through the organization.

It asks:

  • What outcome is requested?
  • Which Anchors apply?
  • What context is needed?
  • Which Agent, human, or deterministic tool should perform each step?
  • Which validations are required?
  • Which Guardians should participate?
  • What risk classification applies?
  • When is human approval required?
  • What evidence must exist before completion?

Orchestrators do not need to perform the work themselves. They direct the work.

The policy governing an Orchestrator should generally be owned by the organizational function accountable for the outcome, while technical execution machinery may be owned by platform or engineering teams.

3.3 Agents Execute

Agents provide scalable execution capacity.

They may:

  • research;
  • draft;
  • code;
  • transform;
  • classify;
  • analyze;
  • generate;
  • test;
  • reconcile;
  • summarize;
  • operate tools.

Agents are deliberately replaceable components. The architecture should not depend on a particular model or vendor.

3.4 Guardians Verify

Guardians independently evaluate work against relevant Anchors.

A Guardian does not define organizational truth. It asks whether the work remains aligned with the truth owned elsewhere.

Guardian outputs should provide evidence, confidence, severity, and recommended disposition rather than opaque approval.

Guardians should be invoked selectively. Applying every Guardian to every task would recreate bureaucracy with AI.

3.5 Humans Decide

Humans retain authority where accountability matters.

Human decisions include:

  • approving or changing Anchors;
  • resolving material ambiguity;
  • accepting consequential risk;
  • approving exceptions;
  • making strategic tradeoffs;
  • authorizing high-impact actions;
  • deciding when organizational truth should evolve.

Human-in-the-loop should not mean human approval for every machine action. It means human authority at consequential boundaries.

4. The Control Loop

                HUMAN-OWNED TRUTH
                       |
                       v
                    ANCHORS
                  define intent
                       |
                       v
                 ORCHESTRATOR
                   directs work
                       |
             +---------+---------+
             |         |         |
             v         v         v
           AGENT      HUMAN     TOOL
             |         |         |
             +---------+---------+
                       |
                       v
                   GUARDIANS
                verify alignment
                       |
                 +-----+-----+
                 |           |
              ALIGNED       DRIFT
                 |           |
                 |           v
                 |       EXCEPTION
                 |           |
                 |           v
                 |      ANCHOR OWNER
                 |      /    |    \
                 |   Reject Allow Evolve
                 |           |
                 +-----------+
                       |
                       v
                    OUTCOME
                       |
                       v
                   TELEMETRY
                       |
                       +----> learning / better Anchors

5. Drift and Exceptions

Drift is a difference between observed work and an applicable Anchor.

Drift is not automatically wrong.

It may represent:

  1. accidental divergence;
  2. an incorrect interpretation;
  3. a justified one-time exception;
  4. evidence that the Anchor itself should evolve.

A Guardian should detect divergence, not automatically suppress innovation.

An Exception Request should explain the sanctioned approach, proposed alternative, evidence, benefits, risks, and requested disposition.

The Anchor owner may:

  • reject the exception;
  • approve a bounded exception;
  • approve the exception and evolve the Anchor.

This converts governance from static enforcement into an organizational learning mechanism.

6. Risk-Adaptive Orchestration

Governance must be proportional.

A low-risk, reversible task may need only lightweight verification. A consequential task involving regulated data, financial exposure, public claims, security boundaries, or irreversible action may require multiple Guardians and explicit human approval.

The Orchestrator should therefore activate controls based on:

  • consequence;
  • reversibility;
  • data sensitivity;
  • regulatory exposure;
  • novelty;
  • confidence;
  • financial impact;
  • customer impact;
  • organizational risk appetite.

Without risk adaptation, AI governance can become an automated bureaucracy.

7. Ownership Versus Machinery

A useful separation exists between policy ownership and execution machinery.

The outcome owner should generally own:

  • intended result;
  • orchestration policy;
  • completion criteria;
  • human gates;
  • acceptable evidence.

Platform or technical teams may own:

  • workflow engines;
  • model routing;
  • tool integrations;
  • logging;
  • identity and permissions;
  • CI/CD;
  • telemetry infrastructure.

Anchor owners remain accountable for the truth represented in their Anchors.

8. Evidence and Provenance

AI-enabled work should produce evidence, not merely output.

Depending on the domain, an evidence package may record:

  • governing Anchor versions;
  • inputs;
  • models or tools used;
  • material assumptions;
  • Guardian findings;
  • exceptions;
  • human decisions;
  • approvals;
  • deterministic validation;
  • final outcome;
  • production telemetry.

This provides traceability from organizational intent to executed work.

9. Economics of Model Routing

The architecture should not assume that every task requires the most capable model.

Orchestrators can route:

  • mechanical work to inexpensive models;
  • deterministic work to code or rules engines;
  • ambiguous reasoning to stronger models;
  • consequential decisions to humans.

The objective is the least expensive reliable execution path consistent with the consequence of the work.

10. What Is Actually Durable?

Individual AI products will change rapidly.

Agents are therefore not the primary organizational intellectual property.

The more durable assets are:

Anchors — what the organization knows, intends, permits, and requires.

Orchestration — how the organization turns intent into action.

Guardian logic — how the organization determines whether execution remains aligned.

This makes the Anchor Model intentionally vendor-independent.

11. A Testable Hypothesis, Not a Proven Doctrine

The Anchor Model combines ideas related to policy-as-code, human-in-the-loop systems, workflow orchestration, design systems, architecture governance, automated testing, AI agents, and organizational controls.

Its proposed contribution is their integration into a human-owned control architecture for AI-enabled execution.

The model should be treated as a hypothesis to validate empirically.

Important questions include:

  • Can Anchors be represented precisely enough for reliable machine interpretation?
  • Can Guardians achieve useful precision without excessive false positives?
  • Does risk-adaptive orchestration reduce governance burden?
  • Does the Exception mechanism improve Anchors over time?
  • Does the model increase verified business value per human hour?
  • Can accountability remain clear as AI authorship increases?

Reference implementations and measured pilots should precede claims of broad superiority.

12. Success Measures

The model should be judged on outcomes such as:

  • business value per human hour;
  • cycle time;
  • human review burden;
  • escaped drift;
  • Guardian false-positive rate;
  • exception resolution time;
  • cost per completed unit of work;
  • quality;
  • control failures;
  • risk events;
  • Anchor freshness;
  • percentage of work requiring human escalation.

The goal is not maximum autonomy.

The goal is maximum useful autonomy within explicit human ownership and acceptable risk.

13. Conclusion

AI makes execution abundant. That makes organizational alignment more valuable.

The Anchor Model proposes a simple division of responsibility:

Anchors define. Orchestrators direct. Agents execute. Guardians verify. Humans decide.

Underneath it sits an even simpler principle:

Humans own truth. AI authors its representation.

The opportunity is not merely to give people better AI tools. It is to design organizations whose intent, controls, workflows, and accountability are structured for a world in which AI can perform a substantial share of execution.

That is the purpose of the Anchor Model:

An Organizational Architecture for AI-Enabled Work.

Appendix A — Applications Beyond Software Development

The Anchor Model is domain-independent. The specific Anchors, Orchestrators, Agents, Guardians, and human gates change by function.

These examples are intentionally illustrative rather than complete designs.

A.1 Software Development

Anchors: BRD, PRD, UX/UI, Architecture, Stack, Security, Risk, Data Governance
Orchestrator: Product-owned delivery orchestration policy
Agents: Coding, testing, research, documentation, migration agents
Guardians: Product, UX, Architecture, Stack, Security, Risk, Data
Humans: Product owners, engineers, architects, security/risk owners

See the companion paper, The Anchor Model for Software Development.

A.2 Marketing

Anchors: Brand, campaign strategy, legal claims, audience policy, privacy, channel standards
Orchestrator: Campaign orchestration
Agents: Research, copy, image, video, segmentation, analytics
Guardians: Brand, legal/claims, privacy, channel compliance
Humans: Marketing owner, brand, legal, compliance

A campaign can be generated rapidly while remaining attached to brand truth and approved claims.

A.3 Finance and FP&A

Anchors: Accounting policy, forecast methodology, chart of accounts, materiality thresholds, reporting definitions
Orchestrator: Close, forecast, or management-reporting workflow
Agents: Reconciliation, variance analysis, narrative drafting, scenario modeling
Guardians: Accounting policy, anomaly, controls, data quality
Humans: Controller, FP&A leadership, business owners

AI authors analysis; humans remain accountable for financial truth.

A.4 Regulated Operations / Underwriting

Anchors: Policy, regulation, eligibility rules, risk appetite, fair-treatment requirements
Orchestrator: Case or underwriting workflow
Agents: Document extraction, verification, analysis, recommendation
Guardians: Compliance, fairness, risk, policy adherence
Humans: Authorized decision makers and exception owners

The architecture separates machine recommendation from accountable authority.

A.5 Customer Operations

Anchors: Customer policy, service standards, refund/credit authority, legal disclosures, brand voice
Orchestrator: Case-resolution workflow
Agents: Classification, retrieval, response drafting, workflow execution
Guardians: Policy, customer harm, brand, compliance
Humans: Escalation owners for exceptions and consequential decisions

A.6 Procurement and Vendor Management

Anchors: Procurement policy, approved terms, security requirements, third-party risk appetite, budget authority
Orchestrator: Vendor evaluation and approval workflow
Agents: Research, comparison, contract extraction, diligence preparation
Guardians: Security, risk, legal, financial authority
Humans: Procurement, business sponsor, legal/risk approvers

Anchors: Approved legal positions, playbooks, jurisdictional rules, escalation policy, privilege requirements
Orchestrator: Matter or review workflow
Agents: Research, extraction, drafting, comparison
Guardians: Citation/evidence, policy, jurisdiction, confidentiality
Humans: Attorneys and authorized compliance owners

The architecture should never confuse AI authorship with legal accountability.

A.8 Human Resources

Anchors: HR policy, compensation frameworks, job architecture, employment-law guidance, privacy
Orchestrator: Hiring, mobility, performance, or employee-case workflow
Agents: Drafting, scheduling, information retrieval, structured analysis
Guardians: Policy, privacy, fairness, legal requirements
Humans: HR owners and authorized managers

A.9 The Common Pattern

Across these domains, the implementation changes but the architecture remains recognizable:

Human-owned truth
      |
   Anchors
      |
Orchestrator
      |
Agents / Humans / Tools
      |
Guardians
      |
Human authority where consequential
      |
Outcome
      |
Telemetry and learning

The broader vision is therefore not a software-development methodology.

It is an organizational architecture for directing, constraining, verifying, and learning from AI-enabled work while preserving human ownership of truth and accountability.

Appendix B — Related Work, Overlap, and Differentiation

A candid companion note for readers of the Anchor Model white paper, identifying closely related 2026 work and clarifying which ideas should—and should not—be treated as distinctive.

Prepared September 2026

Executive note

The Anchor Model was developed independently, but it is not being developed in an intellectual vacuum. Recent industry work and research converge on several of the same problems: specification-driven AI development, machine-readable constraints, continuous governance, drift detection, independent verification, risk-based human gates, and explicit human authority. In particular, The Spec Growth Engine is close to several mechanics in the software-development application of the Anchor Model.

Accordingly, the Anchor Model should not claim novelty for those individual mechanisms. Its potentially distinctive contribution is the higher-level organizational architecture: multiple heterogeneous, human-owned sources of authoritative intent (“Anchors”); orchestration that selects which authorities, actors, controls, and evidence apply to a unit of work; replaceable execution Agents; domain-specific independent Guardians; and a governed feedback loop through which exceptions can challenge and evolve organizational truth.

Humans own truth. AI authors its representation.

Anchors define. Orchestrators direct. Agents execute. Guardians verify. Humans decide.

B.1 The sources

OneTrust — Guardian Agents / Continuous AI Governance

Industry guidance and product framing. Source

OneTrust describes Guardian Agents as runtime governance systems for autonomous AI: monitoring behavior, enforcing scope and access boundaries, detecting drift, escalating risk, and maintaining auditability. It emphasizes agent identity, least privilege, risk-based human oversight, lifecycle control, and governance that operates continuously rather than as a one-time review. This overlaps strongly with the Anchor Model’s Guardian concept, but its primary object of governance is the AI agent and its behavior rather than arbitrary organizational work evaluated against multiple separately owned domain Anchors.

Hartwig Grabowski — The Spec Growth Engine

Spec-Anchored, Code-Coupled, Drift-Enforced Architecture for AI-Assisted Software Development. arXiv:2606.27045 — submitted June 25, 2026.

The paper addresses context explosion and silent spec-code drift using a machine-readable spec graph, scoped context assembly (“Spine”), vertical-slice growth, and a drift gate that can block merges. It explicitly synthesizes established software-engineering practices into a machine-enforced, code-coupled framework. Of the sources reviewed here, it is the closest match to the software-development implementation of the Anchor Model, especially around spec anchoring, selective context, drift enforcement, and bounded authority.

Sabry E. Farrag — The Productivity-Reliability Paradox

Specification-Driven Governance for AI-Augmented Software Development. arXiv:2605.01160 — submitted May 1, 2026.

This paper argues that faster AI code generation does not necessarily produce faster organizational delivery because review, context, and reliability become bottlenecks. It introduces a Specification Governance Model and concludes that specification discipline—not simply model capability—is a binding constraint on dependable AI-assisted software development. That thesis strongly overlaps the Anchor Model’s view that execution is becoming abundant while alignment, context, verification, and authority become more important.

Christopher Koch & Joshua Andreas Wellbrock — Agile V

A Compliance-Ready Framework for AI-Augmented Engineering — From Concept to Audit-Ready Delivery. arXiv:2602.20684 — submitted February 24, 2026.

Agile V combines Agile iteration with V-Model verification and embeds specialized AI agents for requirements, design, build, test, and compliance into a continuous workflow. It uses independent verification, automatically generated audit artifacts, and mandatory human approval gates, and reports a small feasibility case study. This substantially overlaps the Anchor Model’s separation of execution, verification, evidence, and consequential human decision-making, but is centered on compliant engineering delivery rather than a general organizational architecture.

Srinivas Rao Marri — Constitutional Spec-Driven Development

Enforcing Security by Construction in AI-Assisted Code Generation. arXiv:2602.02584 — submitted January 31, 2026.

This methodology introduces a versioned, machine-readable security “Constitution” containing non-negotiable constraints that shape AI-generated code before implementation. The paper emphasizes traceability and reports a banking case study in which constitutional constraints reduced security defects compared with unconstrained generation. Its Constitution is conceptually close to a Security Anchor, especially the idea that human-readable intent can be represented in a structured, versioned form that machines can consume and verify.

The original source list included arXiv:2605.01160 twice; it is listed once here.

B.2 Where the Anchor Model clearly overlaps existing work

The following ideas should be treated as convergent or established patterns rather than claimed as inventions of the Anchor Model:

  • Specifications or constitutions that constrain AI-generated work.
  • Machine-readable or machine-consumable governing artifacts.
  • Selective context assembly for AI execution.
  • Detection of drift between intended and actual implementation.
  • Independent AI-assisted verification.
  • Risk-sensitive human approval gates and bounded autonomy.
  • Traceability, evidence generation, and auditability.
  • Continuous runtime governance of autonomous agents.
  • Versioned policies, constraints, and formal amendment or exception mechanisms.

B.3 Where the Anchor Model may contribute something broader

1. Human ownership of truth versus AI authorship

The Anchor Model makes an explicit distinction between authority and authorship: AI may create, maintain, translate, or execute representations of organizational intent, but a human role remains accountable for what is authoritative. This is broader than keeping a human “in the loop”; it is an ownership model for organizational truth.

2. Multiple heterogeneous Anchors

The model is not built around a single specification or constitution. Product intent, architecture standards, security policy, UX principles, risk appetite, data governance, regulatory interpretation, empirical evidence, and strategic objectives can all be authoritative in different ways and owned by different human roles.

3. Orchestration as coordination of authority

The Orchestrator does more than route tasks to agents. In the proposed model it determines which Anchors apply, which actors or tools should execute, which Guardians should evaluate the work, what evidence is required, and where human authority must enter the workflow. This makes orchestration partly an authority-and-context problem, not merely an agent-routing problem.

4. Guardians tied to domain authority

A Guardian does not own the standard it evaluates. A Security Guardian evaluates against a Security Anchor owned by Security; a Product Guardian evaluates against Product intent; a Risk Guardian evaluates against the organization’s risk authority. This separation is intended to preserve accountability while allowing verification to operate at machine speed.

5. Exceptions as an organizational learning loop

Drift is not automatically treated as failure. A deliberate divergence can produce evidence, trigger an exception request, and be adjudicated by the human owner of the relevant Anchor; the result may be rejection, a bounded exception, or evolution of the Anchor itself. This turns execution into a potential source of governed organizational learning.

6. Generalization beyond software

The broad Anchor Model is intended to apply to AI-enabled organizational work, not only software development: underwriting, marketing, finance, procurement, customer operations, legal/compliance, HR, and other domains. Spec-driven development can therefore be viewed as one possible application of the broader architecture rather than the definition of the model.

B.4 A more precise differentiation

Related concept Primary question Anchor Model framing
Policy-as-code What rules should machines enforce? How does human-owned intent become governed, machine-directed work?
Spec-driven development How do specifications constrain AI software delivery? How do multiple human-owned authorities coordinate AI-enabled work?
Guardian agents How do we monitor and constrain autonomous AI agents? How do independent evaluators verify work against applicable domain Anchors?
RAG / context assembly What information should the model retrieve? Which sources are authoritative, who owns them, when do they apply, and what happens on conflict?
Human-in-the-loop Where should a human approve or intervene? Which decisions remain human-owned, and how is that authority encoded into the workflow?

B.5 The strongest current formulation

A defensible claim is not: “The Anchor Model invented spec-driven AI development, Guardian agents, drift detection, or human approval gates.”

A more defensible claim is: “The Anchor Model proposes an organizational architecture that integrates human-owned authoritative context, risk-adaptive orchestration, replaceable AI execution, independent domain verification, and governed human decision-making into a common pattern for AI-enabled work.”

A useful relationship to the adjacent work is:

  • Spec-driven development can be an implementation pattern within the Anchor Model.
  • Policy-as-code can be a machine-enforceable representation within an Anchor.
  • Guardian Agents can be one mechanism for verification or runtime control.
  • RAG can be one mechanism for assembling relevant Anchor context.
  • Human approval gates can be one expression of human decision authority.

B.6 Important unresolved questions

The Anchor Model is still a proposed framework, not a validated operating model. Before making stronger claims, a reference implementation should test whether it improves outcomes compared with simpler agentic workflows.

  • Can heterogeneous Anchors be represented precisely enough for reliable machine use?
  • Can an Orchestrator correctly determine which authorities apply without creating a new opaque decision layer?
  • Can Guardians achieve useful precision without overwhelming teams with plausible-sounding false positives?
  • Can conflicting Anchors be resolved without turning human approval into the new bottleneck?
  • Can exception-driven evolution improve organizational learning without weakening controls?
  • Does the architecture improve business value, cycle time, reliability, or auditability enough to justify its complexity?

The white paper should be read as an emerging synthesis and hypothesis, not as a claim that every underlying mechanism is novel. The recent convergence represented by these sources is useful evidence that the underlying problem is real: as AI execution becomes faster and more autonomous, specification, context, governance, verification, and human authority become increasingly important.

The next step for the Anchor Model should therefore be empirical. A small reference implementation should compare the same AI-enabled work with and without explicit Anchors, Orchestration, Guardians, and exception handling, measuring alignment, defects, human effort, false positives, cycle time, and inference cost.

B.8 Sources