status/query JSON: add canonical plain-language proof states #26

New issue

Closed

opened 2026-07-16 06:43:29 +00:00 by anuna-02 · 1 comment

anuna-02 commented

2026-07-16 06:43:29 +00:00

(Migrated from codeberg.org)

Summary

Add canonical plain-language proof-state fields to status and query JSON alongside the
compact +D, +d, -d, and -D tags.

Motivation from the grounded run

The compact tags are useful for experts but were repeatedly paraphrased inconsistently
as strict, defeasible, blocked, not provable, or refuted. In the final closure both
engineered-signature and its complement were non-positive, while lab-origin was
defeasibly positive and its complement was not. A single prose gloss for a negative
tag easily hid whether the cause was lack of strict proof, ambiguity, an applicable
defeater, or a proved complement.

why-not is the right detailed diagnostic, but status --json should expose the
engine's canonical meaning without requiring every client to invent a mapping.

Proposed JSON shape

Keep the existing tag for compatibility and add explicit fields, for example:

{
  "literal":"lab-origin",
  "tag":"+d",
  "proof_state":"defeasibly_provable",
  "positive":true,
  "level":"defeasible"
}

The exact names should follow the formal semantics used by Spindle/Elephant; the point
is to make that mapping authoritative and versioned rather than guessed by callers.
Where known cheaply, a separate reason_class could distinguish complement proof,
ambiguity blocking, defeated support, and missing support without replacing why-not.

Acceptance criteria

Every conclusion in status --json carries a documented canonical state in addition
to its existing tag.
The mapping is shared across status, explain, why-not, require, and what-if.
Text output can optionally show the name via --verbose without becoming noisy by
default.
Tests cover definite and defeasible proof, complementary proof, ambiguity blocking,
a defeater, and no supporting rule.
The JSON schema version or additive compatibility policy is documented.

Related: #12 and #13 improve detailed negative explanations. This issue makes the
headline state itself unambiguous to API clients.

Environment / evidence

Observed with Elephant 0.1.2. Final status artifact:
github.com/anuna-cooperative/flf-elephant-experiment@96ca63675e/runs/2026-07-16/grounded-machineB/status.json

### Summary Add canonical plain-language proof-state fields to status and query JSON alongside the compact `+D`, `+d`, `-d`, and `-D` tags. ### Motivation from the grounded run The compact tags are useful for experts but were repeatedly paraphrased inconsistently as strict, defeasible, blocked, not provable, or refuted. In the final closure both `engineered-signature` and its complement were non-positive, while `lab-origin` was defeasibly positive and its complement was not. A single prose gloss for a negative tag easily hid whether the cause was lack of strict proof, ambiguity, an applicable defeater, or a proved complement. `why-not` is the right detailed diagnostic, but `status --json` should expose the engine's canonical meaning without requiring every client to invent a mapping. ### Proposed JSON shape Keep the existing tag for compatibility and add explicit fields, for example: ```json { "literal":"lab-origin", "tag":"+d", "proof_state":"defeasibly_provable", "positive":true, "level":"defeasible" } ``` The exact names should follow the formal semantics used by Spindle/Elephant; the point is to make that mapping authoritative and versioned rather than guessed by callers. Where known cheaply, a separate `reason_class` could distinguish complement proof, ambiguity blocking, defeated support, and missing support without replacing `why-not`. ### Acceptance criteria - Every conclusion in `status --json` carries a documented canonical state in addition to its existing tag. - The mapping is shared across `status`, `explain`, `why-not`, `require`, and `what-if`. - Text output can optionally show the name via `--verbose` without becoming noisy by default. - Tests cover definite and defeasible proof, complementary proof, ambiguity blocking, a defeater, and no supporting rule. - The JSON schema version or additive compatibility policy is documented. Related: #12 and #13 improve detailed negative explanations. This issue makes the headline state itself unambiguous to API clients. ### Environment / evidence Observed with Elephant 0.1.2. Final status artifact: https://github.com/anuna-cooperative/flf-elephant-experiment/blob/96ca63675edd88cf4982449c5f78b9441c320a39/runs/2026-07-16/grounded-machineB/status.json

hugooconnor commented

2026-07-16 09:44:54 +00:00

(Migrated from codeberg.org)

Addressed in PR #28 (branch fix/cli-convergence-observability).

Addressed in PR #28 (branch `fix/cli-convergence-observability`).

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

anuna-research/elephant#26

No description provided.

Rows
Columns