Goal generation

An AI system that can retrieve and reason over evidence still needs to know what it is trying to achieve. Goal generation is the process by which an AI derives, commits to, and decomposes its operational goals — and AIEP provides a structured, auditable substrate for each stage of that process.


The problem with ungoverned goals

Most AI systems today have goals that are implicit — embedded in training, specified in a system prompt, or inferred from context at runtime. This creates three problems:

ProblemWhat happens
Goal driftThe goal shifts as context changes, without any record of what changed and why
Goal ambiguityThe same prompt generates different goal interpretations in different runs — no canonical commitment
Goal hijackingA downstream instruction overrides an upstream goal with no audit trail and no check on whether the override is legitimate

AIEP addresses all three by treating the goal state as a first-class artefact — published, signed, hash-bound, and retrievable.


GoalVector

A GoalVector is a deterministic, structured representation of an AI agent’s current goal state.

It is not a natural language description. It is a canonical, schema-validated record that commits the agent to a specific goal configuration at a specific point in time. The record is signed by the issuer and anchored to the evidence layer.

What a GoalVector contains:

FieldPurpose
Goal identifierCanonical reference to the goal definition
Evidence bindingThe artefacts that justify this goal being active
Commitment hashSHA-256 of the goal state at time of commitment
Activation timestampWhen the goal became active
Issuer signatureWho authorised this goal
Drift thresholdThe allowable deviation before re-commitment is triggered

A GoalVector is not a wish. It is a commitment with provenance.


GoalVector stabilisation

Goals drift. As new evidence arrives, as context shifts, as subgoals complete and new ones are generated, the operational goal of an AI system changes — often without any explicit record of the change having occurred.

GoalVector stabilisation (P50) is the mechanism by which that drift is detected and constrained:

  1. The agent commits to a GoalVector at the start of a task
  2. As execution proceeds, the active goal state is continuously compared against the committed vector
  3. If the deviation exceeds the drift threshold, the agent cannot silently continue — it must either re-commit to a new GoalVector (with evidence justifying the change) or halt
  4. Every re-commitment is a signed record in the evidence ledger — the goal history is auditable end-to-end

This means that for any completed task, you can reconstruct exactly what goal the agent was pursuing at every step, and what caused any goal changes.


Hierarchical planning and subgoal arbitration

High-level goals must be decomposed into executable subgoals. AIEP’s hierarchical planning layer (P72) structures this decomposition as an auditable graph rather than an opaque internal process:

LevelDescription
Primary goalThe top-level GoalVector commitment
SubgoalsDerived goals that must be completed to fulfil the primary goal
Arbitration nodesDecision points where competing subgoals are compared and one is selected
Resolution recordsSigned records of which subgoal was selected, why, and on what evidence

The arbitration graph is not hidden inside the model. It is a structured artefact that can be retrieved, audited, and challenged. If a subgoal was selected in a way that led to a harmful outcome, the arbitration record shows exactly where and why the selection was made.

This is the difference between a system that can be investigated and one that can only be observed.


Governance chip goal trigger

The governance chip goal trigger (P89) extends the GoalVector model to hardware-enforced activation.

In high-stakes deployments — medical, legal, infrastructure — goal activation should not rely solely on software. The governance chip acts as a hardware boundary: a goal cannot become active unless the chip validates the activation record against the signed GoalVector and issues a hardware-bound receipt.

The chain:

  1. Goal is defined and signed as a GoalVector artefact
  2. Activation request is submitted to the governance chip
  3. Chip validates: issuer signature, evidence binding, drift compliance
  4. Chip issues a hardware-signed activation receipt
  5. The AI system can only proceed if the receipt is valid
  6. The receipt is logged to the evidence ledger — tamper-evident, timestamped

No receipt — no activation. The goal cannot run without a verifiable hardware witness to its authorisation.


Why this matters

Goal generation is where AI alignment meets verifiable infrastructure. An AI system can have perfect retrieval, perfect reasoning, and still pursue the wrong goal — or pursue the right goal for a few steps before drifting into something different.

AIEP’s approach:

  • Goals are not assumed — they are declared and committed as structured artefacts
  • Goal changes are not silent — every re-commitment is a signed record
  • Subgoal selection is not opaque — arbitration is structured and auditable
  • High-stakes activation is not software-only — hardware witnesses can be required

The result is a system where the question “what was this AI trying to do, and when did that change?” has a retrievable, cryptographically anchored answer.


  • Architecture — Layer 4 constitutional stack
  • Protocol — Evidence and governance primitives
  • Audit — Evidence ledger and tamper-evident chaining
  • Patents — P50, P72, P89
  • Security — Threat model and governed reasoning