Product - lossless compression

T15 Orchestrator
byte-exact lossless compression.

T15 Orchestrator is lossless compression that returns your data byte-for-byte. Every restore is SHA-256-verified, and the output carries a +1 byte never-worse floor: it is never larger than the best standard codec (worst case +1 byte). It uses SRD math partly together with standard codecs (xz, zstd, brotli) and keeps the smallest verified output.

input -> orchestrate (SRD math + codecs) -> smallest verified .pdli -> restore -> SHA-256 match

LESS WEIGHT - SAME BYTES - VERIFIED RESTORE

No lossy promises: every result must restore the original byte-for-byte, or it stays proof-only / diagnostic.

The three guarantees

Byte-exact. Verified. Never worse.

T15 Orchestrator turns any input into a restorable .pdli container and keeps only output it can prove. Three properties hold on every run.

01 Byte-exact

Lossless, byte-for-byte

Input is read as exact bytes. Restore reconstructs the original byte stream exactly - no lossy re-encode, no approximation, no hidden mutation. What you put in is what you get back.

02 Verified restore

SHA-256-verified restore

Every output is roundtripped: the restored bytes are hashed and the SHA-256 must match the original. If it does not match, it is not shipped. Integrity is checked, not assumed.

03 Never worse

+1 byte never-worse floor

Because the Orchestrator keeps the smallest verified output, it is never larger than the best standard codec - worst case +1 byte of container overhead. No fake savings on random or already-compressed data.

How the Orchestrator works

It uses SRD math partly,
together with standard codecs.

The Orchestrator does not just run one method. It applies SRD math to your data and also runs standard codecs (xz, zstd, brotli), then keeps the smallest output that passes the SHA-256 roundtrip. You get the best of both - SRD structure gains where they exist, standard-codec strength everywhere else.

01

Read exact bytes

Any file, folder or stream enters as raw bytes. Nothing is interpreted, transcoded or reordered before processing.

02

Orchestrate candidates

SRD math runs on your data alongside standard codecs (xz, zstd, brotli). Multiple reversible candidates are produced in parallel.

03

Verify each candidate

Every candidate is restored and its SHA-256 checked against the original. Only candidates that roundtrip exactly stay eligible.

04

Keep the smallest verified

The smallest verified candidate wins. Because standard codecs are in the race, the result is never larger than the best of them (worst case +1 byte).

05

.pdli container out

The output is a portable .pdli container - API-ready, CLI-ready, designed for exact restore.

06

Proof-only if not smaller

If no candidate shrinks the input honestly, the result is proof-only / diagnostic with exact restore preserved - never a fake win.

COMPRESS

input -> SRD math + codecs -> smallest verified .pdli

ROUNDTRIP

RESTORE

file.pdli -> inverse -> original bytes (SHA-256 match)

What it handles

All filetypes. Folders. Any size, streamed.

The Orchestrator works on whatever you give it - single files, whole folder trees, and arbitrarily large inputs via streaming, so memory never has to hold the entire payload at once.

All filetypes

Any bytes, any format

MP4, PDF, ZIP, JSON, logs, datasets, source, backups, raw bitstreams. The entry point is raw bytes, so format is irrelevant to correctness.

Folders

Whole directory trees

Point it at a folder and the full tree is compressed to a restorable container - structure, paths and byte content preserved exactly.

Arbitrary size

Streaming, no fixed size cap

Large inputs stream through in bounded memory. There is no requirement to fit the whole file in RAM, so size is not a limit.

Advisory surfaces

Plan before you compress.

The Orchestrator exposes advisory surfaces so you can estimate, compare and plan up front - then run with confidence.

recommend engine

Recommend engine

Suggests the best path for your input class so you start from the strongest candidate, not a guess.

savings.estimate

Savings estimate

Projects expected size reduction before a full run, so you can size storage and transfer plans.

codec.compare

Codec compare

Shows how candidates stack up side by side so the winning verified output is transparent.

noexpansion.explain

No-expansion explain

Explains the +1 byte never-worse floor and why incompressible input stays proof-only instead of expanding.

integration.plan

Integration plan

Lays out how to wire the Orchestrator into your pipeline via API or CLI without building compression in-house.

ratio.predict

Ratio predict

Predicts the achievable compression ratio for your data so expectations are set before the job runs.

Where it wins - and where it ties the best

Measured, reproducible, never exaggerated

Because the Orchestrator keeps the smallest verified output among SRD math and the standard codecs, it is never larger than the best standard codec (worst case +1 byte): it wins outright on structured classes and ties the best codec everywhere else. Not "superior to all", not "past any entropy bound".

Where it wins
  • Structured JSON / logs (about 2x tighter on structured benchmark samples)
  • Periodic and sparse binary structures
  • Specific MP4 master containers (sealed byte-exact benchmark)
Where it ties the best codec
  • Long English text: the Orchestrator selects xz, matching its size
  • Small generic text: the Orchestrator selects brotli, matching its size
  • Random / encrypted / already-compressed input (proof-only, worst case +1 byte)

FAQ

Quick answers

Is restore really byte-exact?
Yes. The Orchestrator is lossless and byte-for-byte. Every output is roundtripped and the restored bytes must SHA-256-match the original, or the result is not shipped. There is no lossy mode.
What is the +1 byte never-worse floor?
The Orchestrator keeps the smallest verified output among SRD math and the standard codecs it runs. Because the standard codecs are in the race, the result is never larger than the best of them - worst case it adds one byte of container overhead. It does not invent savings on incompressible data.
How does it use SRD math?
It uses SRD math partly, together with standard codecs (xz, zstd, brotli). SRD math captures structure the standard codecs miss; the standard codecs cover everything else. The smallest verified candidate is kept. It is not a single-method racer.
What can it compress?
All filetypes (the entry point is raw bytes), whole folders / directory trees, and arbitrarily large inputs via streaming in bounded memory. Size is not a limit.
What happens with already-compressed or encrypted files?
They take the proof-only path: exact restore is preserved and no compression win is claimed. Random or incompressible input is never presented as savings.
How do I integrate it?
Via REST API or CLI. Use the advisory surfaces - recommend engine, savings.estimate, codec.compare, noexpansion.explain, integration.plan, ratio.predict - to plan first, then run.

Compress it. Verify it. Ship it.

Drop a file in the browser, get a byte-exact .pdli, and confirm the SHA-256 roundtrip yourself. Then see the measured numbers.

No credit card - zero storage on the browser trial - SHA-256 byte-exact restore