Remediation and skills

A remediation is a governed release, not a prompt pasted into production. It links a Failure Atlas family to an exact candidate, repository review, independent evaluation, signed artifact, installation receipts, and rollback ancestor.

Release path

  1. Select an evidence-backed failure family.
  2. Generate the smallest candidate change and causal theory.
  3. Open a child remediation branch and pull request against the affected agent's permanent control branch.
  4. Run historical replay, regression checks, security checks, and non-source held-out evaluation.
  5. Obtain organization approval when required.
  6. Build the deterministic bundle from the approved commit and sign it with KMS.
  7. Install it on matching local, managed ADK, and BYOK endpoints.
  8. Collect activation receipts and compare matched post-release trajectories.
  9. Roll back one agent independently if its canary fails.

The first organization release requires approval. The portal may establish an auto-update policy for later R0-R2 releases after all gates pass. R3-R4 and destructive changes remain organization-admin approved.

GitHub structure

Each organization has one private Dharma control repository. Each source repository maps to one permanent agents/<slug>-<hash> branch. A coordinated remediation campaign has one parent record and independently reversible child targets. Remediation pull requests contain control artifacts, not a mirror of customer source code.

Held-out evidence

Managed automation requires at least 20 non-source held-out trajectories before a candidate can be eligible for promotion. Historical replay is useful but is not a substitute for held-out evidence.

API operations

  • GET /api/v1/orgs/{orgId}/agent-fabric/failures
  • GET /api/v1/orgs/{orgId}/agent-fabric/remediations
  • GET/POST /api/v1/orgs/{orgId}/agent-fabric/remediations/{targetId}
  • GET/POST /api/v1/orgs/{orgId}/agent-fabric/skills
  • GET /api/orgs/{orgId}/managed-remediation/candidates

Write operations require skills:write, an idempotency key, the required gate evidence, and explicit approval where the risk policy requires it.

Rollback

Rollback restores the signed ancestor for one agent and records endpoint receipts. In-flight work stays pinned to its starting bundle. A rollback must not silently alter another agent in the same organization.