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.
The system must operate toward an explicitly defined objective.
Technical specification
- 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
System performance must be evaluated using explicit, shared criteria.
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
The system must only act within its defined scope of authority.
Technical specification
- Specifies allowed inputs, actions, and domains
- Defines explicit out-of-scope conditions
- Triggers refusal, fallback, or escalation on violation
- Defines precedence between refusal, fallback, and escalation actions
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
Outputs must satisfy defined acceptance criteria before being released or acted upon.
Technical specification
- 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
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
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