Piculum

The Idea

A piculum is an image whose pixels can carry data. What sets the format apart is that the placement of that data does not have to be arbitrary. Regions of the image can be painted and assigned specific purposes as layers, so the organization of the data and the composition of the picture are designed together.

The workbench editor with QR And Data open, one of the starter templates that come with the workbench: a nine-square color grid with a spiral. The layer list, circled in red, shows four layers of three kinds: Caption, human-readable, 27,880 pixels; Description, piculum, 4,881 pixels with about 8,713 bytes usable; Data, piculum, 70,756 pixels with about 127,288 bytes usable; and QR, qr, 15,876 pixels. — A template's layer list. Four painted regions with three different purposes: a human-readable caption, two data layers with their byte capacities, and a QR layer.

At its simplest, a piculum can carry a message or a file: you mark the pixels the layer uses but define no fields, and the space it needs is allocated within them as it is written. When more structure is needed, the painted regions become typed fields with names, capacities, locations, and access rules: this shape is a date, this one is a name, this one is a phone number, this one is a choice from a fixed list, this one is free text. A layer can also carry a whole file instead of a typed field. Each field gets a caption, a place on the artwork, and a measured byte capacity, shown once the region is painted.

At that point the image begins to function as a data dictionary. Instead of describing the shape of a record only through a separate schema, that structure is drawn directly onto the picture that will carry the record. The finished design is one file, an ordinary PNG, and that file is simultaneously the schema, the entry form, the transport, and the storage for every record made from it.

The picture carries the data, helps organize it, and can take part in presenting it. It matters as a carrier because a PNG needs no infrastructure: every image viewer displays it, everything that stores images stores it, and it travels every channel a photo travels. But the carrier is not the whole story. The same act that places the data also composes the image, and what makes a piculum useful is the same thing that makes a database table useful: someone defined the record, so every filled copy comes back structured.

Three Roles, Deliberately Separated

The designer decides what the record is. They paint the fields, type them, caption them, and see each one's capacity once it is painted, using a variety of painting and advanced splitting tools to lay out where each field's pixels sit. The definition of the data and the look of the thing that carries it are designed together, in one act.

The data person, a customer, a family member, a coworker, or a program, never sees any of that machinery. They open the template and get a form: a date picker for the date, a proper phone field for the phone, a dropdown for the choice. They fill it in, and out comes a PNG. That PNG is the record.

The reader decodes the PNG with the password and sees the record laid out field by field, captions and all: the structured thing the designer defined, never a blob of text to interpret.

Design once, fill many times, read anywhere. Filling and reading both happen in piculum software; the format is nothing without its encoder and decoder. What the design buys you is that the software is a tool, not a service. Encoding and decoding run locally, no server holds your records, there is no account to create, and nothing phones home. Between the designer and the reader there is only the file and the software.

What That Looks Like in Practice

An emergency-info card. Design it once: name, date of birth, allergies (choice list), medications, emergency contact (phone). Fill one per family member. Each card is a photo on a phone that decodes, with the family password, into labeled fields a stranger could act on.

Business paperwork. A registration form, a warranty claim, an inspection record. The business designs the piculum; customers or field staff fill the form; the returned image decodes to a structured record every time, because the structure was designed in rather than hoped for.

A software license badge. The vendor designs the badge once: licensee name, product, edition (choice list), seat count, expiry date. Each sale fills the form and issues the badge, a small image the customer keeps and presents when support or activation asks for it. When the vendor decodes a presented badge, they either recover exactly the license they issued or the seal refuses to open. A badge that was edited or forged without the vendor's password fails at that check instead of decoding to a doctored license. The customer carries the record; the vendor's decode is the verification.

A publisher with tiers. Regions carry their own passwords, so one designed image serves several audiences: the free password opens the hint, the subscriber password opens the solution. The people who can open one region learn nothing about the contents of the others.

For developers, the template is a contract. The field definitions travel with the piculum itself, so a program using the piculum library can read a template, discover its fields and capacities, fill them, and emit the record, or take a record and consume it. It is a form spec, a data envelope, and a distribution format in one file; the library is the only dependency, and no server is involved in reading.

Why It Holds Up

The carrier is just a PNG. As a picture it needs nothing: it displays, stores, and travels like any other image. As a record it needs the piculum software on both ends. The picture carries the record; the software does the work.

Every field is genuinely sealed. Content is protected with modern authenticated encryption. A wrong password does not produce garbled text to puzzle over; the seal refuses to open. If anyone alters the carrying pixels, the seal breaks visibly instead of decoding to something plausible and wrong. You get the right content or a clear failure.

The workbench Open view for a record made from the Space Power starter template, another of the templates that come with the workbench, after a wrong password. The picture displays normally above a password box. Below it a red message reads: Data: Couldn't unlock this - check the password, or the file may be damaged. — A wrong password. The picture still displays; the data does not open, and nothing else comes out.

For readers who want the specifics: each region is sealed independently with AES-256-GCM, using a key stretched from your password by PBKDF2-SHA256 at 100,000 iterations with a fresh random salt every time, all of it the browser's built-in, audited WebCrypto implementation, not custom cipher code.

The seal has a look. The encrypted contents of a field are rendered into the pixels painted for it, so the ciphertext is presented as part of the image rather than as bytes, hex, or Base64. Sealing the same data twice, even under the same password, produces different pixels; that is ordinary behavior for modern encryption and not the point. The point is placement: the designer chose which pixels carry the seal, so the sealed region takes a deliberate place in the composition built around it. This is the sense in which the picture takes part in presenting the data, not only carrying it.

The workbench showing a decoded record from the Space Power starter template at left, its JSON data listed below it, and two more encodes of the same record side by side at right, outlined in red. All three pictures show the same starry artwork with the caption My Generator, but the colored speckle of encoded pixels differs between them. An annotation reads: these images are the exact same data and password as the first image, but showing that the encoded data looks different every time you encode. — Three encodes of the same record with the same password. The artwork and the decoded data are identical; the encoded pixels are not. These are grabs for illustration, not decodable piculums.

The field map can travel separately. A record normally carries its own sealed field map, so the reader needs only the file and the password. The encoder can instead keep that map out of the picture and save it as a small separate mask file. The picture alone then holds no map of where its fields sit, and reading it takes the picture, the mask file, and the password together. This is a key file in the classic sense, a second thing you must have rather than know. It does not make the encryption stronger; it means an opened record requires two files instead of one, and a copy of the picture without its mask file cannot be opened at all.

The Embed mask checkbox in the workbench encode panel, unticked, with its tooltip: Unticked: the mask is saved as a separate .piculum-mask.png file instead - the picture alone can't be decoded elsewhere without it. — The one box. Unticked, the field map goes to a separate .piculum-mask.png file.

The One Rule of Care

A piculum's content lives in exact pixel values, so it survives anything that preserves the file: copying, attaching, storing, downloading. It does not survive being re-rendered. Screenshots, photo "enhancement," and messengers that recompress images all repaint the pixels and destroy the carried content (the visible picture stays fine). Send the file, not a picture of the file. And the password is the whole key: there is no recovery back door, so losing it means losing the contents. If the mask was saved as a separate file, that file is part of the key too; keep it as safe as the password.

In Short

A piculum lets one person define a record, its fields, its types, its capacities, its look, by drawing it, and lets anyone else fill and read that record as an ordinary picture, using the same tool on both ends. It is a data dictionary you can hand to your family or your customers, with real encryption on every field and nothing between the designer and the reader but the file and the software.