Typed answer states

Metatate's answer model is an honesty contract. Every decision-bearing MCP tool reads only the deployed instruction decisions of your workspace's current deployment publication — and when that published state cannot support a decision, the tool says so with a typed answer state and a stable reason code. It never fabricates a decision, and it never dresses up an empty read as governance.

The three states

State	Meaning	Reason codes
answered	Current published instruction rows are sufficient for the asset and scenario.	—
review_required	Published rows exist, but the answer explicitly requires review or is conflicted.	decision_requires_review, conflicted_published_state
not_enough_published_state	Published state is missing, unresolved, or insufficient.	no_current_publication, no_published_instruction_state, unresolved_published_target, scenario_unresolved

These are answer states, not errors. Malformed inputs and infrastructure failures surface separately as typed error codes (invalid_parameters, asset_not_found, and so on).

Why zero rows is "not enough published state"

If no published instruction rows apply to an asset or scenario, the answer is not_enough_published_state with reason code no_published_instruction_state — by design. It is not an empty pass ("nothing forbids this"), and it is not an invented review decision. Absence of published governance is a fact about your workspace, and the tool reports that fact so your team can publish the missing coverage. Each not_enough_published_state payload carries next_actions, and unresolved-target answers include the specific unresolved_targets.

Decision values

When an answer cites instruction rows, each row's decision is one of eight values: allow, deny, mask_full, mask_partial, require_review, conditional, log_only, retain. A conditional decision means the use is allowed once specific structured conditions (such as approval or anonymize-first) are met, rather than collapsing to a bare require_review — it appears most often in destination-resolved transfer answers, and can also derive from row-access and AI-governance rules.

Deterministic ranking

When multiple published rows apply, the effective decision is derived deterministically — same published rows in, same answer out. The first difference wins:

1. Specificity — column-level beats table-level; within a level, how the asset entered scope: selector, then collection, then taxonomy.
2. Priority — higher instruction priority first.
3. Restrictiveness — deny > mask_full > mask_partial > require_review > conditional > retain > log_only > allow.
4. Stable instruction key — a lexicographic tiebreak, so ordering never depends on read order.

Conflicts are never ranked away: if any row in the winning tier is conflicted, the answer is review_required with reason code conflicted_published_state, carrying every opposing source.

Chaining with decision IDs

Every cited instruction row carries a decision_id, and decision answers surface the winner's decision_id at the top level. Pass any of them to explain_why ({"kind": "decision", "decision_id": "<uuid>"}) to get that exact record's evidence. Answers also carry publication provenance — publication_id and published_at — so you always know which publication produced them.

What publishes state

Answers change only when your workspace publishes a new current deployment publication from its deployable instructions. See Deployments for how publishing works, and the MCP server overview for the tools that read it.