How Insurixa runs in production, on GitLab and Google Cloud.

ArchitectureThree places, one loop.

Insurixa watches what upstream projects retire (Kubernetes APIs, GitLab CI/CD features, OpenTelemetry names) and keeps a service current without a person in the loop. Code decides what is retired and whether a fix is mechanical. GitLab Duo agents handle only the changes that need judgement. Every change ships through the same nine stages a person's change would.

The full flow diagram, with the three entry points and the three flows, is on the overview.

Lifecycle coverageAll nine stages, each doing something specific.

Touching a stage counts; Insurixa makes each one do work that only makes sense for this problem. Job names are the real ones in .gitlab-ci.yml.

The deploy stage sits between configure and monitor: deploy-staging, validate-staging, deploy-production, deploy-firebase and pages.

AgentsCode decides. Agents judge. Both are measured.

Guards that save credits and stop loops

• Each flow's first agent answers SKIP for events that are not its job; a router ends the flow before any other model call.
• The repair flow skips a failed pipeline that is not for the merge request's latest commit, and stops after two attempts so a person looks.
• When upstream has no replacement (NO_REPLACEMENT), it explains on the merge request instead of deleting or inventing.

Evaluation on real upstream files

Six files copied unchanged from Argo CD, kubernetes/examples and go-redis, one merge request each. scripts/agent_eval.py grades the final file with code, never a model.

6 of 6, each in one attempt. Full table: eval/agent/RESULTS.md. Six cases is a small sample; it shows the behaviours, not a rate.

Google CloudWhat runs on Google Cloud, and why there.

Why this split works

• Zero idle cost. Hosting and Firestore's free tier cost nothing between pipelines; nothing is a server waiting for traffic.
• No server between users and data. The playground runs in the browser and reads production directly; the ledger view reads Firestore directly. Fewer moving parts to secure or keep up.
• Same region as the runners. Firestore sits in us-east1, where GitLab's hosted runners run, which is also the grid factor the carbon estimate uses.
• Everything as code. firebase.json, firestore.rules, deploy/gcp/firebase-setup.sh and the CI jobs are in the repository.

SecurityKeyless identity, end to end.

• No JSON key, no long-lived secret in CI variables. The variables hold only names: provider, service account, site.
• The provider's attribute condition accepts only gitlab-ai-hackathon/transcend-october-2026/43322398/showcase on main; a fork or another branch gets nothing.
• The same pattern secures the other external calls: the Vault login in secrets-sync uses an ID token (run 6), and insurixa-safe-fix never runs for merge requests from forks.
• Agents run in GitLab's sandbox with no network and may change only the paths their flow allows.

deploy-firebase:
  id_tokens:
    GCP_ID_TOKEN:
      aud: https://gitlab.com
  script:
    - python scripts/build_site.py public
    - python scripts/firebase_deploy.py "$FIREBASE_SITE" public

Read straight from Google Cloud by your browser. Older records were backfilled from the GitLab API; new ones are written by the ledger job.

Production readinessBuilt to run against production, not a demo.

EfficiencyCompute and model calls only where they change the outcome.

Measured with the SCI method (SCI = ((E × I) + M) per R), runner time from the GitLab API, and Cloud Carbon Footprint's GCP coefficients for us-east1:

• A change shipped by the agent path costs about 2.30 gCO2e; by code alone 1.93 gCO2e, 16% less and with zero model calls.
• SKIP guards end irrelevant sessions in a median 45 s instead of 183 s: 75% less runner time.
• Scheduled pipelines only plan and monitor: 64% less runner time than a full pipeline.
• Static hosting and in-browser checks mean no always-on server for docs, playground or ledger.
• Each pipeline's own carbon is now in the ledger above, so the trend is visible, not a one-off claim.

Method, sources and limits: docs/sustainability.md. Model inference is excluded because no public per-request energy data exists.

PositioningHow it compares.

Insurixa complements dependency bots: they move versions forward; Insurixa makes sure what you wrote against the old version still works.

Adopt itThree steps for a platform team.

1. Include the component:

   include:
     - component: gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43322398/showcase/insurixa@main
       inputs:
         paths: "src/"
         kubernetes_paths: "deploy/"
         kubernetes_version: "1.33"
         gitlab_ci_paths: ".gitlab-ci.yml"

2. Enable the three flows from .gitlab/duo/flows/ in AI › Flows, with their triggers (work item created, pipeline failed).
3. Optional: run deploy/gcp/firebase-setup.sh once for keyless publishing and the ledger.

Before any of that, paste a file into the playground to see what it would find.

Path BRequirements, with evidence.

Honest limitsWhat it does not do yet.

• The scanners read files, not rendered Helm output, and the OpenTelemetry pack finds quoted names, not names behind language constants.
• The checkout service runs on Render's free tier, which sleeps when idle; Cloud Run is wired but needs billing.
• The agent evaluation is six cases: enough to show the behaviours, not to claim a success rate.
• Carbon numbers exclude model inference, which has no public per-request energy data.