JSON/XML Size & Depth Analyzer

Inspectable records

Ledger state

The current ledger marks this instrument verified with errata that must be applied at binding time.

Area

Computing & Information

Tranche

tranche-5

Evidence ID

t5-108

Ledger rows

1

No ledger note is attached.

Review findings

The instrument concept is viable, but the specification lacks exact definitions for encoding, serialization/minification, depth, counting, percentage calculation, and parser-error behavior. The empty honest_label is a concern: the product should disclose that byte size and minified size depend on encoding and serializer policy, and that XML whitespace handling is not universally semantics-preserving.

Formula and scope findings

• The formula description, "tree traversal counting nodes, depth, and serialized length," is not sufficiently defined to reproduce the outputs.
• Maximum-depth convention is unspecified: it is unclear whether the root has depth 0 or 1, and whether scalar JSON values, arrays, object properties, XML text nodes, attributes, comments, and processing instructions contribute to depth.
• The count metric is ambiguous: JSON may count keys, all values, or all tree nodes; XML may count elements only or also attributes, text nodes, comments, and processing instructions.
• Raw byte size requires a specified character encoding; character count is not byte count for non-ASCII input.
• Minified serialization is undefined, especially for XML. Removing whitespace can alter XML text content, and canonicalization choices for attribute quoting, entities, declarations, comments, and empty-element syntax affect size.
• The size-reduction percentage formula is not explicitly stated. The expected conventional formula is 100 * (raw_bytes - minified_bytes) / raw_bytes.

Unit assumptions

• The test vectors assume UTF-8 encoding and byte size means the number of UTF-8 encoded bytes.
• For these vectors, JSON minification removes insignificant JSON whitespace while preserving values and uses compact separators.
• For these vectors, XML minification removes only whitespace between tags; whitespace inside text content is preserved.
• Depth is assumed to be one-based, with the document root at depth 1; JSON scalar values do not increase depth beyond their containing structure.
• JSON count means object keys only; XML count means element nodes only. XML attributes and text nodes are excluded.
• Size reduction is assumed to be 100 * (raw_bytes - minified_bytes) / raw_bytes.

Boundary hardening

BREAK_CLAIMED · SELF_FLAGGED

Empty input produces raw size zero and makes the minification-reduction formula undefined as 0/0; the analyzer must reject it before calculation. The specification also leaves byte encoding and depth conventions unstated, which can produce different reported values for Unicode input.

Errata and corrections

Tranche errata

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "format": "JSON",
    "raw_text": "{\"a\": 1, \"b\": [true, null]}",
    "encoding": "UTF-8"
  },
  "expected_outputs": {
    "raw_bytes": 27,
    "minified_bytes": 23,
    "max_depth": 2,
    "key_or_element_count": 2,
    "size_reduction_percent": 14.8148148148
  },
  "working": "Raw UTF-8 text is ASCII, so bytes = characters = 27. Minified form is {\"a\":1,\"b\":[true,null]} and has 23 bytes. Depth: root object = 1; nested array = 2; maximum = 2. Key count: a and b = 2. Reduction = 27 - 23 = 4 bytes. Percentage = (4 / 27) * 100 = 14.8148148148%."
}

Related workflows

No source-defined multi-instrument workflow membership is recorded.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json · VERIFIED_WITH_ERRATA
• evidence-tranche5/tranche5-results.json
• BOUNDARY_HAZARD_CATALOG.json