T15 Orchestrator - documentation

T15 Orchestrator docs
compress, restore, verify.

How to compress and decompress files, folders and archives, how the byte-exact restore with SHA-256 verification works, what the +1 byte never-worse floor guarantees, and how streaming handles large inputs. Sizes from 0 B to 50 MB are measured; very large jobs are honest about staging.

compress -> smallest verified .pdli -> decompress -> original bytes (SHA-256 match)

Every restore must reproduce the original byte-for-byte and SHA-256-match, or the result stays proof-only / diagnostic.

01 - The two operations

Compress and decompress.

There are two operations. Compress reads your input as raw bytes, orchestrates SRD math together with standard codecs (xz, zstd, brotli), and writes the smallest output that passed the SHA-256 roundtrip into a portable .pdli container. Decompress reads that container and reconstructs the original bytes exactly.

COMPRESS

input -> .pdli

The Orchestrator never ships a candidate it cannot restore. Only candidates whose restored bytes SHA-256-match the original stay eligible; the smallest of those wins.

# compress a single file
pdli compress report.csv -o report.csv.pdli

# compress a folder (whole tree)
pdli compress ./project -o project.pdli

# verbose: show candidate sizes and the winner
pdli compress data.bin -o data.pdli --explain
DECOMPRESS

.pdli -> original bytes

Decompress applies the inverse and writes back exact bytes. The SHA-256 of the restored output is checked against the value sealed at compress time.

# restore a single file
pdli decompress report.csv.pdli -o report.csv

# restore a folder tree to a directory
pdli decompress project.pdli -o ./restored

# verify without writing (hash-only check)
pdli verify project.pdli

COMPRESS

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

ROUNDTRIP

DECOMPRESS

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

02 - Workflow

Files, folders and archives.

The same compress / decompress pair handles a single file, a whole directory tree, or a re-archive of many inputs. Structure, paths and byte content are all preserved exactly.

File

Single file

Any one file enters as raw bytes - format is irrelevant to correctness. The output is one .pdli container that restores to the identical file.

pdli compress movie.mp4 \
  -o movie.mp4.pdli
pdli decompress movie.mp4.pdli \
  -o movie.mp4
Folder

Folder tree

Point at a directory and the full tree - subfolders, paths and per-file bytes - is captured into one container and restored to the same layout.

pdli compress ./logs \
  -o logs.pdli
pdli decompress logs.pdli \
  -o ./logs-restored
Archive

Archive / many inputs

An existing archive (ZIP, tar) is just bytes, so it compresses like any file. Already-compressed archives commonly take the proof-only path - see the never-worse floor below.

pdli compress backup.tar \
  -o backup.tar.pdli
pdli compress *.json \
  -o bundle.pdli
What is preserved: exact byte content of every file, the directory structure and relative paths, and a sealed SHA-256 per item. What is not changed: nothing is transcoded, reordered or lossily re-encoded at any step.

03 - Integrity

Byte-exact restore, SHA-256 verified.

Integrity is checked, not assumed. At compress time the original is hashed; at restore time the reconstructed bytes are hashed again and the two SHA-256 values must match. A mismatch is a hard failure - the result is never silently shipped.

At compress

Seal the hash

The SHA-256 of the original input is computed and recorded in the container so the expected value travels with the data.

At restore

Re-hash & compare

The reconstructed bytes are hashed and compared to the sealed value. Equal means byte-exact; unequal means the restore is rejected.

Self-check

Verify it yourself

Run a standard SHA-256 over the original and the restored output with your own tool - the digests match. Trust is reproducible.

Verify the roundtrip yourself
# 1. hash the original
sha256sum report.csv

# 2. compress, then decompress
pdli compress report.csv -o report.csv.pdli
pdli decompress report.csv.pdli -o report.restored.csv

# 3. hash the restored output - digests must be identical
sha256sum report.restored.csv

# or let the Orchestrator confirm it:
pdli verify report.csv.pdli   # -> OK: SHA-256 match (byte-exact)

04 - The floor

The +1 byte never-worse floor

Because the Orchestrator keeps the smallest verified output among SRD math and the standard codecs, the result is never larger than the best standard codec - worst case it adds one byte of container overhead. It does not invent savings on incompressible data.

What you get
  • Smaller than the best codec on structured inputs
  • Equal to the best codec when there is no extra structure to exploit
  • At most +1 byte of overhead in the worst case
What you never get
  • No fake savings on random / encrypted / already-compressed data
  • No silent expansion - incompressible input stays proof-only
  • No unverified output - everything ships only after a SHA-256 match
Proof-only path: when no candidate honestly shrinks the input, the Orchestrator does not pretend. It keeps exact restore and labels the result proof-only / diagnostic rather than reporting a win. The never-worse guarantee is about size, not about turning incompressible data into a saving.

05 - Sizes & streaming

0 B to 50 MB measured. Larger via streaming.

Inputs from an empty 0-byte file up to 50 MB are measured directly. Beyond that, large inputs stream through in bounded memory so the whole payload never has to sit in RAM at once.

Small

0 B - 1 MB

Edge cases first: a 0-byte file restores to a 0-byte file. Tiny inputs honor the never-worse floor and verify in milliseconds.

Medium

1 MB - 50 MB

The measured working range. Candidates are orchestrated and SHA-256-verified end to end on the whole input.

Large

> 50 MB

Streaming kicks in: the input flows through in bounded-memory chunks, so size is not a hard limit on the box that runs it.

Honest note on very large jobs: a multi-hundred-gigabyte or terabyte-scale input is not a single in-place click. It needs staging - adequate scratch space, time, and a streaming run plan. We say so up front rather than implying instant terabyte compression. The byte-exact and SHA-256-verified guarantees still hold; the difference is operational setup, not the math.

06 - FAQ

Quick answers

How do I compress and decompress?
Two operations. pdli compress <input> -o out.pdli writes the smallest verified container; pdli decompress out.pdli -o <path> reconstructs the original bytes. Both work on files, folders and archives.
Is the restore really byte-exact?
Yes. The Orchestrator is lossless and byte-for-byte. The SHA-256 sealed at compress time must match the hash of the restored bytes, or the restore is rejected. There is no lossy mode.
Can I verify the SHA-256 myself?
Yes. Hash the original and the restored output with any standard SHA-256 tool - the digests are identical. pdli verify out.pdli performs the same check for you.
What is the +1 byte never-worse floor?
The Orchestrator keeps the smallest verified output among SRD math and the standard codecs it runs, so the result is never larger than the best of them - worst case +1 byte of container overhead. It does not fabricate savings on incompressible data.
What size inputs are supported?
From a 0-byte file up to 50 MB is measured directly. Larger inputs use streaming in bounded memory, so size is not a hard cap on the running machine.
What about a 1 TB input?
It is supported via streaming, but honestly it needs staging - scratch space, time and a run plan - not a single instant click. The byte-exact and SHA-256-verified guarantees still hold; the rest is operational setup.
Is there a separate Pedulli product for verification and reasoning?
Yes. SRD is a separate Pedulli product focused on verifier-gated, authorized-scope verification and free-form reasoning. T15 Orchestrator covers only lossless compression and orchestration.

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 read the benchmarks.

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