Update to Domino Data Lab

{
  "description": "Manage model risk governance in Domino using policies, bundles, and evidence. Covers creating governance bundles, attaching model artifacts and MLflow results as evidence, progressing through policy stages, and documenting findings. Use when the user mentions governance, compliance, bundles, policies, model risk management, SR 11-7, NIST AI RMF, or audit trails.",
  "included_files": [
    {
      "relative_path": "APPROVAL-GATE.md",
      "size_in_bytes": 1567
    },
    {
      "relative_path": "AUDIT-EXPORT.md",
      "size_in_bytes": 961
    },
    {
      "relative_path": "BUNDLE-LIFECYCLE.md",
      "size_in_bytes": 6159
    },
    {
      "relative_path": "EVIDENCE-ROUND-TRIP.md",
      "size_in_bytes": 1797
    },
    {
      "relative_path": "EVIDENCE-WORKFLOW.md",
      "size_in_bytes": 8378
    },
    {
      "relative_path": "MODEL-RETIREMENT.md",
      "size_in_bytes": 741
    },
    {
      "relative_path": "MONITORING-REREVIEW.md",
      "size_in_bytes": 1255
    },
    {
      "relative_path": "ONBOARD-MODEL.md",
      "size_in_bytes": 1384
    },
    {
      "relative_path": "POLICY-LIFECYCLE.md",
      "size_in_bytes": 1140
    },
    {
      "relative_path": "READ-CONTEXT.md",
      "size_in_bytes": 1258
    },
    {
      "relative_path": "RECERTIFICATION-BULK.md",
      "size_in_bytes": 1387
    },
    {
      "relative_path": "WAIVER-EXCEPTION.md",
      "size_in_bytes": 975
    }
  ],
  "name": "domino-governance",
  "skill_md_contents": "---\nname: domino-governance\ndescription: Manage model risk governance in Domino using policies, bundles, and evidence. Covers creating governance bundles, attaching model artifacts and MLflow results as evidence, progressing through policy stages, and documenting findings. Use when the user mentions governance, compliance, bundles, policies, model risk management, SR 11-7, NIST AI RMF, or audit trails.\n---\n\n# Domino Governance Skill\n\nThis skill provides knowledge for managing model risk governance in Domino Data Lab using the Governance API.\n\n## Configuration\n\nAuthentication: https://docs.domino.ai/cloud/reference/api/domino-api-authentication . **Do not use API keys** (`X-Domino-Api-Key`, `DOMINO_USER_API_KEY`).\n\nGovernance REST lives at `/api/governance/v1/*`. Pick the base where `GET $BASE/policy-overviews` returns **HTTP 200** (try the table rows in order):\n\n| Context | Base | Authorization |\n|---------|------|----------------|\n| In-run, `DOMINO_API_PROXY` set (5.4.0+ JWT credential propagation) | `{DOMINO_API_PROXY}/api/governance/v1` | None (proxy adds starting-user JWT) |\n| In-run, no proxy, governance on platform API gateway | `{DOMINO_USER_HOST or DOMINO_API_HOST}/api/governance/v1` | Bearer from `GET http://localhost:8899/access-token` |\n| In-run but proxy or sidecar returns **404** on `/api/governance/v1/*` (gateway off or governance not registered on 8763) | `{public deployment URL}/api/governance/v1` | Bearer PAT or SA token |\n| Outside any run | `{public deployment URL}/api/governance/v1` | Bearer PAT or SA token |\n\n```bash\nGOV=\"/api/governance/v1\"\nPREFIX=\"/policy-overviews\"\n\n# 1) In-run, proxy (try first when DOMINO_API_PROXY is set)\nBASE=\"$DOMINO_API_PROXY$GOV\"\ncurl -s \"$BASE$PREFIX\"\n\n# 2) In-run, platform gateway (no proxy)\nHOST=\"${DOMINO_USER_HOST:-$DOMINO_API_HOST}\"\nTOKEN=\"$(curl -s http://localhost:8899/access-token)\"\nBASE=\"$HOST$GOV\"\ncurl -s \"$BASE$PREFIX\" -H \"Authorization: Bearer $TOKEN\"\n\n# 3) Public deployment (outside run, or 404 on 1 and 2)\nBASE=\"https://your-deployment.domino.tech$GOV\"\nTOKEN=\"$PAT_OR_SA_TOKEN\"\ncurl -s \"$BASE$PREFIX\" -H \"Authorization: Bearer $TOKEN\"\n```\n\nDo **not** scrape the JWT `iss` claim to derive the cluster URL. Prefer `DOMINO_API_PROXY` in-run when step 1 succeeds; otherwise step 2 or 3.\n\n**Takeaways for agents**\n\n1. **Proxy + no header is correct only when routing works.** `DOMINO_API_PROXY` injects JWT ([product auth doc](https://docs.domino.ai/cloud/reference/api/domino-api-authentication)); it does not add `/api/governance/v1` if guardrails is not reachable on that path.\n2. **Try steps 1 → 2 → 3** until `GET $BASE/policy-overviews` returns HTTP 200. Do not assume step 1 works on every deployment.\n3. **In-run without proxy is not “use public URL.”** Use `DOMINO_USER_HOST` (or `DOMINO_API_HOST`) plus Bearer from `http://localhost:8899/access-token` when governance is on the platform API gateway.\n4. **Public deployment URL + PAT/SA** when you are outside a run, or when step 1 or 2 returns **404** (common when the API gateway is off or governance is not registered on port 8763).\n5. **Suffix is always** `/api/governance/v1` on whichever host/base you chose ([Governance API](https://docs.domino.ai/cloud/reference/api/governance-api)).\n\n**Examples below:** Omit `Authorization` only when `TOKEN` is unset (proxy path). For gateway or public URL, set `TOKEN` and use `${TOKEN:+-H \"Authorization: Bearer $TOKEN\"}` in curl blocks.\n\n## Key Concepts\n\n### Policy (Template)\nA **policy** is a reusable governance template that defines the stages, evidence requirements, and approval gates a model must pass through. Examples: SR 11-7, NIST AI RMF, internal model risk frameworks. Policies are created by administrators in the Domino UI.\n\n### Bundle (Living Document)\nA **bundle** is the compliance document for a *specific model* in a *specific project*. It follows a policy and accumulates evidence as the model progresses through development, validation, and approval. One project can have multiple bundles (e.g., one per model version).\n\n### Evidence (Proof)\nEvidence comes in two forms:\n1. **Attachments** — Files, model versions, and reports attached to the bundle (visible in the \"Attachments\" tab)\n2. **EvidenceSet answers** — Responses to policy-defined form questions (visible in the \"Evidence\" tab for each stage)\n\n### Finding (Issue)\nA **finding** documents a problem, risk, or concern discovered during review. Findings have severity levels and are tracked as part of the audit trail.\n\n## Related Documentation\n\nWhen automating a specific flow, open the matching workflow file first instead of re-deriving from the 8-step section below.\n\n- [BUNDLE-LIFECYCLE.md](./BUNDLE-LIFECYCLE.md) - Stage sequences, creating bundles, progressing stages\n- [EVIDENCE-WORKFLOW.md](./EVIDENCE-WORKFLOW.md) - Attachment types, evidence submission, findings\n- [ONBOARD-MODEL.md](./ONBOARD-MODEL.md) - Onboard a model into governance\n- [EVIDENCE-ROUND-TRIP.md](./EVIDENCE-ROUND-TRIP.md) - Evidence round-trip with findings\n- [APPROVAL-GATE.md](./APPROVAL-GATE.md) - Approval gate automation\n- [MONITORING-REREVIEW.md](./MONITORING-REREVIEW.md) - Monitoring-driven re-review\n- [RECERTIFICATION-BULK.md](./RECERTIFICATION-BULK.md) - Periodic recertification (bulk)\n- [AUDIT-EXPORT.md](./AUDIT-EXPORT.md) - Regulatory audit export\n- [POLICY-LIFECYCLE.md](./POLICY-LIFECYCLE.md) - Policy lifecycle and rollout\n- [MODEL-RETIREMENT.md](./MODEL-RETIREMENT.md) - Model retirement\n- [WAIVER-EXCEPTION.md](./WAIVER-EXCEPTION.md) - Exception or waiver\n- [READ-CONTEXT.md](./READ-CONTEXT.md) - Read governance context for downstream use\n\n## Governance API Reference\n\nAll endpoints are under `$BASE` (`/api/governance/v1`). See [Configuration](#configuration) for when to send `Authorization`.\n\n| Endpoint | Method | Purpose |\n|----------|--------|---------|\n| `/policy-overviews` | GET | List available policy templates |\n| `/bundles` | POST | Create a new governance bundle (optional inline `attachments`) |\n| `/bundles/{bundleId}` | GET | Inspect bundle: stages, attachments, status |\n| `/bundles/{bundleId}` | PATCH | Update bundle `state`, primary `stage` name, or `policyId` |\n| `/bundles` | GET | List all bundles (filter by `projectId`) |\n| `/bundles/{bundleId}/attachments` | POST | Attach evidence after create (model versions, reports) |\n| `/bundles/{bundleId}/stages/{stageId}` | PATCH | Update stage **assignee** only (not stage completion) |\n| `/rpc/submit-result-to-policy` | POST | Answer policy evidence questions |\n| `/rpc/compute-policy` | POST | Recompute policy for a bundle (returns `ComputedPolicy`) |\n| `/results/latest` | GET | Latest artifact results (`bundleID` query param) |\n| `/rpc/publish-approval-event` | POST | Publish approval workflow events (approve, reject, etc.) |\n| `/policies/{policyId}` | GET | Get full policy with evidenceSet IDs |\n| `/findings` | POST | Create a finding (issue) during review |\n| `/findings/{id}` | PUT | Update a finding (including `status`) |\n\n**Bundle fields:** `stage` (string) is the primary policy stage name; set it with `PATCH /bundles/{id}` to move the workflow. `state` (`Active`, `Archived`, `Complete`) is bundle lifecycle; set when archiving or completing the bundle. `currentStageInfo.status` (`NotStarted`, `InProgress`, `Done`) is stage progress on GET only, not writable on `/stages/{stageId}`.\n\n## Standard 8-Step Governance Workflow\n\nFollow these steps when setting up governance for a model:\n\n### Step 1: Discover Policies\n```bash\ncurl -s \"$BASE/policy-overviews\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"}\n```\nReview available templates. Note the `id` of the policy you want to use.\n\n### Step 2: Get the Project ID\nThe project ID is needed to create a bundle. Use the `DOMINO_PROJECT_ID` environment variable (available inside Domino) or look it up via the gateway API.\n\n### Step 3: Create a Bundle\nAttachments may be inline on `POST /bundles` or added later via `POST /bundles/{id}/attachments`. Prefer inline when creating and attaching a model in one step (see [ONBOARD-MODEL.md](./ONBOARD-MODEL.md)).\n\n```bash\ncurl -X POST \"$BASE/bundles\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"projectId\": \"your-project-id\",\n    \"name\": \"My Model v1.0\",\n    \"policyId\": \"policy-uuid\"\n  }'\n```\nSave the returned `id` as your `BUNDLE_ID`.\n\n### Step 4: Inspect the Bundle\n```bash\ncurl -s \"$BASE/bundles/$BUNDLE_ID\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"}\n```\nThis reveals the policy's stage structure, attachments, and approval status. **Note**: This does NOT return evidenceSet IDs — see Step 6 for how to discover those.\n\n### Step 5: Attach Evidence\nSee [EVIDENCE-WORKFLOW.md](./EVIDENCE-WORKFLOW.md) for full details. Two attachment types are supported:\n\n```bash\n# Attach a registered model version\ncurl -X POST \"$BASE/bundles/$BUNDLE_ID/attachments\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} -H \"Content-Type: application/json\" \\\n  -d '{\"type\":\"ModelVersion\",\"identifier\":{\"name\":\"model-name\",\"version\":5},\"name\":\"Display Name\"}'\n\n# Attach a project file (notebook, report, etc.)\ncurl -X POST \"$BASE/bundles/$BUNDLE_ID/attachments\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} -H \"Content-Type: application/json\" \\\n  -d '{\"type\":\"Report\",\"identifier\":{\"branch\":\"main\",\"commit\":\"abc...\",\"source\":\"git\",\"filename\":\"path/to/file\"},\"name\":\"Display Name\"}'\n```\n\n### Step 6: Answer Evidence Questions (EvidenceSet)\n\nEvidence questions are the interactive forms shown in the Domino UI under each stage's \"Evidence\" tab. They are defined in the policy YAML as `evidenceSet` items.\n\n#### 6a. Discover EvidenceSet IDs\n\nEvidenceSet IDs are NOT in the bundle response. Fetch them from the **policy** endpoint:\n\n```bash\ncurl -s \"$BASE/policies/$POLICY_ID\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"}\n```\n\nThe response contains `stages[]` → `evidenceSet[]` → `artifacts[]` with full UUIDs for each evidence item and artifact.\n\n#### 6b. Submit Answers\n\n```bash\ncurl -X POST \"$BASE/rpc/submit-result-to-policy\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"bundleId\": \"bundle-uuid\",\n    \"policyId\": \"policy-uuid\",\n    \"evidenceId\": \"evidence-uuid\",\n    \"content\": {\n      \"artifact-uuid\": \"value\"\n    }\n  }'\n```\n\n**Key details**:\n- Use `policyId` (NOT `policyVersionId`)\n- `evidenceId` is the evidence set item UUID (from policy response)\n- `content` is a map of `{artifactId: value}`\n- For **radio/textinput/textarea/select**: value is a string\n- For **checkbox/multiSelect**: value is an array of strings\n- Submit one artifact at a time per call, or multiple artifacts in the same evidence item together\n\n### Step 7: Progress Stages\nStage completion is driven by evidence, approvals, and workflow events, not by `status: Complete` on the stage subresource. `PATCH /bundles/{bundleId}/stages/{stageId}` only updates **assignee**. After evidence and approvals:\n\n1. Publish approval events (see [APPROVAL-GATE.md](./APPROVAL-GATE.md)):\n```bash\ncurl -X POST \"$BASE/rpc/publish-approval-event\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"bundleId\": \"bundle-uuid\",\n    \"policyId\": \"policy-uuid\",\n    \"projectId\": \"project-uuid\",\n    \"eventType\": \"RequestApproved\",\n    \"approvalId\": \"approval-uuid\"\n  }'\n```\n\n2. When the policy requires explicitly setting the primary stage name, use `PATCH /bundles/{bundleId}`:\n```bash\ncurl -X PATCH \"$BASE/bundles/$BUNDLE_ID\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"stage\": \"Next stage name from policy\"}'\n```\n\nRe-fetch the bundle and verify `stage` (primary stage name) or `currentStageInfo.status` (`NotStarted`, `InProgress`, `Done`) changed before continuing. Details: [BUNDLE-LIFECYCLE.md](./BUNDLE-LIFECYCLE.md).\n\n### Step 8: Document Findings (if any)\n```bash\ncurl -X POST \"$BASE/findings\" \\\n  ${TOKEN:+-H \"Authorization: Bearer $TOKEN\"} -H \"Content-Type: application/json\" \\\n  -d '{\n    \"bundleId\": \"bundle-uuid\",\n    \"policyVersionId\": \"policy-version-uuid\",\n    \"name\": \"Finding title\",\n    \"description\": \"Detailed description...\",\n    \"severity\": \"High\",\n    \"approver\": {\"id\": \"org-uuid\", \"name\": \"model-gov-org\"},\n    \"assignee\": {\"id\": \"user-uuid\", \"name\": \"username\"}\n  }'\n```\nClose or resolve with **PUT** `/findings/{id}` and `\"status\": \"Done\"` (not `PATCH` or `state: Closed`). See [EVIDENCE-ROUND-TRIP.md](./EVIDENCE-ROUND-TRIP.md).\nGet the `policyVersionId` and user/org IDs from the bundle response (Step 4).\n\n## Viewing in Domino UI\n\nAfter creating a bundle and attaching evidence, the bundle is visible in the Domino UI:\n**Project** > **Govern** > **Bundles** > click the bundle name\n\nThe UI shows:\n- **Overview** — Stage progression and classification\n- **Evidence** tab (per stage) — Interactive forms for evidenceSet questions\n- **Attachments** tab — Files, model versions, and reports\n- **Findings** tab — Documented issues with severity\n\n## After compute-policy (polling)\n\n`POST /rpc/compute-policy` returns **200** with a `ComputedPolicy` body. Freshness lives on artifact results, not a single top-level flag.\n\n1. Call `POST /rpc/compute-policy` with `bundleId` and `policyId`.\n2. Poll `GET /results/latest?bundleID={bundleId}` (and optional `policyID`, `artifactID`) until the artifacts you care about have `isLatest: true`, or inspect `results[].isLatest` on the compute response when present.\n3. Only then treat evidence as current for submit, stage advance, or read-context output.\n\nReuse this loop in every workflow that calls `compute-policy` (see [ONBOARD-MODEL.md](./ONBOARD-MODEL.md), [EVIDENCE-ROUND-TRIP.md](./EVIDENCE-ROUND-TRIP.md), [READ-CONTEXT.md](./READ-CONTEXT.md)).\n\n## Known platform behaviors\n\nShort pointers; full gotchas live in the workflow files linked under [Related Documentation](#related-documentation).\n\n| Behavior | Where |\n|----------|--------|\n| Governance base URL (proxy vs gateway vs public on 404) | [Configuration](#configuration) |\n| Verify stage actually advanced after approvals | [APPROVAL-GATE.md](./APPROVAL-GATE.md), [BUNDLE-LIFECYCLE.md](./BUNDLE-LIFECYCLE.md) |\n| Poll after `compute-policy` | [After compute-policy (polling)](#after-compute-policy-polling) |\n| `ModelVersion` attachment `identifier.name` | [EVIDENCE-WORKFLOW.md](./EVIDENCE-WORKFLOW.md), [ONBOARD-MODEL.md](./ONBOARD-MODEL.md) |\n| Draft vs submitted evidence (`isLatest`) | [EVIDENCE-WORKFLOW.md](./EVIDENCE-WORKFLOW.md) |\n| Close findings (PUT + `status`, new evidence first) | [EVIDENCE-ROUND-TRIP.md](./EVIDENCE-ROUND-TRIP.md) |\n| Policy version retire / upgrade on bundles | [POLICY-LIFECYCLE.md](./POLICY-LIFECYCLE.md) |\n| Multi-bundle per model | [READ-CONTEXT.md](./READ-CONTEXT.md) |\n| Policy attach RPC vs nucleus guardrails proxy | [POLICY-LIFECYCLE.md](./POLICY-LIFECYCLE.md) |\n| Open findings before stage advance | [EVIDENCE-ROUND-TRIP.md](./EVIDENCE-ROUND-TRIP.md) |\n\n## Documentation Reference\n\nOpenAPI and route discovery: [API-SPECS.md](../domino-api-intro/API-SPECS.md) (public routes section).\n\n**Governance API base:** See [Configuration](#configuration) (proxy, in-run gateway + access-token, or public URL + PAT/SA when governance 404s on the sidecar). Do not scrape the JWT `iss` claim.\n\n**Product docs:**\n- Governance overview: https://docs.domino.ai/cloud/platform-capabilities/features/governance\n- Governance API: https://docs.domino.ai/cloud/reference/api/governance-api\n\nFor governance workflows and pitfalls, see [Related Documentation](#related-documentation).\n"
}