DIGITAL FORGE DOSSIER // REVIEWED RECORD
— powered by ai-teams
AI-operated delivery with human review gates
Most conversations about AI and software engineering start with throughput: can the model write the code, how fast, and how much? Operating a production Go microservice platform, I found the constraint somewhere else. Generating code was not the hard part. Knowing which of the agent's claims I could rely on was.
The result is a system in which AI agents perform requirement analysis, task planning, backend implementation, first-pass review, incident diagnosis, release work, routine maintenance, and database backup. I retain the veto wherever an action becomes irreversible, outward-facing, or production-affecting.
REAL WORK FIRST // WORKFLOW RECONSTRUCTION
Bug investigation and repair
Feature development
Database export automation
Routine maintenance
Architecture and operational-risk review
Development and SRE planning
WHERE IT STANDS TODAY
Requirements → specification → plan → implementation → independent verification
Deployment → maintenance → database export → SRE evidence
Start gates → independent verification → amendments → human veto
Verifiable dealing and match history entered dev integration testing
NEXTFinish integration evidence · retain separate environment gates · run a restore drill
AI performs the defined engineering work. I decide the architecture, accept or reject revisions, control environment promotion, and retain the final veto.
CONTROL DOCTRINE
An agent that reports success without admissible evidence has not removed work. It has moved uncertainty into a place where it is harder to inspect. So I built the delivery system around a different question: what counts as evidence?
Encode the rule as an invariant of the tool, not as documentation a person is expected to remember.
Destructive capability defaults to off. A missing contract causes a refusal rather than a guess. Knowledge without required freshness metadata fails a check. Published plans disclose incomplete state instead of hiding it. An implementation agent's narrative and its own shell output are not accepted as proof of its work.
A second principle matters just as much: record what is not known. Knowledge gaps, unresolved domain questions, and numbered incident threads have explicit homes. One incident record states that a question is undecidable with the available instrumentation and names the metric that would settle it. That boundary turns missing knowledge into visible state instead of a hallucination surface.
SYSTEM TOPOLOGY
requirement-to-spec-architectSpecificationengineering-task-plannerImmutable planai-backend-developer
ai-frontend-developerImplementationindependent verifierTrusted verdictSpecifications, immutable plans, implementation, and independent verification. The core contains zero hard-coded project references.
cyberpoker-expertDomain context · 16 service recordscyberpoker-sre-expert4 environments × 6 systemsApproved context files, service records, and session-level consultation supply domain knowledge without automatic Skill-to-Skill dispatch.
Durable ledgers govern incidents, releases, maintenance, and database exports.
Roles hand work to each other through versioned files instead of conversation history. A different agent—or a different AI vendor—can resume a stage without reconstructing the earlier chat.
EVIDENCE PROTOCOL
The agent's own shell output is inadmissible as evidence of its own work.
Only harness-native tool results and terminal output supplied by the human count. Seven completion words are individually gated: done, written, updated, tested, validated, verified, and committed.
Each ticket is reviewed by a separate verifier in a new session. Its findings stand by default. The implementation agent cannot rebut them with memory, earlier claims, its own narrative, its own shell output, inferred filesystem state, or a rationalising theory. A challenge requires a saved dispute backed by trusted evidence.
Published plans are immutable and digest-pinned. Execution state lives in separate ledgers. Before implementation, every cited file and line is rechecked against the current repository because the code may have moved since planning. Changes outside a ticket's allowed-file scope require a change request or a numbered amendment.
AUTHORIZATION MATRIX
The gates sit where correction stops being cheap or an action stops being reversible.
| Gate | What it blocks |
|---|---|
| Specification approval | A requirement becoming a plan |
| Plan publication approval | A plan becoming executable and immutable |
| Diagram decision | Code starting before design is recorded |
| Artifact landing evidence | Review starting before required artifacts exist |
| Milestone gate | Work advancing to the next milestone |
| Merge-request review and merge | Code entering a shared branch |
| Production deployment trigger | Code reaching production |
| Infrastructure execution authorization | Any infrastructure command running |
| Destructive maintenance confirmation | A real maintenance side effect |
| Outward-facing announcement | A release announcement being sent |
| On-chain signing | Any blockchain transaction |
| Backup execution | A real export after 16 prechecks and a canary |
The system never auto-commits, auto-branches, or auto-merges. It never writes into a published plan, reads or prints secret values, grants itself cloud permissions, or marks a ticket Done. Done means QA passed, and that is not the agent's decision.
MISSION TRACE
The incident workflow starts by reading the ticket and every comment. It locates the owning service through approved project knowledge, then traces the root cause to a source location. Production or staging logs may be consulted only after the infrastructure-access gate is approved.
The agent must close evidence, code, and every reported symptom against each other. It renders that reasoning as a symptom-to-mechanism-to-evidence table so a partial explanation remains visible.
The fix includes a regression test that is verified to fail against the original bug. The system prepares a merge request; I review and merge it. The closing sequence checks the pipeline, creates a durable deployment record, prepares release communication, and moves the ticket to Ready For Test with QA assigned. It does not set the ticket to Done.
SELECTED CASE DETAILS
FIXED IN STAGING · SENT TO QA
In a test environment, an item-claim request returned success. But the item disappeared, its contents never arrived, and the system created no transaction record.
The AI read the issue and every comment, followed the code path, and compared the affected logs with a normal control sample. It found two bugs that caused the failure only when they happened together, then added three regression tests that all failed against the old code as expected.
After I reviewed the fix, it was deployed to staging and copied back to development on 2026-08-07. The deployment record includes the merged changes and QA handoff.
DEVELOPMENT COMPLETE · DEV INTEGRATION TESTING · NOT PRODUCTION
Two complex backend features needed to move from requirements through architecture, implementation, and independent verification without allowing AI agents to rewrite scope or promote environments on their own.
The governed workflow completed Chainlink VRF-based verifiable dealing and match history. The VRF flow had already passed Base Sepolia request-to-fulfillment validation; both feature sets were merged and deployed to dev for integration testing on 2026-08-24.
Both features remain in dev integration testing. Neither is deployed to production, and integration testing has not been claimed as passed.
IN USE · HUMAN CONFIRMATION REQUIRED
The old process meant opening GCP Console and exporting each database one by one. I spent about 27 minutes clicking and watching the jobs, and there was no standard manifest at the end.
I turned the process into one guided command. The AI guides the run and summarizes the result, while a fixed script handles 16 prechecks, a dry run, a one-database canary, export, compression, and the final manifest.
The first measured run covered 19 databases. Hands-on time fell from about 27 minutes to about two (−93%), the full job finished in 15 minutes 53 seconds (−41%), and files shrank from 6.37 GiB to 1.26 GB (−80%). The workflow now covers 21 PostgreSQL databases across five Cloud SQL instances.
Run a full restore drill in an isolated environment and keep a record of the result. Restores remain separate from this export tool.
OPERATIONAL TELEMETRY
On 2026-08-14, one repository's plan ledgers contained 249 execution and verification reports.
Against 59 development reports: about 1.5 review rounds per ticket
File-scope rules actually stopped work
The interruption and contradiction procedure fired in practice
Immutable plans forced scope changes through an auditable path
Human approvals were recorded
Across the wider system, 393 sessions covered 31 tracked projects. Eight published task plans contain 75 active tickets. Operational ledgers hold 20 deployment records and 14 maintenance sessions. These are usage and governance records, not productivity measurements.
TRANSFER PATTERN
Four subsystems independently converged on the same move: centralize the index, never move the body, and distribute by symlink.
Skill bodies remain in their owning repositories while a central registry indexes and deploys them. Each service knowledge record remains beside its code while a central directory exposes one discovery point. The backend and frontend executors share one governance core. The infrastructure context Skill keeps one canonical body with parallel runtime entry points.
That pattern prevents a single-operator system from splitting into divergent copies. It also keeps the portable core free of project names: moving it to another platform would require project profile and workflow override files for each repository, not a rewrite of the core.
KNOWN BOUNDARIES
ai-frontend-developer shares the governance core but has zero recorded dispatches.This system does not remove human judgment. It puts human judgment at the points where it has the highest leverage.