BASICS is organized into a Shared Core that applies to all conformant products, and three Deployment Profiles for products that cross software, hardware, or firmware boundaries. Conformance is cumulative — profiles inherit and may not weaken Core controls.

Shared Core

The Shared Core defines obligations that every BASICS-conformant product must satisfy, regardless of deployment tier or hardware target. It establishes the minimum verifiable guarantees that make interoperability and operator confidence possible.

### Command Surface Products must publish a machine-readable and human-readable command contract. The contract defines every command the product exposes, its required and optional parameters, its side effects, and its version history.
  • BASICS-SC-001 A command contract MUST be published at a stable, versioned URI.
  • BASICS-SC-002 Every command MUST declare its minimum required schema version.
  • BASICS-SC-003 Breaking changes to the command surface MUST increment the major version.
  • BASICS-SC-004 The command contract MUST be machine-parseable (JSON Schema or equivalent).
### Record Operations Core record operations — create, read, update, delete — must function without network connectivity. This is the foundational offline-first guarantee.
  • BASICS-SC-010 Create and read operations MUST succeed without network access.
  • BASICS-SC-011 Records MUST be assigned a durable local identifier at creation time, before any sync.
  • BASICS-SC-012 A published event schema MUST describe all record mutation events.
  • BASICS-SC-013 Records MUST carry a schema version field.
### Interoperability Products must declare their interoperability surface — what they can import, export, and exchange — so that integration is predictable and testable.
  • BASICS-SC-020 Products MUST publish an interoperability declaration listing supported import/export formats.
  • BASICS-SC-021 Declared formats MUST reference a versioned schema or public specification.
  • BASICS-SC-022 Products MUST publish a compatibility policy stating how long prior versions remain supported.
### Versioning and Governance Artifacts must be versioned, and changes must be traceable.
  • BASICS-SC-030 All published artifacts (schemas, contracts, declarations) MUST carry a semver version string.
  • BASICS-SC-031 An ADR (Architecture Decision Record) history MUST be maintained for all breaking changes.
  • BASICS-SC-032 A degraded-mode matrix MUST be published, listing which operations are available at each network/power state.

Software Profile

Applies to products delivered as software (web, mobile, desktop, CLI). Builds on the Shared Core and adds requirements for installation, update paths, and data portability.

  • BASICS-SW-001 The product MUST support installation on devices with ≤ 512 MB RAM without degraded core functionality.
  • BASICS-SW-002 Updates MUST not break existing records without a published migration path.
  • BASICS-SW-003 A full data export in an open format MUST be available without operator intervention.
  • BASICS-SW-004 Minimum supported OS/runtime versions MUST be published and maintained.

Hardware Profile

Applies to products that include or require dedicated hardware (readers, terminals, kiosks, purpose-built devices).

  • BASICS-HW-001 Hardware MUST operate in environments with ambient temperatures of 0–50°C without data loss.
  • BASICS-HW-002 Local record storage MUST persist across power cycles without external sync.
  • BASICS-HW-003 A published bill of materials (BOM) MUST identify all primary components.
  • BASICS-HW-004 Hardware products MUST publish a repair and replacement policy.

Firmware Profile

Applies to products that include programmable embedded firmware.

  • BASICS-FW-001 Firmware MUST support field update without specialized tooling beyond a USB connection or equivalent.
  • BASICS-FW-002 Firmware versions MUST be readable from the device without disassembly.
  • BASICS-FW-003 A signed firmware manifest MUST be published with each release.
  • BASICS-FW-004 Rollback to the prior firmware version MUST be supported.

All rule IDs are canonical and referenced in the Rule Index. Registered deviations use the same IDs via the Deviation Registry. The full normative text lives in the BASICS-standard GitHub repository.