AfterCare

Aftercare turns GitLab Duo investigations into human-approved repairs—and verifies that affected customers are back in business.

Comment

Inspiration

A green pipeline does not mean every customer has recovered.

A subscription bug can be fixed and deployed while paying customers remain locked out because their stored access state is still wrong. Engineers then have to identify affected accounts, distinguish valid repairs from dangerous guesses, and prove the recovery worked.

We built AfterCare to close that gap between shipping a fix and restoring the customer experience.

What it does

AfterCare turns a GitLab Duo investigation into a reviewable, human-approved repair with verified customer outcomes.

Our demo follows a synthetic subscription incident involving five accounts. Two paying customers need their access restored. A cancellation must remain respected, an already-working account must stay untouched, and conflicting records require manual review.

The recovery workflow:

  1. GitLab Duo investigates repository and event evidence, then creates a merge request containing a bounded repair package.
  2. AfterCare rehearses that package inside a rollback boundary, checking the outcome without committing changes.
  3. A human approves the exact plan. Approval is bound to the package and evidence snapshot.
  4. AfterCare executes the approved repair atomically and records a receipt.
  5. Fresh access checks verify the customer outcomes. Repeating the repair returns the same receipt without additional writes.

The public demo uses a recorded, merged Duo-authored package and gives each visitor an isolated session.

How we built it

We built AfterCare around GitLab Duo, GitLab CI/CD, Node.js, SQLite, and Google Cloud Run.

A custom GitLab Duo recovery flow investigates the incident and proposes the repair through a merge request. A separate hosted Duo run validated the runtime, branch tests, and exact-package rehearsal.

The Node.js and SQLite repair engine handles evidence checks, rollback rehearsals, approval binding, transactional execution, and recovery receipts. The interface brings investigation, review, approval, repair, and verification into one workflow.

We also used GitLab’s CI Expert to inspect pipeline evidence and consult Orbit’s knowledge graph. Security Analyst reviewed session isolation and approval boundaries, helping us strengthen the implementation.

Our pipeline runs behavioral tests, a synthetic repair rehearsal, SAST, secret detection, and a security gate. The serverless demo runs on Google Cloud Run with scale-to-zero, a maximum of one instance, and isolated visitor sessions.

Challenges we ran into

The hardest challenge was defining when an automated repair should refuse to act. A cancelled subscription and conflicting event history cannot be treated like a straightforward renewal failure.

We also needed to prevent approval from becoming stale. Binding approval to the exact plan and evidence snapshot ensures that changed evidence requires a new rehearsal and approval.

Runtime compatibility created another obstacle. The original Duo runner could not execute the SQLite tests with its Node.js version. We configured a compatible runtime and validated the package in a subsequent hosted Duo run.

Finally, making the demo public required isolating visitor state so one person’s approvals, repairs, and resets could not affect another person’s session. We also resolved two SAST findings through implementation changes rather than dismissing them.

Accomplishments that we're proud of

We completed a recovery backed by actual GitLab Duo investigation, a merged repair request, hosted validation, and passing pipeline evidence.

The demo restores both eligible customers while preserving the cancellation, existing access, and manual-review boundary. It also demonstrates rollback rehearsal, evidence-bound approval, atomic execution, and repeat-safe recovery.

Our final pipeline passes 20 behavioral tests and the repair rehearsal, with zero reported SAST or secret-detection findings.

Most importantly, the workflow ends by checking whether customers can access their workspaces. A successful repair command alone is not enough.

What we learned

AI-assisted recovery needs explicit boundaries, inspectable evidence, and a clear division between proposing a repair and authorizing its execution.

We learned that a merge request is a useful bridge between AI investigation and operational action. It gives the proposed repair a concrete artifact that people can inspect, test, and review.

We also learned to distinguish three separate outcomes: the code is fixed, the repair executed successfully, and the customer actually recovered. Reliable recovery requires checking all three.

What's next for AfterCare

We want to connect AfterCare to more incident sources and customer systems, extending the approach beyond subscription access.

Next steps include stronger identity-based approvals, durable audit storage, additional repair policies, and production-ready persistence beyond the demo’s temporary sessions.

We also plan to support fresh Duo investigations for new incidents and richer verification checks against real customer-facing services.

Our guiding principle will stay the same: AI proposes, humans authorize, and customer outcomes prove the repair worked.

Built With

Share this project:

Updates

Submission history