This distinction matters in how the standard is structured, what it asks of implementors, and what it does not ask.
If your product generates workpad URLs — the workpads.me/p#... format — encode according to §5 so that any conformant decoder can read the record. If your product decodes workpad URLs, implement §5 faithfully so that records from any conformant encoder are readable.
That’s the full obligation. Interoperability is the standard’s core value, not exclusivity.
The standard does not ask:
You may build a commercial product on Workpads and keep that product entirely proprietary. You may extend the format for your use case using the reserved field slots in §5 without registering anything. The standard does not police what you build on top of it.
The Workpads Standard conforms to BASICS v0.1.1 at the Core tier. BASICS provides a meta-framework for interoperability claims and deviation registration.
Formal BASICS conformance for your product is not required to implement Workpads. It is a signal — to other implementors, to your users, to the ecosystem — that your product has a documented interoperability posture. It says: here is what we implement, here is what we deviate from, here is why.
If your product generates workpad URLs and you want that signal, read §8 and create a deviation registry. If you don’t need the signal, build and ship.
The standard grows through real implementation experience. We learn more from a conformant product built by an independent team than from months of internal spec work.
If you find that something in the spec doesn’t match what works in practice, that is valuable. Open a GitHub Discussion. Describe what you’re building, what the spec says, and what you found. Deviations documented in practice feed the next version.
The goal is a format that is actually interoperable in the wild — not one that is theoretically interoperable on paper. Every independent implementation makes that goal more achievable.
]]>Workpads launched first on KaiOS. This was not a pragmatic choice. It was a design constraint.
Building for the most constrained platform first forces decisions that remain correct as you move to richer environments. The KaiOS Workpads app must:
Every one of these constraints is a good constraint for any commercial record format. D-pad navigation produces a clear information hierarchy. Memory limits prevent scope creep. SMS-length URLs enforce encoding discipline. No background sync means records must be self-contained.
The Two-Build Strategy (§7) describes how a single codebase produces both the KaiOS 3.x build and the modern web build. The split is at the platform adapter layer — the record logic, codec, and storage contract are shared. Only the navigation model and rendering layer diverge.
The KaiOS use case gave us the codec’s core constraint: a complete business record must encode to under 300 characters to be reliably SMS-transmissible. The §5 codec achieves this through:
The result: a complete svc-basic record with all optional fields populated encodes to approximately 180-220 characters. With only required fields, it’s under 80.
KaiOS apps navigate using softkeys and D-pad. The panel access model (§ panel-access-model.md) defines how ArrowLeft and ArrowRight navigate between record panels, and how the softkey bar maps to record actions (Save, Share, New).
This model transfers cleanly to touch and mouse: swipe or click to move between panels, with the softkey actions becoming persistent footer buttons. The same mental model works across both platforms.
The KaiOS app is available on the KaiOS Store and as a demo at workpads.app.
]]>The distinction matters. When a format is built for storage, it assumes a server will receive it, a database will hold it, and a client will retrieve it on demand. Connectivity is a given. The record is a description of state that lives somewhere else.
A workpad record assumes none of that. The record is the transmission. It encodes a complete business transaction — service description, parties, status, financial terms — into a URL hash fragment small enough to fit in an SMS message. When the URL travels, the record travels with it.
In much of the world, reliable internet connectivity is intermittent or expensive. A feature phone with a data plan may get SMS reliably but not HTTP. A QR code scanned at a market stall doesn’t require a working server at the other end.
The Workpads codec (§5) is designed with these constraints in mind:
A record generated on a KaiOS phone in Lagos can be decoded on a web browser in Louisville without either party having an account, a server, or an internet connection at the moment of transfer.
The atomic unit of the format is the workpad record: a single document capturing one piece of work. By design, it is:
These four properties, defined in §1 — PADS Data Model, are not aspirational. They are enforced by the encoding: a workpad URL that omits the service description is malformed. A workpad URL that requires a server lookup to decode violates the sovereign property.
The record format is open. The Workpads Standard v0.1 defines what a workpad record is and how it is encoded. What you build with that is yours.
]]>