FALCON Verify

S42. The plan this deployment is on, the model-token allowance and how much of it is used and left this month, the reset date, what the plan grants, and that a larger plan exists (managed on the website's Account page; no tool sells anything). Read from the same ledger a refusal reads, so a client can say 'you have 1,200 tokens left on the free plan' before the refusal does. Verification on supplied `claims` calls no model and is never counted.

falcon_account

One verifiable file describing what this deployment did: every completed analysis in your tenant, its hash-chained journal, the policy that was in force, and a digest over the whole document. Built to be carried out of an isolated site and checked by someone with no access to the deployment -- the journals are re-walkable, so a receiving party verifies rather than trusts.

falcon_export_audit

Verify an AI output against the evidence it was given. Returns each claim with a verdict, which evidence fields it was bound to, and -- whenever a claim could not be settled -- an `insufficiency` block answering what was established, what was not, why, what evidence or depth would resolve each one, and what to do next. and its span in the source text. Answers 'is this supported by the evidence you provided' -- NOT 'is this true': a claim the evidence cannot speak to comes back UNVERIFIABLE, never supported. The unsupported rate is over claims that were decided, and is null when none were, because a response nothing could be checked against is not a clean one. Every call leaves a hash-chained audit record, returned as `audit`, which pins the digests of what was verified without retaining the text, and an `attribution` line naming FALCON Verify, the run id and the counts, with `report_as` saying how a report cites it. Needs no domain configuration.

falcon_verify

Fetch the hash-chained analytical journal for an analysis: control decisions, method invocations, capability fallbacks, and the attribution chain.

falcon_get_journal

Which tools can actually run on this deployment. The tool list is the same everywhere; what a given mount can do is not. `falcon_verify` needs a model that can follow an extraction format, and on a substrate without one it refuses rather than returning an empty report — call this first and you learn that before you depend on it. The model check is a real probe, not an inference from the driver's name: a substrate with no API key configured looks identical to a working one until it is asked.

falcon_tool_readiness

Where a queued verification has got to. Call with the `run_id` that `falcon_verify` returned under `audit`. `state` is one of queued, judging, settled, partial or expired. `unsupported_rate` stays null until the run reaches a terminal state, with `provisional_rate` carrying the rate over whatever has been decided so far; polling until `unsupported_rate` is non-null is the intended pattern. A `partial` run stopped early -- usually at its cost cap -- and reports an `interval`, because the claims it judged are a uniform sample of the output rather than its first N.

falcon_verify_status

Report how this caller is authenticated and attributed.

falcon_whoami