What is backward verification in context compression?

Backward verification is the ability to prove, after compression, which source bytes an agent was shown and to recover them exactly. Most compression preserves forward continuity, meaning enough state to keep working, but discards the link between a claim and the evidence supporting it. Entroly records exact UTF-8 byte offsets plus recomputable source and fragment SHA-256 digests for every fragment, so an omitted span can be returned as the original bytes and checked independently.

How is Entroly's context compression reversible?

Entroly stores content-addressed recovery material rather than discarding what it omits. A Context Receipt records each fragment's path, byte range and digests, and a recovery handle returns the exact bytes for that range. Recovery verifies the digest and byte length before returning anything, so a corrupt or substituted store fails loudly instead of returning plausible-looking content.

Can a compressed context be tampered with undetected?

No. The commitment covers the canonical bytes of the context, so altering a single character changes the digest and verification fails. A shared Rust verifier owns commitment validity, and the Python and Node runtimes delegate to it rather than reimplementing the rule and drifting apart.

Does Entroly send code to a third party in order to compress it?

No. Indexing, selection, compression, receipts and recovery run locally. In proxy mode the selected prompt is sent to the LLM provider the user configured, and no outbound analytics are enabled by default.

Backward verification, not just forward continuity

Entroly compresses context without asking you to trust the compressor.

Most context compression keeps an agent working. It does not let you prove afterwards which source bytes the model actually saw. Entroly records exact UTF-8 byte offsets and recomputable SHA-256 digests for every fragment, so an omitted span can be returned as the original bytes and checked by anyone holding the source.

Direct answer: Entroly is a local-first context compression layer whose reductions are reversible and independently verifiable. Every selection emits a Context Receipt recording what was selected, what was omitted, and the digests needed to recover and check those omissions.

Forward continuity is not backward verification

Compression for agents is usually optimised for forward continuity: retain enough state that the next step succeeds. That is a different property from backward verification: establishing, after the fact, which evidence supported which claim. A summary can read well and still drop the one span that justified a decision, with nothing in the transcript revealing it.

The distinction is an active research topic. Work on verifiable context governance, on governance receipts bound to individual agent actions, and on formal frameworks for verifiable LLM context compression each describe this shortfall from a different direction. Entroly is a working implementation of the property that literature specifies.

How the link between claim and evidence survives compression

Property	Mechanism
Exact addressing	Each fragment records its source path and an exact UTF-8 byte range. Slicing the untouched source with that range reproduces the fragment text.
Independent checking	Source and fragment SHA-256 digests are recomputable by anyone holding the source, without running Entroly.
Recoverable omission	Omitted spans are content-addressed rather than discarded. A recovery handle returns the original bytes, verified against the recorded digest before anything is returned.
Tamper evidence	The commitment covers the canonical bytes of the context. Altering one character changes the digest and verification fails.
One owner of validity	A shared Rust verifier decides commitment validity. Python and Node delegate to it rather than reimplementing the rule and drifting apart.

Measured, not asserted

These properties are checked by benchmarks whose artifacts are committed to the repository. Each records its corpus rules, pinned baseline, harness digest and stated limitations, so a reader can audit the claim rather than take it.

5,117 / 5,117

Fragments whose recorded byte range slices their own text back out of the untouched source, across 1,104 files.

13 / 13

Public SDK recovery probes whose recovered bytes matched their source span exactly and whose digests validated.

Fails closed

A tampered or non-canonical context is rejected outright rather than accepted with a warning.

These measure fragment fidelity and digest recomputability. They do not measure retrieval recall, generated-answer correctness, latency, or provider cost, and the corpus is one pinned revision of this repository. The artifacts state those limits directly rather than leaving them to be inferred.

What this is not

Entroly does not promise a fixed savings percentage: reduction depends on repository size, workload, token budget, provider, pricing, cache behaviour and baseline. It does not establish that a model's answer is true; verification evaluates whether a claim is supported by the evidence supplied. It does not replace your model or your agent runtime.

Check it yourself

pip install entroly
entroly compress path/to/file.json --json    # receipt, including a recovery digest
entroly recover sha256:...                   # the exact bytes that digest commits to
entroly verify-claims                        # bounded local installation check

Recovery verifies the digest and the byte length before returning anything, so a substituted store fails loudly rather than handing back content that merely looks plausible.