Four Files And Three Refusals

Four JSON files sit in one project folder. They weigh 613, 614, 634 and 671 bytes, 2,532 between them, and they were written on 2026-09-24 inside a single window of 152.932 seconds. That window opens at 14:59:49 and closes at 15:02:22, 00:02:32 later, 4.248 per cent of one hour. The gaps between them are 85.1, 16.886 and 50.946 seconds, an average of 50.977. Every one of the four is bigger than the one before it. The sizes run 613, 614, 634, 671, and that is also the order they were written, so the clock and the byte count agree for once. The spread across the four is 1.0946 to one and the whole range is 58 bytes. Four distinct sha256 hashes, no two files alike. The folder holds 6 JSON files and 8,373 bytes of them, so these four are 66.67 per cent of the JSON files and 30.24 per cent of the JSON bytes. The other two carry the plan.

Read the four for what they say happened and the shape turns. One file records a clip. Two files record refusals. The refusal files are 634 and 671 bytes, 1,305 bytes together, 51.54 per cent of the 2,532. The two files that record work landed are 613 and 614 bytes, 1,227 bytes, 48.46 per cent. The failure records outweigh the work records by 78 bytes. Seven refusal events are stored in that 1,305 bytes, 186.43 bytes each. Three of four files, 75.0 per cent of them, describe something that did not happen. The folder that holds them holds 75 files and 75,647,512 bytes, and this day's ledger is 0.0033 per cent of it. The probability a reader opens this folder as a record of what was made is high, and it is not certain, because the bigger half of the bytes is the register of what was refused.

The probe file holds 634 bytes and 5 rows of 4 fields: account, key name, state, message. There are 5 distinct account labels and 5 distinct key names, so five separate credentials were exercised. Every one of the five states is 'code 97' and every one of the five messages is 'Insufficient balance', 20 characters, 100 bytes of the 634, 15.77 per cent. No row carries a task id, so nothing was queued. No row reads not configured, so all five keys were present and all five were empty. The response is the same sentence five times from five different accounts, and the file's own order is the order the script declares them in. The labels are not sorted and not numeric: WIRO3, 2, 1, 3alt, WIRO2. Two of them name the same service, one is a bare number, one carries a suffix. Five keys, five balances, one answer.

The fourth file holds 671 bytes and 2 keys: 03_two_shot_q2 and 04_woman_close_a2. Each key holds one field, an error, and there is nothing else in the file. Both errors open with 429, both carry type insufficient_quota, both carry code credit_balance_exhausted. The two messages are character for character identical, 267 characters and 27 words each, stored twice. That is 534 bytes of the 671, 79.58 per cent of the file given to one refusal written out twice. Put the two providers side by side and the price of a refusal swings wide: 20 characters from one, 267 from the other, in files of 634 and 671 bytes. Neither message names a fix. Each names an address.

2,532 bytes, four files.

Read all four for cross references and there are none. Not one names another's filename. The subject labels are contiguous, 01 through 04, and they are split: the clip file holds only 02, the upload file holds 01 and 02, the edit file holds 03 and 04, and the account file holds no subject at all. So the two subjects that landed sit in the two files with no refusal, and the two that failed appear only in the file that records failures. The order of the day exists in no artifact. It exists only in the four mtimes. The upload file holds 3 references and 1 of them carries provenance: one 10 character sha1 in a field beside its address and the same 10 characters inside the sent filename. The other two entries are a bare address and nothing else, so two of three uploads cannot be checked against their own bytes. One host serves all three, in two shapes: a prefix of 107 characters of 12 groups twice and 71 characters of 8 groups once.

Each of the four was written by a script sitting in the same folder. Three of those scripts were last edited seconds before their output appeared: build_stills_openai.py at 15:02:16 against an output at 15:02:22, probe_accounts.py at 15:01:25 against 15:01:31, wiro_upload.py at 15:01:04 against 15:01:14. The fourth runs the other way: build_clips.py carries a last edit 80.004 seconds after the manifest it names. The probe script also reaches outside the folder for its client, into a sibling project, and it opens on a memory that had already failed: account 3 is the live one, the note says, and account 3 had just answered code 97. The folder holds 16 Python files at 98,686 bytes. The four ledgers are 0.0257 of that. The clip the first of them records weighs 6,909,443 bytes, 2728.8 times the ledger that names it, and its declared 10.041667 seconds is exactly 241 frames at 24 frames a second against a performance of 9.938 seconds, 2.488 frames shorter. The ledger knows the file to the byte. It does not know who paid.