How it works

Principles, not mechanism.

This page explains what ByteLite must achieve and how it holds itself to account. The methods that produce a representation are proprietary and are not published here.

What can be reviewed from outside

People ask what they are allowed to look at. This is the answer: six categories that can be examined without me handing over the mechanism. It is a review framework, not a description of how ByteLite operates internally.

Public review framework: source, result, evidence, status, limitations and review.
  • Source — the declared inputs.
  • Result — the observable output.
  • Evidence — the supporting artifacts.
  • Status — the current state, labelled.
  • Limitations — the boundaries I already know about.
  • Review — technical examination of all of the above.

01

Determinism

The same input and build produce the same output, every time.

ByteLite’s core encoding and decoding mechanism is deterministic. It does not rely on probabilistic inference or confidence scores to decide what the original data probably was.

02

Exact reconstruction

The original must come back byte for byte, or the attempt failed.

  1. Originalfile
  2. Representationstructure
  3. Reconstructedfile
hash(original) hash(reconstructed)

Identical — the roundtrip passes

Anything other than identical — the roundtrip fails, and no reduction may be claimed

ByteLite compares the rebuilt file against the original. There is no partial credit: a file that comes back almost the same is a failure, not a smaller file.

This is the precondition for everything else. A representation that loses even one byte is not a smaller file — it is a different file.

03

A self-contained final artifact

Everything the decoder needs is intended to live inside the artifact itself — not in a companion file that travels beside it.

Development proof scaffold

Current development

  1. Source
  2. ByteLite research engine
  3. Structural representation
  4. Explicit reconstruction evidence
  5. Exact verification

Reconstruction evidence is written out where it can be inspected, replayed and falsified. It is a research scaffold.

All required reconstruction information included

Final target

  1. Source
  2. ByteLite
  3. Self-contained artifact (.root)
  4. ByteLite decoder
  5. Exact source

One artifact carries everything the decoder needs. Nothing essential lives outside the counted representation.

During development, ByteLite uses explicit reconstruction evidence so each transformation can be inspected and verified. This is a research scaffold, not the intended final artifact. The final ByteLite architecture is intended to include all information required for exact reconstruction inside the self-contained counted representation.

This is the clearest difference between where ByteLite is today and where it is going. Development deliberately writes reconstruction evidence out in the open so the architecture can be inspected, replayed and falsified. That scaffold is a research tool. The final artifact must stand alone.

04

Complete counting

A reduction counts only when the complete artifact is smaller — everything included.

  • Primary representation the represented content itself
  • All required reconstruction information everything that restores the exact original
  • Required artifact state anything else the artifact must carry to decode

Complete ByteLite artifact

Any compression claim is based on the complete artifact.

Complete artifact < original input

Counted reduction

Complete artifact is the same or larger

No counted reduction

Illustrative only. Not a claimed compression ratio. A reduction only counts when everything needed to rebuild the file is included in the measurement. Moving cost somewhere that is not counted is not a reduction.

This is the discipline that separates a measurement from a claim. If part of what the decoder needs lives somewhere that was not counted, the number is not real.

05

Proof before claim

Two questions decide whether ByteLite may claim anything at all.

  1. Can the original be reconstructed exactly?

    No Fail. Do not claim.

    Yes Continue

  2. Is the complete artifact smaller?

    No Preserve the original. No reduction claim yet.

    Yes Continue

  3. Counted lossless reduction
Both gates must pass before anything may be claimed. Where they do not yet pass, the honest result is to preserve the original and say so. This governs what ByteLite claims today — it is not a limit on what the architecture is being built to achieve.

Target: ByteLite is being developed with the target of producing a smaller exact, self-contained representation for every source file.

Current state: The mechanism required to establish that target is still under active development and validation. The gate above governs what ByteLite is willing to claim today; it is not a statement about how far the architecture is meant to reach.

06

What ByteLite is not

The boundary, stated as refusals. None of these cards says what is used instead — that is the part that stays private.

  • Not a generative AI system

    ByteLite does not reconstruct data by guessing what was probably there. Reconstruction is not inference.

  • Not lossy compression

    If exact reconstruction cannot be proven, the result does not qualify. There is no partial credit.

  • Not "close enough"

    "Looks the same" and "means the same thing" are not accepted as equivalent to the original bytes.

  • Not probabilistic entropy coding

    ByteLite is not built around probabilistic entropy coding. Its research target is a deterministic, recursively self-contained representation architecture.

  • Not independently validated or production-qualified

    Those gates are not complete, and ByteLite is not presented as though they were.

Different by design

The column on the right is a list of priorities I chose, not a list of results anyone has certified. It says what ByteLite is built to be, which is a different claim from what it has been proven to do.

A common probabilistic approach compared with ByteLite priorities: deterministic operation, explicit constraints, evidence tracked, auditable artifacts.
  • Deterministic operation instead of probabilistic outputs.
  • Explicit constraints instead of confidence scores.
  • Evidence tracked instead of limited explainability.
  • Auditable artifacts instead of statistical behaviour.

Technical details

Recursive processing, at a high level

The complete representation ByteLite produces is itself a candidate for further reduction. Whether another pass is taken is decided by the same accounting rule as the first: it counts only if the complete artifact gets smaller. A pass that does not improve the complete artifact is not taken.

Intrinsic convergence, as a target

The intended behavior is that recursion stops because the work is finished, not because a counter ran out. No iteration cap, timeout or "good enough" threshold decides the outcome. Demonstrating that convergence is an open gate, not a completed result.

Verification

Every result is checked by rebuilding the original and comparing it against the input. The size reported is counted from the finished artifact rather than estimated from a model of it.

What is not published

The internal rules and formats that produce a representation are trade secrets and are not disclosed on this site, and neither is the way required reconstruction information is intended to become compact. The public material describes what ByteLite must prove, not how it is built.

If it works

Why a smaller representation can matter.

  • Storage fewer bytes held at rest
  • Transfer fewer bytes moved between systems
  • Handling fewer bytes passed through processing steps
Reducing the representation of data can potentially reduce the infrastructure resources associated with storing or moving that representation. Whether it does, and by how much, would have to be measured for a given workload — ByteLite does not claim savings in any of these categories today.
What has been proven Licensing