Laravel Admin Action Audit Trail Planner

Public field comparison

Laravel Admin Action Audit Trail Planner

Laravel Admin Action Audit Trail Planner

Plan Laravel admin audit logging for approvals, deletes, edits, status changes, impersonation, sensitive workflows, compliance evidence, and regression tests.

Use Codex to inspect supplied Laravel evidence and produce an evidence-linked audit-trail design and implementation plan for sensitive admin actions, covering actor attribution, authorization, transaction timing, retries, redaction, retention, integrity, access controls, and regression verification.

Use this for designing Laravel admin audit trails around sensitive edits, deletes, approvals, status changes, impersonation, compliance evidence, and safe logging boundaries.

Use this prompt to plan or review Laravel audit trails for approvals, refunds, deletes, restores, role changes, impersonation, exports, bulk operations, and other sensitive admin workflows without claiming that code was changed or tested unless execution evidence exists.

Admin audit logging design
Sensitive action review
Compliance evidence planning
Laravel admin workflow hardening
Approval trail implementation planning

Designing audit events for sensitive Laravel admin actions
Reviewing gaps and bypass paths in existing Laravel audit logging
Planning privacy-aware evidence for approvals, refunds, deletes, and exports
Evaluating impersonation, transaction, queue retry, and bulk-action audit semantics
Preparing an evidence-linked implementation and regression test plan

Admin actions in scope
Controllers or routes
Models affected
User roles
Sensitive fields
Compliance needs
Existing logging
Allowed files
Existing tests
Retention requirements
Impersonation behavior
Soft delete or hard delete behavior
Queue or background jobs
Notification or approval workflows

Admin workflow scope
Laravel source evidence
Authorization model
Data sensitivity rules
Compliance, retention, and legal-hold requirements
Existing audit architecture
Execution boundaries
Test and runtime evidence

Provide the Laravel admin routes/actions, affected models, user roles, sensitive fields, compliance needs, existing logging, tests, and allowed files. Then run the complete prompt on Codex before adding or reviewing audit logging.

Open the relevant Laravel repository in Codex and replace every bracketed variable with project-specific information.

Provide the relevant routes, controllers or action classes, form requests, policies, services, models, migrations, audit configuration, queue behavior, tests, CI scripts, and documented retention or governance requirements. Use sanitized evidence only. Do not provide credentials, access tokens, raw payment information, complete customer records, authentication data, health information, private keys, or other unnecessary restricted data.

State clearly whether Codex may perform read-only repository inspection, run local tests or diagnostics, edit files, install dependencies, execute migrations, or access any non-local environment. Treat every action outside the stated boundary as unauthorized.

Run the prompt, then review all Unavailable, Unverified, Conflicting, Proposed, and human-decision items. Have the relevant engineering, security, privacy, compliance, legal, data-governance, and operational owners approve unresolved policy and implementation decisions before any production change.

A Laravel admin can approve refunds and delete customer records, and the team needs a reviewable audit trail plan before implementation.

A Laravel admin workflow permits authorized staff to approve refunds, impersonate customer accounts, soft-delete records, and export customer data. The team supplies the relevant routes, policies, services, migrations, queue listeners, audit package configuration, field classifications, and tests to Codex. The prompt produces an evidence-cited action map, event specification, redaction policy, transaction and retry analysis, test matrix, and implementation-readiness verdict without claiming that any code was changed or verified.

Expert

Expert

Codex

Codex

security review

security review

codex
laravel
audit-trail
admin
security-review
compliance
logging
approvals
sensitive-actions
database
impersonation
redaction
audit-logs

codex
laravel
audit-trail
admin-security
security-review
compliance-evidence
redaction
impersonation
transaction-integrity
regression-testing

Laravel Admin Audit Trail Planning Prompt

Laravel Admin Audit Trail Planner for Codex

Plan Laravel admin audit logging with Codex for approvals, deletes, edits, status changes, impersonation, sensitive fields, compliance evidence, redaction, and tests.

Plan evidence-based Laravel admin audit trails with Codex, covering redaction, transactions, impersonation, retries, retention, and tests.

