Piculum: A Data Dictionary You Can Draw

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 and, optionally, their own passwords: 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. 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. It is the schema and the entry form, and every record made from it is an ordinary PNG too.

The picture carries the data, helps organize it, and can take part in presenting it. A PNG needs no infrastructure: every image viewer displays it, everything that stores images stores it, and it travels every channel a photo travels. What makes a piculum useful is what 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 painting tools, plus tools that split a region into scattered pieces, 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, or a coworker, 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 piculum software runs. That software is a tool, not a service: it runs in a browser or in Node, with no server required, no account to create, and nothing that phones home. Between the designer and the reader there is only the file and the software.

What That Looks Like in Practice

An information card. Design it once: name, a few dates, a category (choice list), a contact (phone), whatever details someone might need about a person or a thing. Fill one per subject. Each card is a photo on a phone that decodes, with a shared password, into labeled fields the reader can 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 a free sample. Regions carry their own passwords, so one designed image serves several audiences: a story's opening chapter opens with a password published alongside it, and the rest opens with the password readers get when they buy. The people who can open one region learn nothing about the contents of the others.

For developers, the field definitions travel with the piculum itself by default, 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 reading needs no server.

Why It Holds Up

Every data region is sealed. Content is protected with modern authenticated encryption. A wrong password does not produce garbled text to puzzle over; the seal refuses to open. Altered pixels get the same refusal, never something plausible and wrong. You get the right content or a clear failure. Visible-only layers, such as a caption or a QR code, are part of the artwork and are not sealed.

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 WebCrypto, built into browsers and Node, not custom cipher code.

The seal has a look. The encrypted contents of a data region 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 mask can travel separately. A record normally carries its own sealed mask, the map of which pixels hold data, so the reader needs only the file and the password. The encoder can instead keep the mask out of the picture and save it as a small separate file. The picture alone then holds no map of where its data sits, 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 opening a record requires two files instead of one.

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 mask goes to a separate .piculum-mask.png file.

Rules 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. There is no recovery back door: losing the password means losing the contents. If the mask was saved as a separate file, losing that file does too.

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 data region and nothing between the designer and the reader but the file and the software.