case_hypotheses
Register a candidate root-cause explanation or read the hypothesis ledger for a VMware debugging case. See at a glance which theories are refuted, blocked by gaps, or still open.
Instructions
[WRITE] Register a candidate explanation, or read the ledger — step 06.
WHEN: as soon as you have a theory worth testing, and again to see where
each one stands. Pass statement to add one; omit it to just read.
Every hypothesis gets an id (H1, H2, …). Those ids are what case_record_gap(blocks=[...]) and case_submit_evidence(falsifies=[...]) refer to, and an id that was never registered is REFUSED rather than ignored — a dangling reference blocks nothing and falsifies nothing, which quietly reports a stronger case than you have.
RETURNS: {case_id, added, hypotheses, note}. Each entry carries its
status: refuted (ruled out by case_grade's rule), blocked (a gap is
in the way, with the gap id and how to close it), or open.
refuted_by lists every falsifying item; the first next step says when
more sources are needed. Status is computed from what points at the
hypothesis, never asserted.
GOTCHAS: refuted outranks blocked. Once an observation settles the question, a missing measurement no longer matters.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | The case whose hypothesis ledger this is (from case_open/case_list). | |
| statement | No | The candidate explanation, in one line. Pass it to register a new hypothesis, which is assigned the next id (H1, H2, …); omit it to read the ledger without changing it. There is no parameter for a hypothesis's status — status is computed from the evidence and gaps that point at it. |