This is worth naming directly: BASICS was not written in the abstract. It was extracted from the design decisions, failure modes, and hard constraints encountered while building Workpads for deployment on KaiOS feature phones in emerging markets. The standard is a distillation of what turned out to matter.
The Workpads conformance evidence package includes:
This evidence is published alongside the standard at standard.workpads.org.
A standard without a conformant implementation is a hypothesis. The 100-day governance cycle, the deviation registry, the tier structure — all of these were tested against the reality of building Workpads, not just theorized.
Several rules changed during development. BASICS-SC-011 (durable local ID at creation) was originally scoped to sync-enabled products only; the Workpads implementation revealed that the constraint applies from the moment a record is created, regardless of whether sync is configured. The rule was updated to reflect that.
This is the feedback loop the standard is designed to have. A product builds against it, hits friction, and the friction becomes a proposal. The proposal moves through community review. The standard improves.
If you are building a tool for constrained or emerging-market deployment, we would like to hear from you. The Adoption Playbook is a 30-day track designed to take you from zero to Core tier conformance. The standard is open. The governance process is public. The deviation registry exists precisely so that your constraints can be disclosed without invalidating your conformance claim.
]]>The decision to make offline operation a mandatory Core control came directly from the deployment environments BASICS is designed to serve: rural markets, field operations, areas with intermittent or expensive connectivity. In these environments, a tool that requires a network call to create a record is not a business tool — it is a liability.
Offline-first is often treated as an architecture preference. In BASICS, it is a verifiable obligation. The degraded-mode matrix (BASICS-SC-032) requires products to publish which operations are available at each network and power state. “Create works offline” must be demonstrable, not claimed.
This has implications beyond the obvious. A record created offline needs a durable local identifier before any sync occurs (BASICS-SC-011). That identifier must be assigned deterministically — not generated from a server response, not dependent on a timestamp that may not be accurate offline.
Conflict resolution then becomes a first-class problem, not an edge case. When two records created offline sync against each other, the conflict comparison contract (BASICS-SC-041, Field tier) defines how the product represents that state to the operator. The operator must be able to see it and act on it.
The Core tier establishes the offline requirement. The Field tier provides the evidence standard: degraded-mode test output, conflict comparison contracts, constrained deployment validation. This is not belt-and-suspenders redundancy — it is a progressive hardening path.
A product that claims Core conformance has made an architectural commitment. A product that claims Field conformance has produced evidence that the commitment holds under pressure. Both claims are testable. That is the point.
Offline-first design forces decisions that online-first products postpone. Schema versioning becomes critical the moment a user’s device is running a version of your app that hasn’t synced in three weeks. Data portability becomes critical the moment the operator needs to move records off a device before it’s replaced.
These are not hypothetical problems in the deployment environments BASICS is designed for. They are routine. Building for them from the start is not a burden — it is the cost of operating in the real world.
]]>The distinction matters. A specification tells you what to build. A commitments framework tells you what you’re promising — and what the other party can hold you to.
When a standard is purely a specification, there is no clear answer to the question: what happens if you don’t follow it? The standard describes a behavior; the product either implements it or doesn’t; interoperability breaks or doesn’t. The feedback loop is indirect and slow.
This is especially painful in constrained deployments. When a product fails in the field — drops a record during a sync conflict, loses data after a power cycle, becomes incompatible after an update — the downstream effects are real and often irreversible. A farmer’s stock record doesn’t come back. An inventory adjustment that didn’t make it through isn’t recoverable from a vague specification.
BASICS requires that conformance be verifiable. Every mandatory control has a corresponding evidence artifact:
This shifts the question from did you implement the spec? to can you show me the evidence? That shift is the difference between a claim and a commitment.
Implementing BASICS is not a compliance exercise. It is a forcing function for decisions that most product teams delay until they’re expensive: how do we handle schema changes? What happens during a conflict? What is our compatibility horizon?
The 100-day proposal cycle and the deviation registry exist because we know real products have constraints that a standard written in the abstract cannot anticipate. The goal is not perfect adherence — it is transparent, documented, auditable behavior.
A product that registers a deviation and explains its compensating control is more trustworthy, not less. That’s the commitments model working as intended.
]]>