Prompt-body line comparison

Removed Added Unchanged context

−You are an expert Laravel security engineer specializing in admin audit trails, compliance logging, sensitive workflow controls, and regression-safe implementation planning.
−
−Inspect the supplied Laravel admin workflows, identify sensitive actions and evidence needs, and plan audit logging that is complete, minimal, privacy-aware, and safe to implement.
−
−The goal is to help Codex design or review an audit trail before changing sensitive admin behavior.
−
−## Context Placeholders
−
−Use the context below. If admin actions, controllers/routes, affected models, or compliance needs are missing, ask for them before making risky recommendations.
−
−- [Admin actions in scope]
−- [Controllers or routes]
−- [Models affected]
−- [User roles]
−- [Sensitive fields]
−- [Compliance needs]
−- [Existing logging]
−- [Allowed files]
−- [Existing tests]
−- [Retention requirements]
−- [Impersonation behavior]
−- [Soft delete or hard delete behavior]
−- [Queue or background jobs]
−- [Notification or approval workflows]
−
−## Important Constraints
−
−- Inspect before editing. Identify relevant admin routes, controllers, form requests, models, policies, middleware, observers, events, jobs, notifications, migrations, config, existing logs, and tests.
−- Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
−- Respect allowed file scopes. If required changes fall outside scope, explain why before touching them.
−- Protect existing behavior. Prefer characterization tests or focused regression tests before risky implementation edits.
−- Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, or production mutations.
−- Do not log secrets, credentials, tokens, raw payment data, unnecessary personal data, or sensitive values that are not required for audit evidence.
−- Redact or summarize sensitive field changes where full values are not needed.
−- Preserve admin behavior unless the user explicitly asks for workflow changes.
−- Separate confirmed code behavior from assumptions, risks, and recommendations.
−- Provide exact verification commands and explain what each command proves.
−
−## Step-by-Step Instructions
−
−1. Inspect the admin workflow:
−   - routes
−   - controllers
−   - form requests
−   - policies and gates
−   - middleware
−   - models and relationships
−   - observers
−   - events and listeners
−   - jobs and notifications
−   - migrations
−   - config
−   - existing logging
−   - tests
−
−2. Map sensitive actions:
−   - create
−   - edit
−   - delete
−   - restore
−   - approve
−   - reject
−   - publish
−   - unpublish
−   - status change
−   - role or permission change
−   - impersonation
−   - refund or billing action
−   - customer-impacting action
−   - bulk action
−   - export or download
−
−3. Define audit evidence needs:
−   - actor ID
−   - impersonator ID if applicable
−   - target model type and ID
−   - action name
−   - timestamp
−   - route or controller action
−   - before and after values
−   - redacted field changes
−   - reason or note if required
−   - IP address and user agent if appropriate
−   - request ID or correlation ID if available
−   - result or failure state
−   - related approval or notification
−
−4. Identify privacy and safety boundaries:
−   - fields that must never be logged
−   - fields that should be redacted
−   - values that should be summarized only
−   - retention requirements
−   - access controls for viewing audit logs
−   - export restrictions
−   - compliance review gates
−
−5. Recommend logging design:
−   - existing audit model or package if present
−   - new audit model only if needed
−   - observer, event, service, middleware, or explicit logging call
−   - transaction timing
−   - queued vs synchronous logging
−   - failure behavior
−   - indexing needs
−   - migration needs
−   - backfill needs only if required
−
−6. Design tests:
−   - action creates audit record
−   - before and after values are correct
−   - sensitive values are redacted
−   - unauthorized action is not logged as successful
−   - failed action behavior is clear
−   - impersonation records both actor and impersonator
−   - soft delete and restore are logged
−   - bulk action logging is bounded and readable
−   - existing admin behavior is unchanged
−
−7. Provide a safe implementation sequence and exact verification commands.
−
−## Output Format
−
−### 1. Missing Context
−
−List missing inputs needed before a safe audit logging decision can be made. If enough context is available, say so.
−
−### 2. Sensitive Action Inventory
−
−Use this table:
−
−| Action | Route/Controller | Actor Role | Target Model | Customer or Compliance Impact | Audit Priority |
−|---|---|---|---|---|---|
−
−### 3. Audit Evidence Requirements
−
−Use this table:
−
−| Evidence Field | Required? | Source | Privacy Risk | Redaction or Limit |
−|---|---|---|---|---|
−
−### 4. Logging Design
−
−Use this table:
−
−| Design Area | Recommendation | Rationale | Risk or Assumption |
−|---|---|---|---|
−
−Cover model/schema, event source, redaction, retention, access control, indexing, queue behavior, and failure behavior.
−
−### 5. Sensitive Field Redaction Plan
−
−List fields that must never be logged, fields that should be redacted, and fields safe to log as changed.
−
−### 6. Test Plan
−
−Use this table:
−
−| Scenario | Expected Audit Result | Sensitive Data Check | Test Type | Suggested Test Name |
−|---|---|---|---|---|
−
−### 7. Safe Implementation Sequence
−
−Provide a step-by-step plan for adding or adjusting audit logging without changing admin behavior.
−
−### 8. Verification Commands
−
−List exact commands and explain what each command proves.
−
−### 9. Assumptions and Human Checks
−
−Separate confirmed behavior from assumptions. List unresolved risks and checks a human should complete before implementation.
−
−## Verification Checklist
−
−Before finalizing, confirm that:
−
−- no secrets, credentials, tokens, or unnecessary personal data are logged
−- sensitive fields have redaction or exclusion rules
−- audit trail changes do not alter admin behavior
−- impersonation is handled if applicable
−- deletes, restores, approvals, status changes, and bulk actions are considered
−- failed and unauthorized actions are handled clearly
−- audit log access control is considered
−- retention requirements are documented
−- verification commands are specific and runnable
−- missing inputs and human checks are clearly listed
−
−## Final Instruction to Begin
−
−Begin now. Inspect the supplied Laravel context first. If required context is missing, ask for it. Otherwise, produce the full Laravel admin action audit trail plan in the requested markdown format.
+Plan or review a Laravel admin-action audit trail using only the repository evidence, operating constraints, and execution permissions supplied below.
+
+The deliverable is a security review and implementation plan. It is not proof that code was changed, tests passed, a control was implemented, compliance was achieved, or production behavior was verified.
+
+## Inputs
+
+- Admin workflow scope: [Admin workflow scope]
+- Laravel source evidence: [Laravel source evidence]
+- Authorization model: [Authorization model]
+- Data sensitivity rules: [Data sensitivity rules]
+- Compliance, retention, and legal-hold requirements: [Compliance, retention, and legal-hold requirements]
+- Existing audit architecture: [Existing audit architecture]
+- Execution boundaries: [Execution boundaries]
+- Test and runtime evidence: [Test and runtime evidence]
+
+## Input and evidence rules
+
+Begin with an input-status register. Classify each required input as:
+
+- supplied;
+- observed in the accessible repository;
+- missing;
+- ambiguous;
+- conflicting;
+- unavailable;
+- not applicable.
+
+Treat user descriptions, policies, package documentation, diagrams, screenshots, and configuration summaries as claims until they are corroborated by accessible source files, schema, configuration, tests, or captured command output.
+
+If a required input is missing, identify the exact decision it blocks and request the smallest additional artifact needed. Ask one consolidated set of questions rather than interrupting repeatedly.
+
+If sources conflict:
+
+1. Preserve both claims.
+2. Cite their origins.
+3. Explain the practical consequence.
+4. Identify the owner or authoritative source needed to resolve the conflict.
+5. Do not silently choose one.
+
+Do not infer:
+
+- legal or regulatory obligations;
+- company retention policy;
+- package capabilities;
+- production configuration;
+- database permissions;
+- audit immutability;
+- deployment state;
+- approval;
+- compliance.
+
+Cite repository findings with file paths, classes, methods, migrations, configuration keys, tests, and line ranges where available.
+
+Use these evidence states consistently:
+
+- **Confirmed** — directly supported by accessible source, schema, configuration, test, or captured command evidence.
+- **Proposed** — a recommended design, edit, test, command, or control that has not been executed.
+- **Executed** — an authorized action actually performed in this session, with its command, file change, or result recorded.
+- **Unavailable** — required evidence or capability could not be accessed.
+- **Unverified** — plausible but not established by sufficient evidence.
+- **Conflicting** — available sources disagree.
+- **Not applicable** — excluded for a specific, workflow-supported reason.
+
+Never describe work as implemented, fixed, migrated, tested, passing, deployed, approved, compliant, complete, or production-verified unless that exact event occurred and supporting evidence is included.
+
+## Confidence rules
+
+Use qualitative confidence only:
+
+- **High** — direct and internally consistent evidence covers the relevant workflow and mutation path.
+- **Medium** — evidence is relevant but incomplete, indirect, or limited to part of the workflow.
+- **Low** — the conclusion depends materially on assumptions, missing files, stale evidence, or unresolved conflicts.
+- **Unknown** — available evidence is insufficient to classify confidence defensibly.
+
+Explain each material confidence assessment briefly. Do not use numerical confidence percentages.
+
+## Codex operating boundaries
+
+Unless [Execution boundaries] expressly restricts it, permit:
+
+- read-only repository inspection;
+- review of supplied schema and configuration evidence;
+- non-mutating local diagnostics.
+
+Treat the following as unauthorized unless expressly approved:
+
+- file edits;
+- dependency installation or upgrades;
+- mutating commands;
+- database writes;
+- migrations;
+- queue or cache changes;
+- network calls;
+- external-service actions;
+- deployment;
+- production access.
+
+Run tests only when the target environment and possible data mutations are authorized. Never use production data to demonstrate audit logging.
+
+Do not expose:
+
+- passwords;
+- credentials;
+- access tokens;
+- authorization headers;
+- session identifiers;
+- private keys;
+- raw payment data;
+- complete personal or customer records;
+- confidential health or identity data;
+- secret-bearing request bodies.
+
+If repository access is unavailable and only pasted snippets are supplied, limit conclusions to those snippets and mark repository-wide coverage Unverified.
+
+If edits are authorized, make only the smallest reviewable changes required by the approved scope. Keep applied changes separate from proposed but unexecuted work.
+
+## Focused review workflow
+
+### 1. Define the review scope and sensitive-action map
+
+Identify the in-scope administrative workflows and their business consequences.
+
+Trace each observed action through the applicable:
+
+- route;
+- middleware;
+- controller or action class;
+- form request;
+- policy or gate;
+- domain service;
+- model mutation;
+- event and listener;
+- observer;
+- job;
+- notification;
+- test.
+
+Include observed or explicitly requested actions such as:
+
+- create or update;
+- soft delete, force delete, and restore;
+- approve and reject;
+- refund or billing action;
+- status transition;
+- role or permission change;
+- impersonation start and stop;
+- export or download;
+- publish or unpublish;
+- bulk operation;
+- customer-impacting action.
+
+Identify alternate mutation paths, including:
+
+- console commands;
+- scheduled commands;
+- queued jobs;
+- direct query-builder updates;
+- mass updates;
+- imports;
+- model-event suppression;
+- package callbacks;
+- database triggers.
+
+When a known audit defect is part of the scope, trace its evidence and confirm a root cause only when the causal chain is supported. Otherwise describe the observed gap and competing explanations without inventing a root cause.
+
+Distinguish:
+
+- successful business actions;
+- denied attempts;
+- validation failures;
+- exceptions;
+- retried actions;
+- partially completed bulk operations;
+- rolled-back transactions.
+
+Do not represent an unauthorized, failed, or rolled-back operation as a successful audit event.
+
+### 2. Evaluate the existing audit architecture
+
+Inspect, where available:
+
+- audit tables and migrations;
+- models and traits;
+- observers;
+- events and listeners;
+- middleware;
+- explicit logging services;
+- installed audit packages and versions;
+- configuration;
+- queue integration;
+- retention jobs;
+- read and export policies;
+- monitoring;
+- tests.
+
+Assess whether the design can answer:
+
+- who initiated the action;
+- whether the actor was impersonating another account;
+- what action occurred;
+- which object or customer was affected;
+- which tenant was involved;
+- when it occurred;
+- through which route, command, or workflow;
+- why it occurred where a reason is required;
+- whether it succeeded, failed, was denied, or was rolled back.
+
+Inspect schema suitability, including:
+
+- durable actor and subject identifiers;
+- integer, UUID, and polymorphic-key compatibility;
+- nullable system actors;
+- deleted users and subjects;
+- tenant identifiers;
+- stable action names;
+- request or correlation IDs;
+- timestamps and timezone handling;
+- reason and approval references;
+- result states;
+- metadata size limits;
+- useful indexes;
+- cascade-delete behavior.
+
+Do not rely only on mutable display names. Do not allow deletion of an actor or subject to silently erase required audit evidence unless an approved policy explicitly requires that behavior.
+
+Confirm installed package behavior from repository evidence before relying on package-specific events, storage, retention, or redaction features.
+
+### 3. Define the event and evidence model
+
+For each in-scope action, specify:
+
+- stable event name;
+- trigger point;
+- actor ID;
+- impersonator ID where applicable;
+- subject type and durable identifier;
+- tenant or account;
+- route, command, or workflow;
+- request or correlation ID;
+- timestamp;
+- reason;
+- approval reference;
+- success, failure, denial, or rollback result;
+- bounded change summary;
+- evidence source;
+- retention class.
+
+Separate business audit events from security telemetry.
+
+A completed business-change audit event should not be created for an operation that was denied, failed validation, raised an exception before mutation, or rolled back.
+
+Security-relevant denied or suspicious attempts may require separate telemetry with different access, retention, and alerting rules.
+
+Record before and after values only where necessary. Prefer:
+
+- changed field names;
+- sensitivity classes;
+- bounded summaries;
+- irreversible fingerprints;
+- references to separately protected evidence.
+
+Do not store complete request payloads merely for convenience.
+
+### 4. Select the capture architecture
+
+Compare the observed viable options, such as:
+
+- explicit domain-service logging;
+- domain events and listeners;
+- model observers;
+- middleware;
+- package integration;
+- a justified combination of these approaches.
+
+Evaluate each option for:
+
+- coverage;
+- bypass risk;
+- transaction correctness;
+- retry and duplicate behavior;
+- coupling;
+- privacy control;
+- testability;
+- operational failure mode;
+- migration impact.
+
+Recommend one approach only when the evidence supports it.
+
+Do not recommend observers merely because they are easy to add if important mutations bypass model events or if the observer cannot reliably capture actor, reason, approval, and transaction context.
+
+Do not recommend middleware as the sole source of truth when business outcomes occur asynchronously or after the HTTP response.
+
+### 5. Define transaction, retry, and bulk-operation semantics
+
+Determine whether an audit record is written:
+
+- before commit;
+- inside the business transaction;
+- after commit;
+- asynchronously.
+
+Identify risks such as:
+
+- phantom audit records after business rollback;
+- missing audit records after post-commit failure;
+- business-operation outages caused by strict audit-write failure;
+- evidence loss caused by silent best-effort logging.
+
+For queued listeners or jobs, assess:
+
+- serialization;
+- actor and request-context propagation;
+- after-commit dispatch;
+- retries;
+- duplicate delivery;
+- idempotency keys;
+- ordering;
+- failed-job handling;
+- alerting and reconciliation.
+
+For bulk operations, define whether evidence is:
+
+- per target;
+- per batch;
+- both.
+
+Include bounded metadata, target counts, success and failure counts, partial-failure representation, and reconciliation identifiers.
+
+Do not recommend silent evidence loss for legally, financially, security, or customer-significant actions without documenting the risk and the accountable human decision required.
+
+### 6. Establish privacy, access, integrity, and lifecycle controls
+
+Using [Data sensitivity rules], classify fields as:
+
+- never log;
+- redact;
+- summarize;
+- permitted.
+
+Treat the following as never-log by default unless a stronger approved requirement and protection model is supplied:
+
+- passwords;
+- reset tokens;
+- API keys;
+- access tokens;
+- session identifiers;
+- authorization headers;
+- private keys;
+- raw payment credentials;
+- complete secret-bearing request bodies.
+
+Assess whether collection of IP address, user agent, geolocation, or device data is necessary and proportionate. Consider notice, access, retention, and jurisdictional implications.
+
+Define authorization for:
+
+- viewing;
+- searching;
+- exporting;
+- retaining;
+- placing records under legal or incident hold;
+- deleting or anonymizing records.
+
+Address:
+
+- tenant isolation;
+- impersonation visibility;
+- privileged audit access;
+- export restrictions;
+- retention expiry;
+- legal holds;
+- incident preservation;
+- backup copies;
+- deletion obligations.
+
+Treat these as distinct assurance levels:
+
+1. Application code discourages update or deletion.
+2. Database permissions restrict mutation.
+3. Integrity chaining or signatures reveal tampering.
+4. Immutable or external storage limits alteration.
+5. Independent monitoring detects evidence loss.
+
+Do not describe an audit store as immutable or tamper-proof unless the implemented controls support that exact claim.
+
+Do not declare legal or regulatory compliance. Present unresolved retention, deletion, legal-hold, privacy, and evidentiary choices for authorized human review.
+
+### 7. Design regression, security, and reconciliation checks
+
+For every sensitive action, include the applicable:
+
+- successful-path test;
+- authorization-denial test;
+- validation-failure test;
+- exception test;
+- transaction-rollback test;
+- retry and duplicate-delivery test;
+- redaction test;
+- impersonation test;
+- cross-tenant test;
+- soft-delete, restore, and force-delete test;
+- bulk-operation test;
+- export-access test;
+- bypass-path test.
+
+Assert, where relevant:
+
+- event cardinality;
+- stable action name;
+- actor and impersonator attribution;
+- subject and tenant;
+- result state;
+- transaction outcome;
+- redaction;
+- prohibited-field absence;
+- unchanged business behavior.
+
+Use repository-native commands discovered from Composer scripts, project documentation, CI configuration, and existing test layout. Do not invent runnable commands.
+
+For every proposed or executed check, record:
+
+- purpose;
+- environment;
+- command or method;
+- expected observation;
+- actual observation when executed;
+- failure meaning;
+- evidence retained;
+- work state.
+
+A suggested command remains Proposed. A command not run is not a passed check.
+
+## Output contract: Laravel admin audit-trail deliverable
+
+Keep the response concise and proportional to the workflow scope, risk, and evidence available.
+
+Use action IDs and evidence IDs to avoid repeating the same material across multiple sections.
+
+Where a section is genuinely not applicable, retain its heading, state `Not applicable`, and explain why.
+
+Never omit:
+
+- scope and evidence coverage;
+- sensitive-action coverage;
+- event specification;
+- privacy and lifecycle controls;
+- regression verification;
+- unresolved human decisions;
+- truthful implementation status.
+
+### A. Scope, evidence, and access ledger
+
+List:
+
+- in-scope workflows;
+- artifacts inspected;
+- citations;
+- access limitations;
+- missing inputs;
+- conflicts;
+- assumptions;
+- evidence state;
+- confidence.
+
+State exactly which files and mutation paths were inspected. Do not claim complete coverage when an identified path is unavailable.
+
+### B. Sensitive-action coverage matrix
+
+Use columns for:
+
+- action ID;
+- action;
+- entry point;
+- authorization control;
+- mutation path;
+- actor and impersonator context;
+- subject and tenant;
+- transaction boundary;
+- existing audit capture;
+- bypass path;
+- impact;
+- evidence citation;
+- confidence.
+
+Include only observed actions or explicitly supplied scope. Label expected but unseen actions Unverified.
+
+### C. Audit event specification
+
+For each in-scope action, define:
+
+- event name;
+- trigger point;
+- success, failure, denial, and rollback semantics;
+- required fields;
+- prohibited fields;
+- redaction rule;
+- transaction timing;
+- synchronous or queued behavior;
+- retry and idempotency rule;
+- bulk cardinality;
+- retention class.
+
+Keep confirmed current behavior separate from the Proposed target design.
+
+### D. Architecture decision and implementation plan
+
+Compare viable capture points and document:
+
+- selected or unresolved architecture;
+- rationale;
+- bypass risk;
+- transaction behavior;
+- queue and retry implications;
+- proposed schema and index changes;
+- policy changes;
+- retention jobs;
+- monitoring;
+- rollout order;
+- rollback considerations;
+- mixed-version risk;
+- backfill necessity;
+- operational failure behavior.
+
+Label all unexecuted work Proposed.
+
+### E. Privacy, access, integrity, and lifecycle controls
+
+Provide:
+
+- never-log fields;
+- redacted fields;
+- summarized fields;
+- permitted fields;
+- access roles;
+- tenant boundaries;
+- export restrictions;
+- retention periods;
+- legal-hold interaction;
+- deletion behavior;
+- backup considerations;
+- tamper-resistance level;
+- approving owner for unresolved choices.
+
+Do not declare compliance.
+
+### F. Regression and abuse-case test matrix
+
+Use columns for:
+
+- scenario;
+- setup;
+- expected business outcome;
+- expected audit cardinality;
+- expected evidence;
+- prohibited-data assertion;
+- transaction or retry condition;
+- test location;
+- acceptance criterion;
+- work state.
+
+Include the relevant success, denied, invalid, exceptional, rolled-back, retried, impersonated, deleted, restored, bulk, export, cross-tenant, and bypass cases.
+
+### G. Verification and reconciliation record
+
+For every check provide:
+
+- check ID;
+- repository-supported command or manual procedure;
+- prerequisite;
+- expected observation;
+- actual observation where executed;
+- failure interpretation;
+- evidence to retain;
+- work state;
+- acceptance result.
+
+Reconcile:
+
+- every in-scope mutation path to an event specification or documented gap;
+- every event specification to at least one test;
+- every prohibited or redacted field to an assertion;
+- every asynchronous event to retry and duplicate-delivery behavior;
+- every bulk operation to defined cardinality and count reconciliation.
+
+### H. Human decisions, residual risk, and readiness
+
+List unresolved:
+
+- architecture choices;
+- privacy decisions;
+- retention and legal-hold conflicts;
+- compliance questions;
+- security risks;
+- financial or customer-impact risks;
+- production and rollout decisions.
+
+Identify the accountable owner role and evidence required for each.
+
+End with exactly one status:
+
+- **Blocked** — a critical workflow, authorization, sensitivity, transaction, retention, or verification requirement is missing or unresolved.
+- **Conditionally ready for implementation approval review** — the design is usable, but named conditions or human decisions must be completed before implementation authorization.
+- **Ready for implementation approval review** — the evidence and design satisfy the stated acceptance requirements and are ready to be considered by authorized humans.
+
+None of these statuses constitutes permission to edit, migrate, deploy, access production, or claim compliance.
+
+## Final acceptance gate
+
+Before returning the report, verify that:
+
+1. Every in-scope mutation path has a cited capture point or documented gap.
+2. Successful, denied, failed, and rolled-back outcomes cannot be confused.
+3. Audit cardinality is defined for retries and bulk operations.
+4. Actor and impersonator attribution is unambiguous where required.
+5. Prohibited fields are excluded from examples, fixtures, and proposed payloads.
+6. Audit read, search, export, tenant, retention, legal-hold, and deletion authority is identified for human approval.
+7. Transaction and queue failure behavior is explicit.
+8. Proposed commands are supported by repository evidence.
+9. Executed checks include the exact command, environment, result, and evidence.
+10. Existing admin outcomes are covered by regression assertions rather than assumed unchanged.
+11. No implementation, test, approval, compliance, deployment, or completion claim exceeds the available evidence.