Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaServicesBuild InitiativesUser Acceptance Testing
User Acceptance Testing

User Acceptance Testing

Block · Pipeline stage in Build Initiatives

📖About & Usage

About

User Acceptance Testing is the final gate that confirms an initiative's reviewing work actually does what was asked — and crucially, WHO performs it depends on WHO triggered the initiative.

Manual lane (today): initiatives Orion drives — both his planner runs and his bypass work — are accepted by Ninad himself. Operator-directed work has no deterministic failing trigger to replay, so a human signs it off; nothing closes until Ninad confirms it.

Automated lane (today): when an initiative was triggered by a concrete, replayable failure, UAT is the act of re-exercising that exact failure and confirming it now passes — no human needed. For Albus's bypass work, which is always triggered by a specific pipeline failure, UAT means the triggering failure is rectified and then the failed execution is RE-RUN as part of acceptance — it passes only if that rerun now succeeds. For Hermione's planner executions, which arise from a failed scheduled process, UAT means the process that failed is RE-RUN — the initiative is accepted only if that rerun completes successfully.

Future autonomous lanes: as more agents gain authority to trigger initiatives, they will own their own UAT the same way — if Leo or Noah triggers an initiative, that agent performs the UAT autonomously, replaying whatever it was that triggered the work and confirming the fix holds.

The principle is uniform: automated UAT re-runs the precise thing that caused the initiative and accepts only on a clean rerun; manual UAT is reserved for operator-directed work that has no such trigger to replay. UAT currently has no droids of its own — it is performed by the triggering agent (or by Ninad).

Where it fits

This is one stage of the Build Initiatives service. The owner and the agents who run it are listed under the team below, and the other blocks of the service are linked at the bottom of this page.

🛠️Team & droids

Elrond Block owner

Owns the UAT block and the sign-off lane, and decides which UAT lane applies to an initiative based on who triggered it. For Orion-initiated work he runs the Stale-Review Auto-Closer, which auto-accepts any of Orion's initiatives left in reviewing more than 2 days as a recorded no-objection operator sign-off through the status router, so they close cleanly with the close-hooks. He also holds the manual lane open for operator-directed work that has no failing trigger to replay.

Albus

Runs UAT for his own bypass initiatives, which are always triggered by a specific pipeline failure. His acceptance test is to confirm the triggering failure is rectified and then RE-RUN the failed execution (via his troubleshooter / resume watcher); it passes only if the rerun now succeeds, otherwise it is sent back rather than closed.

Hermione

Runs UAT for the initiatives SHE triggered — the ones born from a failed scheduled process. Her acceptance test is to RE-RUN the exact process that failed (through her scheduler / process monitor); the initiative is accepted and closed only if that rerun now completes successfully. If it still fails, the work is bounced back for more fixing rather than closed.

Leo

Runs autonomous UAT for the blueprint / sizing initiatives he triggers. His acceptance test re-runs the blueprint or sizing check that triggered the work and confirms the fix holds before the initiative closes. Autonomous lane — engages as Leo gains trigger authority.

Noah

Runs autonomous UAT for the migration initiatives he triggers. His acceptance test re-exercises the migration step or validation that triggered the work and confirms it now passes; only on a clean re-run does the initiative close. Autonomous lane — engages as Noah gains trigger authority.

👤Owner

Elrond · Head of Engineering

🧱Other blocks in Build Initiatives

Filing an initiativeSprint PlanningPlanning an initiativePlanning the execution of a stepExecuting the stepReviewing the stepReviewing the initiativeJudging the initiativeMonitoring the executionReplanning the initiativeTroubleshooting the initiativeSupport