A data dictionary you can draw

A piculum starts the way a database table does: you define the fields. A date here, a name there, a phone number, a choice from a fixed list, free text, a file. The difference is where the definition lives. You paint it onto a picture, and that picture becomes the schema, the entry form, and the record, all in one file. Anyone can fill it. Anyone with the password can read the structured record back out. And it travels as an ordinary PNG.

Read the white paper npm install piculum

You paint the schema onto the artwork

In the workbench, defining a field and placing it are the same gesture. You paint a region onto the image, any shape, anywhere, and declare what it holds. Each field gets a caption and shows its exact byte capacity while you draw, so you know what fits before anything is filled. A field's pixels can be a heart, a scatter of stars, or a precise-capacity blob dropped exactly where you click. No schema tool has worked this way before: the record definition and the artwork are the same object.

Design

The designer defines the record

Paint the regions, type the fields, caption them, see their capacities. The result is a data dictionary that happens to be a picture.

Fill

Everyone else sees a form

A date picker for the date, a phone field for the phone, a dropdown for the choice. They fill it in and out comes a PNG. That PNG is the record.

Read

The reader gets the record back

Decode with the password and the record comes 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. And it 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.

What people do with it

An emergency-info card. Design it once: name, date of birth, allergies, medications, emergency contact. 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. Each sale fills the form and issues the badge: a small image the customer keeps and presents when support or activation asks for it. A badge that was edited or forged fails at the vendor's decode instead of decoding to a doctored license.
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.
A note in a photo. The undesigned case works too: encode a private message or a file into any picture and send it as a picture.

Why the record is a picture

A PNG needs no infrastructure. Every image viewer displays it, everything that stores images stores it, and it travels every channel a photo travels. The record format, the entry form, the transport, and the storage are all the same file.
Every field is genuinely sealed. Each region is encrypted independently with AES-256-GCM under a key stretched from your password (PBKDF2-SHA256, 100,000 iterations, fresh salt every time), all via the browser's built-in, audited WebCrypto. A wrong password or a tampered image does not produce plausible garbage. The seal refuses to open.
One file can serve several audiences. Per-region passwords are how piculums are built, not a bolt-on. People who can open one region learn nothing about the others.
Capacity is visible up front. The designer sees, region by region, exactly how many bytes fit, while designing, before anything is filled.

The one rule of care: a piculum's content lives in exact pixel values, so it survives anything that preserves the file and does not survive being re-rendered. Screenshots and messengers that recompress images repaint the pixels and destroy the carried content. Send the file, not a picture of the file. And the password is the whole key: there is no recovery back door.

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. The codec entry has zero dependencies and runs in browsers and Node; all encryption runs locally on the caller's machine.

npm install piculum pngjs   # pngjs only needed in Node

import { encodeMessage, decodePng } from 'piculum';
import { installNodePng } from 'piculum/node';

installNodePng(); // once, in Node; browsers need nothing

const { png } = await encodeMessage('hello', 'password', 200, 200);
const text = await decodePng(png.blob, 'password');

The codec never needs a key or an account. For environments that can't run it, there is also a hosted developer API (beta): validate and inspect templates, measure capacity, and seal or open records over HTTPS. Its free API keys exist for quotas and abuse control, not billing, and your artwork never leaves your machine.