Prečo som nechcel ďalší ZIP: ako vznikol formát .ithz

Keď sa povie nový archívny formát, prvá otázka býva jednoduchá: Je menší než ZIP?

Pri .ithz bola pôvodná otázka iná: Dokáže archív vysvetliť, prečo dáta usporiadal a komprimoval práve takto? A urobí rovnaké rozhodnutie aj vtedy, keď súbory prečíta v inom poradí alebo použije viac pracovných vlákien?

Táto otázka nevznikla pri navrhovaní archívu. Vznikla oveľa skôr, v kernelových experimentoch ITHKOR. Pri skúmaní konečných informačných modelov som narazil na problém, ktorý vyzeral najprv ako drobný technický detail: lokálne rozhodnutie mohlo závisieť od toho, v akom poradí sa systémom prechádzalo.

Ak algoritmus stlačí alebo zahodí detail hneď pri prvom lokálnom signále, jeho rozhodnutie môže byť rýchle. Nemusí však byť stabilné. Iný priechod tým istým systémom môže uvidieť udalosti v inom poradí a vytvoriť iný plán.

To bol moment, z ktorého neskôr vyrástol .ithz: nie ako pokus premenovať existujúcu kompresiu, ale ako pokus preniesť jednu výskumnú zásadu do práce so skutočnými dátami.

Najprv pozoruj štruktúru. Až potom, na jasnom kontrolnom bode, rozhodni, čo a ako komprimovať.

Experiment, ktorý zmenil smer

Kľúčový bol checkpointový stres test C3b. V malých grafových modeloch porovnával dva spôsoby výberu:

• budgeted visit reagoval priebežne na lokálne signály počas návštevy prvkov;
• layer checkpoint najprv zhromaždil informáciu za celú kanonickú vrstvu a rozhodnutie uzavrel až potom.

V širokom kontraste mal priebežný budgeted_visit výsledok 0 z 24 nastavení, ktoré by prešli všetkými bránami. layer_checkpoint prešiel 24 z 24. Hlbší checkpointový test potom potvrdil stabilitu v 12 z 12 sledovaných kombinácií rodiny a kanála.

Tieto čísla nehovoria, že bol objavený nový fyzikálny zákon. Išlo o konečný diagnostický experiment. Ukázal však veľmi praktickú vec: ak má kompresia závisieť od štruktúry a nie od náhody vykonávania, lokálna špička nie je dobrým miestom na okamžitý záväzný rez.

V archíve má tento problém celkom obyčajnú podobu. Predstavte si priečinok s tisíckami súborov. Jeden program ich číta podľa názvu, druhý odzadu, tretí paralelne. Ak si kompresor vyberie základ pre podobné súbory jednoducho podľa toho, ktorý uvidí prvý, výsledný plán môže byť pri každom behu iný.

Súbory sa síce po rozbalení vrátia správne, ale archív už nie je ľahko reprodukovateľný. Je ťažšie porovnať dve zostavy, auditovať rozhodnutie alebo zistiť, či rozdiel vznikol zmenou dát, alebo iba iným poradím práce.

Preklad z teórie do archívu

Z kernelového výsledku vznikla archívna hypotéza ITHZ-CFC, teda checkpointová kompresia riadená štruktúrou dát.

Jej postup sa dá vysvetliť bez rovníc:

1. Najprv prebehne sonda. Archív si pozrie typy dát, opakovania, podobnosť, entropiu a možné náklady. Ešte nič záväzne nemení.
2. Nájde podpory a rezy. Podporou môže byť skupina podobných JSON objektov, logov, verzií rovnakého súboru, číselných stĺpcov alebo podobných binárnych oblastí. Rez určuje, kde je výhodné oddeliť základ, presný rozdiel, metadáta či doslovný únikový prúd.
3. Zhromaždí kompresný tlak. Odhadovaný zisk sa porovná s cenou metadát a dekódovania. Lokálny signál je iba hlasom v rozhodovaní, nie príkazom.
4. Rozhodne na checkpointe. Až keď sa uzavrie kanonická vrstva, vyberie sa stabilný plán.
5. Použije iba vratné transformácie. Ak sa súbor vyjadrí ako základ plus rozdiel, rozdiel musí byť presný. Dekódované dáta musia byť bitovo zhodné s originálom.

Samotné techniky ako RLE, deflate, delta alebo byte shuffle nie sú nové. Výnimočný kandidát je vrstva nad nimi: ako sa dáta zoskupia, kde sa urobí rez, kedy sa rozhodnutie uzavrie a ako sa jeho stabilita overí.

Prvý archívny test

Prvý meraný experiment pracoval s malým generovaným korpusom: 19 súborov rozdelených na 100 kúskov. Rovnaké dáta sa zabalili v pôvodnom poradí, obrátene, podľa hashov, s dvoma náhodnými poradiami a s rôznym počtom vlákien.

Checkpointová verzia vytvorila vo všetkých siedmich variantoch rovnaký kompresný plán, rovnakú veľkosť a správny lossless výstup. Greedy kontrola, ktorá sa rozhodovala priebežne podľa návštevy, dáta tiež správne obnovila, ale pri piatich poradiach vytvorila päť rôznych plánov.

To je malý, ale dôležitý rozdiel. Obe cesty dokážu zabaliť a rozbaliť dáta. Iba jedna však v tomto teste ukázala, že jej rozhodnutie patrí dátam, nie poradiu, v akom ich práve stretla.

