Get Sufficiency
get_sufficiencyDetermine if a single control's assertions sufficiently cover its description; get a sufficient/insufficient verdict with named missing clauses and required evidence.
Instructions
Sufficiency verdict for a single control: whether its submitted assertions collectively cover every aspect of the control. Read-only.
Returns the LLM sufficiency status and reasoning for one control, evaluated server-side from the current assertion set (no CI round-trip). Use this for a focused check on one control after submitting assertions; for the whole-model rollup with tier1/tier2 pass/fail counts and drift/misalignment details across all controls, use get_verification_report instead. A verdict carries a freshness of fresh | stale | pending beside its status: stale means the control description, the assertion set or the rules the verdict was computed under have moved since. A stale read with no re-evaluation already queued queues one, so calling again shortly does converge; a stale read that is already waiting adds nothing. For the whole-model rollup, which also refreshes stale controls on read, use get_verification_report.
This is the surface that explains a control stuck at
verification_status: "partially_verified". Returns status
("sufficient" | "insufficient" | "pending"; staleness rides in
freshness, not in the status) and, when
insufficient, a details breakdown naming EACH uncovered clause of
the control description and what evidence would close it — a concrete
work list, not a score. A claim that carries a soundness_tier
reports its weakest clause's tier: a control is proven no more strongly
than the thinnest clause it rests on, so the composed tier is read as
that bound and never as a control-level pass. Act on it by submitting
the named assertions with submit_assertions; if a clause is
uncloseable because the control describes a mechanism the system does
not actually use, that is a signal to refine_control instead of
manufacturing evidence.
The per-clause work list is served by get_control_work_order:
where the order names a required class for a clause,
required_evidence carries the clause id to put in covers, the
clause text and its quantifier, the required_class that closes it
and a suggested_submission skeleton whose <...> placeholders
you replace before submitting. It is stated by-construction first — for
a for-all clause the required class is
[by_construction, sound_over_approximation], so prefer
typed_boundary (declare the type the sinks accept and its
constructors), else sink_default_deny (declare the sinks that
realise the clause, the safe forms, a reviewed allowlist). When
evidence of the wrong class is bound, class_mismatch is set: the
evidence is the wrong CLASS, not merely incomplete, and more of it
will not help. An attestation covers an existential clause and never
a for-all one; the only legitimate non-mitigation exit for a for-all
clause is a risk acceptance or a not-applicable disposition.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| model_id | Yes | ID of the threat model. | |
| control_id | Yes | ID of the control (e.g., "CTRL-01"). | |
| server_version | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||