Prover Consult Agent

​

Availability

Genesis seeds the non-editable Prover Consult system agent during startup with the stable bot_id Consult — never renamed, because it keys threads, loadouts and every recorded ruling. Its direct tool loadout contains only data_connector_tools; callers reach it through request_consult_ruling in the source_contract_tools group, which the pinned seats (Consult itself, the Adjudicator, the Court-Attorney) deliberately do not carry. The constitution Consult works under is packaged with Genesis and recorded by name and content hash when the agent is initialized. Snowflake metadata-backed installs also seed this seat; see Snowflake metadata cache storage for where it is stored and how startup handles seed failures.

​

What a ruling is, and is not

A caller brings the open finding, exactly one dispute shape — an explanation, a reading of the ticket, or a claim of a check defect — and the implementer’s position in its own words. Everything else is hydrated from the finding ledger, which is the point: a caller that could describe the finding could describe it favourably. Consult returns a verdict about the merits — ACCEPTED_SUPPORTING (the ticket licenses the position, and it survives an elimination probe) or REJECTED — plus INVALID_DOCKET for a request that must be repaired before it can be ruled on. The result carries the thread, the round number, the rationale, the probes actually run, any mechanical guard, and a spec_flag when Consult found an axis the ticket leaves undetermined. Two properties are worth stating plainly:

• Consult is never shown an oracle. No verifier outcome, no benchmark score, no prior review decision reaches it. Its ruling must be grounded in the ticket and in measurable estate data.
• It cannot escalate by choosing to. Escalation is mechanical: a dispute has a bounded number of rounds, and the call that reaches the bound records the escalation — with the implementer’s values standing and every ruling attached — after which further calls on that measurement are refused. A new position appeals in the same thread.

A spec_flag is a record stored on the finding for a person to read. It names whether the ticket left an axis undetermined or over-specified a check — opposite repairs — along with the verbatim ticket sentence it turns on. It is not sent to a spec author, opens no handoff, and never reopens a sealed specification. For the call itself — parameters, defaults, cost and the full result shape — see the source_contract_tools reference.

​

How a ruling reaches the board

estate_char.consult.apply_mode decides what a recorded ruling does, and it is read when the ruling is applied. The shipped default is human_approval. An unreadable or unrecognised configuration reads as advisory, not as the shipped default — the failure a wrong guess must never cause is a finding leaving the open count on an unratified agent ruling. Seeding also requires the ruling library itself: estate_char.rulings.enabled must be true and estate_char.rulings.fairness_hold false. Those switches outrank the apply mode. If either blocks the overlay, or the finding carries no ambiguity class, the ruling is recorded as a finding event only. Rejections, escalations, invalid dockets and an acceptance Consult never probed all record without seeding a direction. Approving or declining a recorded ruling is a person’s act. See Roles and approvals for what that signature attests to.

​

Cost and safety

One call spends one full Consult bot turn plus read-only SELECT probes against the named delivered and build databases, and can take seconds to minutes. Do not call it speculatively, in a loop, or for a finding you have not read.