Work Poiesis
Poiesis · Shared generationSeveral of my apps share one service, Poiesis, for generating text and images. Each app needs proof of exactly what came back, a clear date when the file goes away, and prompts that don't linger once the job is done.
Component study · eight tests passed on September 19, 2026, with no AI model running
Hello
5 bytes · UTF-8 · no trailing newline
Fingerprint: a code computed from the exact bytes (SHA-256)
185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969Fetching a file doesn't extend its deadline, and never fetching it doesn't keep it longer. The tests use sample files and a clock they control.
The file and its expiry time are recorded.
The file's set lifetime is over.
A request for the file gets a refusal.
A cleanup call deletes the expired file, whether or not anyone collected it.
The eight tests run the service's own code for jobs, images, requests and stored prompts. Each step below covers one or more of them and says what they showed. The steps come from different tests, not one recorded job.
The image engine's code runs, but its request goes to a stand-in that answers with a small PNG image made for the test. The job finishes with exactly those bytes. A second test fetches the image back through the service and checks that it carries an expiry time.
A stand-in text generator sends "Hel" and then "lo" as the text streams in, and returns "Hello". The service records one text file, marks the job complete and stores the exact bytes with their fingerprint.
The test fetches its sample file once, then moves the test clock to 24 hours and one second after the file was made. The next request for the file is refused. A cleanup call then reports one file deleted.
A second sample file is never fetched. At 25 hours, a cleanup call deletes it and leaves the job with no files.
Three tests check the stored prompt. It waits in the work queue locked, its key is deleted when the job finishes, and it can't be unlocked under a different job's ID. The next section explains why it's built this way.
A worker, the part of the service that runs a job, may fail after accepting it. A second worker needs enough information to carry on. That makes custody of the prompt, meaning who holds it and for how long, a real design problem: making work recoverable also creates something that could be kept too long.
So the locked prompt and its key live in different places. The lock is also tied to the job's ID: a test tries to open the prompt under another job's ID, and it fails.
Holds the prompt, encrypted, along with the job's details. A test looks through everything in the queue and finds no readable copy of the prompt.
Holds the key, apart from the prompt. When the job finishes, the key is deleted. A test keeps a copy of the locked prompt, standing in for a backup, and shows it can no longer be opened.
Where the prompt and its key sit in the tests.
The prompt and the returned files end in different ways. When a job finishes, the prompt's key is deleted, so the stored prompt becomes unreadable. Returned files expire 24 hours after they're made, and a cleanup call deletes them whether or not anyone collected them. Steps 3, 4 and 5 above show both.
The cost: a set lifetime can make useful content unavailable. Recovery and delivery have to fit inside that limit; retrying forever would defeat it.
I decide what each project is for and check what comes back. In July 2026 I decided Poiesis would be a shared service that my other apps call when they need something generated. The rule I set for it: you get back exactly the file that was made, and nothing stays available forever.
AI tools write the code, including the eight tests on this page.
de39639, with no failures, no skips and no attempted outside connections.Each test's name as the record lists it, grouped by the file it lives in and what it covers.
tests/test_executor.pytest_a_generation_runs_through_the_real_lifted_enginetest_artifacts_are_fetchable_and_carry_an_expirytest_run_text_with_a_sink_streams_and_settles_completedtests/test_api.pytest_artifacts_expire_at_24h_whether_or_not_collectedtest_expiry_is_not_extended_by_never_fetchingtests/test_durable.pytest_the_plaintext_prompt_never_reaches_the_queue_at_alltest_shredding_the_key_makes_the_ciphertext_permanently_unreadabletest_a_sealed_prompt_cannot_be_moved_to_another_generationThe tests ran on Python 3.11 with made-up data, storage held in memory, a clock the tests control and stand-ins for the text and image generators. No AI model, graphics processor or live generation service was called.
Beyond the two gaps in the record above, the tests don't show:
The fingerprint identifies the bytes that came back. Authorship, rights, accuracy and quality need separate evidence.
You can check the "Hello" fingerprint yourself: printf 'Hello' | sha256sum prints the same 64 characters.
The record's attribution wording was updated on September 23, 2026, and the note on the 409 refusal was added then from the source. No tests were rerun, and the results didn't change.