Define the audit record and scope

Decide what is auditable and what each record must answer.

First time here? Paste the Context Pack first so the AI understands your project - open it from the header above.

Prompt Capsule

Design the audit record. SCOPE: audit consequential actions - state mutations (writes, deletes), external effects (network calls, sends, spends), permission decisions, and security-relevant events (blocks, escalations); read-only trivia need not be audited (avoid drowning the trail). RECORD FIELDS: timestamp, actor (agent id + session), action (tool + operation), arguments (scrubbed, but specific - which file, which record), AUTHORITY (what permitted it: auto-allow tier, session grant, user approval with reference, or policy), triggering context (task id, the user request that led here, provenance/trust of any content involved), and OUTCOME (success/failure, effect summary). Define which fields are mandatory. The test: could an investigator answer who/what/when/why/outcome from one record plus its links?

Paste into EmergentFull Build: complete implementation prompt with explicit requirements

Quick is short. Full Build is recommended for most steps. Strict forces real logic when the AI keeps faking output.

Actual change check

Expected after this step

An audit record schema that captures authority and causation, not just action.

Should NOT happen

An existing feature broke
A button only logs to console
Data disappears after refresh
Errors fail silently with no visible state

This is what should exist before you continue. If reality does not match, do not move on.

Your notes for this step

Track what changed, failed, or needs follow-up. Notes export with the flow.

Pass the Verify Gate to complete this step

Verify before continuing

Do not move on until every check is true. The complete button stays locked until then.

Consequential actions scoped; trivia excludedAuthority and triggering request capturedWho/what/when/why/outcome answerable

Do not continue if…

! Logs that show the action but not who/why/what-authorized-it
! Mutable logs an attacker (or the agent) could alter to hide actions
! Audit records so verbose or so sparse they cannot answer real questions
! No linkage between the action and the request/approval that caused it

If the AI messes this up

Use this when:

- it only made visual forms or placeholder UI
- buttons do nothing or only log to console
- data is not persisted - state disappears on refresh
- something that worked before is now broken

Use this when the AI fakes progress or breaks the feature. It forces a real fix.

Records show what happened but not why it was allowed. Add the authority and triggering-request fields - an audit trail that cannot explain why an action was permitted is useless in an incident.