Na vybraných podobných vrstvách ušetril presný základ s rezíduami 4 326 bajtov oproti odhadu bez delta vrstvy. Zároveň bol celý prvý .ithz kontajner väčší než referenčný ZIP, pretože niesol rozsiahly auditovateľný manifest. To je podstatná súčasť príbehu: prvý úspech nebol víťazstvom v rebríčku veľkosti. Bol potvrdením stabilného plánu, presného roundtripu a merateľného signálu na štruktúrovaných dátach.

Neskoršia špecializácia pre veľké množstvo malých súborov už v jednom testovacom prostredí prekonala ZIP/deflate na šiestich zo siedmich profilov. tar.gz však zostal menší na všetkých siedmich. .ithz preto dnes netvrdí, že je všeobecne najlepší kompresor. Tvrdí niečo užšie a zaujímavejšie: existujú dátové profily, v ktorých sa deterministické štruktúrne plánovanie oplatí, a jeho rozhodnutie zostáva kontrolovateľné.

Čo je teda na .ithz výnimočné

Jeden hash pre význam, druhý pre fyzické bajty

.ithz oddeľuje sémantický hash plánu od hashu fyzického kontajnera. Metadáta sa môžu v budúcej kompatibilnej verzii uložiť úspornejšie a fyzické bajty archívu sa zmenia. Ak sa nezmenilo logické rozhodnutie, sémantický hash môže zostať rovnaký.

Je to podobné, ako keď dokument dostane nový papier a väzbu, ale jeho obsah a štruktúra rozhodnutí zostanú totožné.

Archív vie povedať „prečo“

Natívny nástroj dokáže ukázať rodiny dát a vysvetliť, prečo konkrétny súbor skončil v určitej metóde: ako malý textový zväzok, podobná verzia, nekomprimovateľný obsah alebo chránený predkomprimovaný formát.

To neznamená, že algoritmus je jednoduchý. Znamená to, že jeho rozhodnutie nemusí zostať skryté iba vo výslednom prúde bajtov.

Bezpečné overenie nemusí zapisovať na disk

Režim verify safe dekóduje a kontroluje hlavičky, pätičky, manifest, offsety, cesty a SHA odtlačky bez toho, aby najprv rozbalil celý strom súborov. Blokuje absolútne cesty, pokusy o ../ únik, duplicity, rezervované názvy aj poškodené rozsahy.

Niekedy je správna kompresia žiadna kompresia

Fotografie, videá, ZIP súbory alebo iné už stlačené a vysoko entropické dáta majú zostať v stráženom režime STORE, ak plánovanie nenájde bezpečný zisk. Vynútená „inteligentná“ transformácia by mohla iba pridať réžiu a marketingový príbeh.

Prečo z archívu vznikla pamäťová zóna

Archívny formát sa neskôr stretol s druhým problémom: pamäťou AI agentov.

Agent potrebuje viac než hromadu textových poznámok. Potrebuje vedieť, ktoré rozhodnutie platí, ktorý claim je zablokovaný, aký test je bránou, čo sa zmenilo a čo sa nesmie potichu stratiť pri skrátení kontextu.

Tu sa archívna myšlienka spojila s pracovnou pamäťou. project.ithz môže uchovávať checkpointy, rozhodnutia, riziká, povolené a blokované tvrdenia, reviewer poznámky a odvodené indexy. Nejde iba o kompresiu súborov. Ide o kompresiu projektového príbehu bez straty jeho rozhodujúcich hraníc.

Rovnaká zásada sa opakuje:

• neukladaj všetko bez rozlíšenia;
• nerozhoduj iba podľa poslednej udalosti;
• zachovaj presnú stopu toho, čo bolo vybrané;
• a umožni ďalšiemu človeku alebo agentovi výsledok overiť.

Aké sú možné dôsledky

Ak sa tento smer bude ďalej potvrdzovať, .ithz môže byť zaujímavý všade tam, kde samotné obnovenie súborov nestačí.

Vo vedeckých dátach môže byť dôležité zopakovať nielen výstup, ale aj plán, ktorý dáta rozdelil. V softvérových zostavách môže stabilný sémantický hash oddeliť skutočnú zmenu od náhodnej odlišnosti poradia. V audite môže vysvetlenie prečo ukázať, prečo sa určitý obsah komprimoval, ponechal alebo zablokoval. A pri AI agentoch môže projektová pamäť zostať lokálna, verzovateľná a čitateľná bez viery v neviditeľnú cloudovú históriu.

Najširší dôsledok je však možno myšlienkový: kompresia nie je iba otázka, koľko bajtov zostane. Je to aj otázka, ktoré rozlíšenia systém považuje za podstatné a či vieme toto rozhodnutie spätne skontrolovať.

Nie magický formát, ale poctivý experiment

.ithz dnes nie je náhradou všetkých archívov. Nevyhráva nad ZIP, tar.gz, 7z alebo zstd na každom type dát. Niektoré experimentálne transformácie nepriniesli zisk a neboli povýšené do predvoleného formátu. To je zámerná súčasť vývoja, nie chyba v príbehu.

Výnimočnosť .ithz je zatiaľ inde: spája lossless kompresiu s kanonickým plánom, bezpečným overením, vysvetliteľnými rozhodnutiami a auditovateľnou pamäťou. Je to archív, ktorý sa nesnaží iba zavrieť dáta do nádoby. Snaží sa zachovať aj odpoveď na otázku:

Prečo boli tieto dáta usporiadané práve takto — a dokážeme rovnaké rozhodnutie zopakovať?

Práve preto formát vznikol. Nie z potreby pridať svetu ďalšiu príponu, ale z potreby urobiť kompresiu a pamäť o niečo menej závislú od náhody a o niečo viac otvorenú kontrole.

Pokračovať môžete cez ITHZ Drive, technickú vrstvu ITHZ Native alebo experimentálnu mapu výskumu.