Conformance

Normative

This page defines what it means to be a conformant Chiisai HAL driver.

Conformance statement

A driver implementation is a conformant Chiisai HAL driver for a given module if, and only if, it satisfies every Mandatory (MUST / MUST NOT) requirement defined for that module.

  • Recommended (SHOULD) and Optional (MAY) requirements do not affect conformance. An implementation that omits them is still conformant, though it may be less capable or less robust than one that adopts them.

  • Conformance is claimed per module. An implementation states which modules it supports (for example, “Chiisai HAL CAN and SPI”); the claim covers the Mandatory requirements of exactly those modules.

  • Requirement keywords are interpreted per Requirement Keywords.

Claiming conformance

An implementation claiming conformance for a module MUST be able to demonstrate that each Mandatory requirement is met. Every requirement carries an id of the form CHI-<MODULE>-<BAND>-<NN>, where <BAND> is the severity (MUST, SHOULD, or MAY) and <NN> numbers the requirements within that band; the Mandatory requirements that conformance depends on are therefore exactly the CHI-<MODULE>-MUST-<NN> ids. The specification does not mandate a particular evidence format; a requirement-id-indexed test or review matrix is the expected practice.

What conformance does not require

To keep the barrier to entry low and the standard distinct from heavyweight compliance regimes, conformance intentionally does not require:

  • adoption of any particular operating system, scheduler, or RTOS;

  • adherence to an external coding-rule regime as a precondition of conformance;

  • inter-module version-check machinery;

  • tool-specific configuration formats.

These may be adopted by an integrator as project policy, but they are outside the Chiisai HAL conformance contract.