Q
Layer II

The Seven Principles
of Agentic Coordination

Structural requirements for governed agentic systems, grounded in specification theory, proof theory, and source-reliability epistemology.

v1.2 · 18 May 2026
Unifying Statement

A system is PromptQ-compliant when all seven principles are explicitly specified and operationally enforced to the degree required by the system's risk profile and operational context.

PromptQ assessment produces a structured score across all seven principles. Each principle is evaluated on a graduated scale. The total score reflects degree of compliance. A system with identified gaps is not non-compliant in the same way as one with no governance structure; the score identifies where remediation is required.

A system with known unresolved gaps should not be deployed in high-risk contexts until those gaps are addressed.

P1

Principle of Purpose

The system must operate toward an explicitly stated purpose. The purpose statement must define the output space and specify either a success predicate (for goal-directed systems) or an explicit exploration charter with defined domain, constraints, value signals, and stopping or redirect conditions (for exploratory systems). Systems that transition between modes must specify the transition criteria.

Technical specification — goal-directed systems
  • Accommodates stochastic outputs (distributions, confidence bounds, or expected utility ranges)
  • Specifies acceptance criteria and tolerances
  • Defines the output space and conditions under which evaluation applies
  • Makes trade-offs explicit in multi-objective settings
Technical specification — exploratory systems
  • Specifies the domain or problem space being explored
  • Defines the constraints on what the system may attempt
  • States what signals would indicate a worthy direction to pursue
  • Defines stopping or redirect conditions
Technical specification — hybrid or mode-shifting systems
  • Specifies the indicators that determine which mode is active
  • Defines the transition criteria between modes
P2

Principle of Measurement

System performance must be evaluated against explicit criteria known to the agent. The criteria need not be public or universal. They may be subjective or as simple as the satisfaction of a named person or role. What matters is that the agent has a mechanism to know whether the evaluation condition has been met. Invisible criteria cannot be satisfied reliably.

Technical specification
  • Maps outputs to scores or decisions
  • Supports repeatable (statistical where required) assessment
  • Exposes uncertainty or confidence
  • Designed, where feasible, to reduce susceptibility to proxy optimisation
  • Validated, where feasible, against the underlying objective to reduce proxy misalignment
P3

Principle of Authority

The system must only act within its defined scope of authority: what it is permitted to do, the source of that authority (which may be role- or policy-based), and the predefined conditions under which that authority can be expanded, restricted, or revoked.

Technical specification
  • Specifies allowed inputs, actions, and domains
  • Defines explicit out-of-authority conditions
  • Records the source of delegated authority, at the level of role or policy where individual attribution is impractical
  • Triggers refusal, fallback, or escalation on violation
  • Defines precedence between refusal, fallback, and escalation actions
  • Specifies conditions under which authority may change
P4

Principle of Data Integrity

Information must be handled according to defined trust and sensitivity constraints.

Technical specification
  • Classifies source reliability and sensitivity
  • Constrains usage, transformation, and retention
  • Enforces provenance tracking where feasible and proportionate
  • Defines handling procedures when data integrity cannot be verified or is compromised
P5

Principle of Quality Control

Outputs must satisfy explicitly defined acceptance criteria that are demonstrably mapped to the reasonable expectations of identified stakeholders and any applicable obligations, before being released or acted upon. Acceptance criteria that are not so mapped produce a false sense of security: a technically true proposition about a poor output is not quality control.

Technical specification
  • Identifies the stakeholder classes whose expectations the acceptance criteria must reflect
  • Evaluates outputs against the success predicate and/or rubric
  • Enforces acceptance thresholds or regions (not limited to binary decisions)
  • Defines retry, revision, fallback, or escalation behaviour
  • Includes safeguards against exploitation via repeated retries or metric gaming
  • Defines limits or termination conditions for retry and revision processes
  • Names the evidence stream the human can independently access to verify the output
  • Requires active human engagement (a deliberate decision or confirmatory action) rather than passive approval
P6

Principle of Consistency

The governing specification must not contain unresolved contradictions. Three failure modes are identified: explicit contradiction, where two instructions cannot both be followed; implicit ambiguity, where an instruction admits multiple valid readings with different execution outcomes; and mechanism-obligation mismatch, where the document certifies a capability its specified mechanism cannot deliver.

Technical specification
  • Identifies incompatible constraints or instructions
  • Specifies precedence or arbitration mechanisms
  • Prevents execution under unresolved conflict unless explicitly permitted by defined fallback or arbitration rules
  • Includes resolution pathways for system-human disagreement
P7

Principle of Adaptation

The governing document must declare when its content becomes stale and specify the conditions that require re-evaluation. A document that makes no staleness declaration will silently assert authority over a system it may no longer correctly describe.

Technical specification — document level
  • Declares a time-based staleness threshold: the document specifies a maximum interval after which it must be re-evaluated regardless of other conditions
  • Declares at least one event-based trigger: the document names the conditions that require immediate re-evaluation (such as model update, tool addition, or domain expansion)
  • Declares at least one evidence-based trigger: the document names the boundary behaviour divergence thresholds at which re-evaluation is required regardless of time or events
  • Supports versioning and supersession of specifications
Technical specification — programme level
  • Monitors performance and environment at a cadence proportionate to system risk
  • Defines explicit divergence thresholds and triggers
  • Initiates revalidation, constraint updates, or controlled degradation when thresholds are exceeded
  • Defines system operating conditions during revalidation
  • Surfaces unexpected or anomalous deviations not limited to pre-specified divergence metrics, with defined response pathways