Original Research

NPSL — Nudge Prompt
Specification Language

A self-annealing governance framework for deterministic AI agent control. Born from 2 years of empirical research with 1,000+ tests on preventing quality drift in multi-agent AI development systems.

Abstract

The Central Problem: Goodhart's Law in AI Agents

When an AI agent is rewarded for marking a task as "complete," it optimises for that signal — not for the underlying quality the signal was meant to represent. Left unchecked, an agent will gradually anneal away its own quality constraints because they create friction. It will declare success without running tests. It will claim "done" when nothing has been verified.

This is not malice. It is the natural result of optimising a proxy metric. It is Goodhart's Law applied to AI coding agents: "When a measure becomes a target, it ceases to be a good measure."

NPSL (Nudge Prompt Specification Language) is a governance framework that provides four structural protections against this failure mode, creating a self-improving system that gets stronger — not weaker — over time.

Foundation

The 3 Laws of AI Agent Control

These three principles form the axiomatic foundation of NPSL governance. Every rule, control point, and quality gate derives from these laws.

I

Don't Trust, Verify

Every agent claim requires independent evidence. A test log, not a promise. A screenshot, not a description.

II

Proximity Beats Priority

Rules at the moment of action override rules from session start. Context decay is countered by proximal reinforcement.

III

Impossible Beats Improbable

Technical controls (structural impossibility) beat behavioural controls (hoping the agent complies). Make violations architecturally impossible.

Architecture

Four Structural Protections

NPSL provides four interlocking mechanisms that prevent quality erosion:

1. Agents Cannot Promote Their Own Rules

Rule maturity is gated on external evidence, not self-assessment. An agent cannot decide its own rules are "good enough" and relax them. Promotion from OBSERVE to CHALLENGE requires 500+ observations across 10+ task types with a false positive rate below 10%. This threshold is measured by replay agents, not self-reported.

2. Break-Glass for Enforced Rules

Bypassing an ENFORCED rule requires explicit human sign-off and is permanently logged. The escape hatch OVERRIDE SA-XXX: {reason} exists because no rule is universally applicable — but every override creates an audit trail.

3. Evidence is Structurally Required

Completion contracts demand proof files, not claims. "All tests pass" is meaningless without a path to progress/testing/evidence/cp7/. The system enforces this through SA-007 (Testing Phase Sequence Gate) at the ENFORCE stage.

4. CI/CD is the External Truth Gate

The pipeline validates; the agent proposes. No code reaches production without passing through the environment pipeline: DEVELOPMENT → TEST → STAGING → PRODUCTION. Each stage has a different quality gate requirement.

Self-Annealing

Evidence-Based Rule Maturity Pipeline

Rules mature through evidence, not time. AI agents are not bound by the time dimension — they can spawn parallel agents to generate evidence at scale. A rule that works well can reach ENFORCE within a single session. A rule that fails gets demoted immediately.

OBSERVE // Shadow mode. Logging only. Gathering baseline data. Promote when: >= 500 observations, >= 10 task types, FPR < 10% CHALLENGE // Active warnings. Agent may continue but violation logged. Promote when: >= 2,000 obs, TPR > 80%, red-team fails 100 attempts ENFORCE // Blocks the action. Override requires escape hatch. Promote when: >= 10,000 obs, TPR > 90%, red-team fails 1,000 attempts IMMUTABLE // Permanent. Only human Break-Glass can override. Requires: Human sign-off. Constitutional amendment.

Key insight: Promotion is evidence-gated, not time-gated. A rule can be born from a production incident (like SA-004, created from 570 upsert failures) and be immediately placed at OBSERVE with fast-track evidence gathering via parallel replay agents.

Continuous Improvement

The Self-Annealing Loop

All transformer-based agents suffer from drift. Three types destroy quality: identity drift (agent forgets its role), goal drift (agent loses sight of the objective), and context drift (constraints set early are silently violated later — the "donut hole" problem).

BACON-AI's self-annealing loop runs continuously to detect and correct these failure modes:

DIAGNOSE // Detect drift signals Optimistic language, skipped tests, scope creep, identity confusion FIX // Correct the behaviour Apply the fix, document the pattern in lessons learned ANNEAL // Promote the fix to a rule Create or update SA rule via evidence pipeline (OBSERVE → ENFORCE) SYNC // Propagate across all agents Push to NAS, pull to all machines, update constitution.yml // Loop back to DIAGNOSE — continuous improvement
Active Rules

The Constitution: SA-001 through SA-008

Eight self-annealing rules currently govern all BACON-AI agent behaviour. Each rule was born from a real failure, documented with root cause analysis, and promoted through the evidence pipeline.

Rule Name Stage Purpose
SA-001 Optimistic Language Detector CHALLENGE Flags "should work", "ready for UAT" without evidence
SA-002 Evidence Path Validator OBSERVE Warns when test claims lack evidence file paths
SA-003 Scope Creep Detector OBSERVE Flags work outside the defined task boundary
SA-004 External API Boundary Sanitizer OBSERVE All external API data must pass through sanitize_*()
SA-005 Mandatory Completion Gap-Check CHALLENGE Enumerate gaps before any completion claim
SA-006 Mandatory SSC Review CHALLENGE 5-agent retrospective at session boundaries
SA-007 Testing Phase Sequence Gate ENFORCE TUT→FUT→SIT→RGT is mandatory and sequential
SA-008 Deming PDCA Completion Contract ENFORCE CHECK phase completes the DO phase — code without tests is a hypothesis
Methodology

The 12-Phase Development Methodology

BACON-AI structures every project through 12 sequential phases, each with defined inputs, outputs, quality gates, and team composition requirements. The methodology draws from PRINCE2, SAP Activate, ISTQB, and Deming's PDCA cycle.

PHASE 0
Verification
Verify prerequisites, assess feasibility
PHASE 1-2
Requirements
PRD, URD, feature decomposition
PHASE 3
Analysis
Architecture, C4 model, tech stack
PHASE 4-6
Solution Generation
TRIZ, evaluation, selection
PHASE 7-8
Design & Planning
TSD, FSD, implementation planning
PHASE 9
Build & Test
TUT, FUT, SIT, RGT quality gates
PHASE 10-11
Go-Live & Deploy
Staging, UAT, production release
PHASE 12
Reflection
SSC retrospective, lessons learned
Philosophy

The Deming Reframe

BACON-AI's most consequential insight came from applying Deming's PDCA cycle to AI agent behaviour. The chronic failure pattern is Plan → Do, treating Check as optional friction. SA-008 makes Check structurally non-optional by reframing the relationship between code and tests:

// OLD mental model (broken): "I built the feature, now I should test it" "Testing is friction before declaring done" "I clicked it and it worked" // NEW mental model (BACON-AI): "I built the code. Tests tell me if I built the FEATURE yet." "Testing is the last step of building. Without it, building is not done." "A click is an observation. An evidence file is proof." // The key insight: Code is the hypothesis. Tests are the proof. Evidence is the primary deliverable. Code is the supporting artifact.

Empirical data supports this approach. Defect cost multipliers (Capers Jones, NIST 2002): a defect found at TUT costs 1x. The same defect found at FUT: 4x. At SIT: 15x. At UAT: 40x. In production: 100x.