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.1 · 29 April 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
P6

Principle of Consistency

The governing specification must not contain unresolved contradictions.

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 system must remain aligned with current conditions over time.

Technical specification
  • 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
  • Supports versioning and supersession of specifications
  • Surfaces unexpected or anomalous deviations not limited to pre-specified divergence metrics, with defined response pathways