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 an operationally pure read — it changes nothing and records nothing — 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.
evaluated_atThe RFC 3339 UTC instant this listing filtered validity windows at. Present in every state.

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, effective_from, effective_until, 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.

Rules are served as authoredDirect link to Rules are served as authored

The listing applies the same validity filter as the decision-bearing tools — a rule outside its window at evaluated_at does not appear, and each returned rule shows its own effective_from / effective_until. It does not apply purpose or actor substitution: what you see is what was authored. A usage_guidance rule reads here exactly as written, even where an authorize_use call would resolve it differently for a particular purpose or a particular token role.

That is the point of this tool. It answers "what do our policies say about this asset", not "what would this agent be told". For the second question, call authorize_use.

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), unresolved_published_target (with unresolved_targets details), or not_currently_effective (rules exist for this asset and scenario, but none is inside its validity window at evaluated_at). 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": "master",
    "schema": "public",
    "table": "employees"
  },
  "scenario_key": "access.read"
}

Response:

{
  "state": "answered",
  "asset": {
    "database": "master",
    "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": "employee-data-access v1 role_grant:spec.accessControl.deniedRoles:public:deny -> deny on master.public.employees",
      "parameters": {
        "action": "deny",
        "role": "PUBLIC"
      },
      "scope": {
        "database": "master",
        "schema": "public",
        "table": "employees",
        "column": null
      },
      "provenance": {
        "policy_id": "accef000-0000-4000-8000-000000000041",
        "policy_version_id": "accef000-0000-4000-8000-000000000042",
        "policy_name": "Customer 360 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.