Skip to main content

inspect_governance_rules

inspect_governance_rules lists the governing rules for one asset: every deployed instruction decision from the current deployment publication that applies to the asset, optionally narrowed to one canonical scenario. Each rule is summarized from allow-listed published fields — decision, reason, scenario, enforcement mode, resolution provenance, policy provenance — never from raw policy prose. It is read-only and advisory, and clients that present hyphenated tool names can call it as inspect-governance-rules.

When to useDirect link to When to use

Use this tool to browse or audit the rule set itself:

  • "What rules apply to employees, and why do they apply?" — including how each rule reached the asset (direct selector, collection membership, or taxonomy match).
  • To review enforcement posture: which rules are enforceable versus advisory, and their enforce / monitor / advisory enforcement modes.
  • To gather decision_id values for follow-up explain_why calls.

Versus get_decision_context: both tools read the same instruction rows and cite the same record shape, but get_decision_context additionally derives an effective_decision (the single winning verdict) and structured business_context. inspect_governance_rules returns the ranked rule list only — use it when you want the rules, and get_decision_context when you want the rules plus the bottom line. For a verdict on one concrete proposed use, use authorize_use instead.

InputDirect link to Input

ParameterTypeRequiredDescription
assetobjectYesReference to a governed table or column.
asset.databasestringYesNormalized database name, as shown in the catalog.
asset.schemastringYesNormalized schema name.
asset.tablestringYesNormalized table name.
asset.columnstringNoNormalized column name. Omit it for a table-level reference.
scenario_keystringNoA canonical scenario key (for example access.read) to narrow the read to one scenario. Non-canonical values are rejected with invalid_parameters.

The schema is strict: unknown keys are rejected with invalid_parameters. A table-level reference returns rules scoped to the table and to its columns.

OutputDirect link to Output

A successful call returns one JSON payload discriminated by state. When the state is answered:

FieldDescription
state"answered".
assetThe resolved asset scope; column is always present and null for table-level.
scenario_keyThe scenario filter that was applied, or null for all scenarios.
rulesThe active instruction rules (at least one), in rank order: column-level before table-level, then more explicit resolution (selector over collection over taxonomy), then higher priority, then the more restrictive decision.
publicationCurrent-publication provenance: publication_id, published_at.

Each entry in rules is the same instruction record shape get_decision_context returns in decisions: decision_id, instruction_key, instruction_family, scenario_key, scenario_lane, category, priority, weight, enforcement_mode, decision, decision_reason, parameters (the extracted policy parameters, served verbatim — keys inside follow the policy YAML authoring convention), scope, provenance (policy_id, policy_version_id, policy_name, version_number), primary_resolution_source, resolution_paths, conflict_status, conflict_group_id, and conflicts_with. See get_decision_context for the field-by-field description.

There is deliberately no effective_decision field: this tool describes the rule set without collapsing it to a verdict.

Answer statesDirect link to Answer states

All three typed states are possible:

  • answered — as above.
  • review_required — published rules exist but must not be presented as a settled listing. reason_code is conflicted_published_state (rules in scope conflict; the payload adds a conflict group carrying every opposing source) or decision_requires_review (the top-ranked rule is an explicit require_review). The payload keeps rules and adds next_actions.
  • not_enough_published_state — reason_code is no_current_publication, no_published_instruction_state (no published rule covers this asset and scenario — never returned as an empty rule list), or unresolved_published_target (with unresolved_targets details). The payload carries the asset echo, a fixed message, and next_actions.

See Typed answer states for the full model and reason-code semantics.

ExampleDirect link to Example

Request arguments:

{
  "asset": {
    "database": "acmecloud_demo",
    "schema": "public",
    "table": "employees"
  },
  "scenario_key": "access.read"
}

Response:

{
  "state": "answered",
  "asset": {
    "database": "acmecloud_demo",
    "schema": "public",
    "table": "employees",
    "column": null
  },
  "scenario_key": "access.read",
  "rules": [
    {
      "decision_id": "accef000-0000-4000-8000-000000000040",
      "instruction_key": "role_grant:spec.accessControl.deniedRoles:public:deny",
      "instruction_family": "role_grant",
      "scenario_key": "access.read",
      "scenario_lane": "platform",
      "category": "enforceable",
      "priority": 2,
      "weight": 1,
      "enforcement_mode": "enforce",
      "decision": "deny",
      "decision_reason": "acme-employee-access v1 role_grant:spec.accessControl.deniedRoles:public:deny -> deny on acmecloud_demo.public.employees",
      "parameters": {
        "action": "deny",
        "role": "PUBLIC"
      },
      "scope": {
        "database": "acmecloud_demo",
        "schema": "public",
        "table": "employees",
        "column": null
      },
      "provenance": {
        "policy_id": "accef000-0000-4000-8000-000000000041",
        "policy_version_id": "accef000-0000-4000-8000-000000000042",
        "policy_name": "AcmeCloud employee data access",
        "version_number": 1
      },
      "primary_resolution_source": "selector",
      "resolution_paths": [{ "source": "selector", "ref": null }],
      "conflict_status": "none",
      "conflict_group_id": null,
      "conflicts_with": []
    }
  ],
  "publication": {
    "publication_id": "accef000-0000-4000-8000-000000000001",
    "published_at": "2026-07-16T00:00:00.000Z"
  }
}

Without the scenario_key filter, the same asset returns its full rule set across all scenarios (the sample workspace returns 25 rules for employees).

Limits and notesDirect link to Limits and notes

  • scenario_key must be canonical. Free-text intents are not accepted here; there is no proposed_use or use parameter on this tool. See Scenarios for the vocabulary, or take valid keys per asset from discover_context.
  • Summaries only. Rules are composed from allow-listed published instruction fields. Raw policy source is never returned; read the policy itself in the app if you need the authored YAML.
  • Conflicts are never ranked away. A conflict anywhere in the applicable rules turns the listing into review_required with every opposing source attached — the tool will not present conflicted state as a settled answer.
  • Metering. Every call that passes input validation consumes one MCP call before any read; over quota, the call fails with quota_exceeded. Calls rejected with invalid_parameters are not metered.
  • Error codes. asset_not_found (the reference does not resolve in the workspace's current catalog — a cross-workspace reference is indistinguishable from not found), invalid_parameters, read_failed, plus the shared unauthorized, auth_unavailable, rate_limited, quota_exceeded.