Proof Portal

Projects

jsonparser

ProbeLabs23 findings · 123 requirements

The fastest JSON parser for Go — formally verified with ReqProof (real library, master).

All requirements
RequirementSYS-REQ-034SystemReview

When Delete is called with a provided path, the addressed target is absent, and the input is otherwise usable for deletion, the parser shall return the original byte payload unchanged.

This requirement changed after its last recorded review, so approval is stale. Automated checks pass and 2/2 obligations are satisfied.
PriorityshallTypeguaranteeCategoryfunctionalComponentparserAssuranceEFindingsnone open

Specification

The requirement exactly as authored — its complete prose text and, where present, the formal FRETish sentence it compiles to.

Description

When Delete is called with a provided path, the addressed target is absent, and the input is otherwise usable for deletion, the parser shall return the original byte payload unchanged.

FRETish formula
the parser shall always satisfy !delete_path_is_provided | delete_target_exists | delete_input_is_unusable_for_requested_path | delete_preserves_input_when_target_missing
View full formal model

Rationale & tags

Why this requirement exists, and how it is categorised.

Missing-target preservation is a distinct API outcome from successful deletion and from malformed-input robustness.

decompositiondeleteedge-case

Verification & provenance

How this requirement was checked: the review trail, edit history, and the machine-analysis status terms (each ⓘ explains what it means).

Assurance levelE
Formalizationvalid
Realizabilityrealizable
Vacuitychecked_ok
Strategyfretish

Review

Status
approved
Reviewer
Leonidbugaev
Reviewed
Apr 23, 2026, 00:00 UTC

History

Created
Apr 14, 2026, 15:45 UTC · Codex · AI agent
Modified
Jul 26, 2026, 14:54 UTC · Created via CLI

Change history

Every recorded revision of this requirement's source file — newest first, each with its commit message and the diff for that change.

Every recorded revision of this object's source — newest first, each with the commit message and its file-level diff.

Obligations

What this requirement must witness to be considered satisfied — the required evidence, and the tests that discharge each one.

2 obligations · 2 discharged

Browse the catalogue
Discharged

Behavior for unusual but valid input combinations.

If it were violatedLow

Delete on an object whose only key is the absent target rewrites the payload (e.g. drops a sibling key in cleanup), silently corrupting the document.

Discharging evidence1/1 required witnessed
  • nominalrequiredpresent
    Covered by 1 test
Discharged
If it were violatedLow

Delete on a missing nested path descends into the intermediate structure and corrupts a sibling by deleting the wrong key, producing a wrong document.

Discharging evidence1/1 required witnessed
  • nominalrequiredpresent
    Covered by 1 test

Formula evidence

The formal formula behind this requirement, the variables it is written over, and the tests that exercise it (each term is explained inline).

FRETish formula

the parser shall always satisfy !delete_path_is_provided | delete_target_exists | delete_input_is_unusable_for_requested_path | delete_preserves_input_when_target_missing

Variables

NameTypeDirectionDescription
delete_path_is_providedTrue when Delete is called with at least one path segment.
delete_target_existsTrue when the addressed Delete target exists and can be isolated in the input JSON.
delete_input_is_unusable_for_requested_pathTrue when Delete cannot safely resolve the requested path because the input is malformed, truncated, or otherwise unusable for that deletion request.
delete_preserves_input_when_target_missingTrue when Delete leaves the input unchanged because the addressed target is missing in otherwise usable input.

Witnesses· 5 scenarios total

  • TestMCDC_SYS_REQ_034_Row1_TriggerFalse
    exercises 1 condition scenario
  • TestMCDC_SYS_REQ_034_Row2_InvariantViolation
    exercises 1 condition scenario
  • TestMCDC_SYS_REQ_034_Row3_TargetExistsUsable
    exercises 1 condition scenario
  • TestMCDC_SYS_REQ_034_Row4_UnusableInput
    exercises 1 condition scenario
  • TestDelete
    exercises 1 condition scenario

MC/DC truth table· 5 rows

Each row assigns the formula's conditions (T/F) and shows the Result— the formula's value for that input row, not a test pass/fail. A row proves a condition when flipping only that condition flips the outcome. The test that covers each row is linked.

Covereda test exercises this rowExempteda reviewed mcdc:ignoreNo-actionfalse-result row satisfied by designUncoveredneeds a covering test
#delete_input_is_unusable_for_requested_pathdelete_path_is_provideddelete_preserves_input_when_target_missingdelete_target_existsResultProvesCovering test
1FFFFTdelete_path_is_provided
2FTFFFdelete_input_is_unusable_for_requested_path
3FTFTTdelete_target_exists
4FTTFTdelete_preserves_input_when_target_missing
5TTFFTdelete_input_is_unusable_for_requested_path

Its place

This requirement shown inside its trace neighbourhood — the parents it satisfies, the code and tests attached to it, and its findings.

Loading graph…

Trace evidence

The concrete artifacts linked to this requirement — implementing code, verifying tests, documents, and the findings raised against it.

Impact

Blast radius — if you change this requirement, what else may need re-checking, and what it in turn depends on.

If you change this

Requirements
0
Files
1
Tests
6
At-risk contracts
0

Files to re-check (1)

  • parser.goparser.go

Tests to re-run (6)

  • empty_key_path_test.goempty_key_path_test.go
  • mcdc_spec_witnesses_test.gomcdc_spec_witnesses_test.go
  • obligation_evidence_test.goobligation_evidence_test.go
  • parser_test.goparser_test.go
  • property_test.goproperty_test.go
  • reference_oracle_test.goreference_oracle_test.go

What this rests on

Changes

Semantic changes that move or scope this requirement — the intended work touching it. Each links to the full change.

Discussions

Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.

Sign in to discuss this with the proof team.Sign in