Skip to content

12. Conformance and Test Mapping ​

12.1 Conformance Claim ​

A baseline conformance claim requires:

  1. Normative behavior alignment with this requirement set, especially Chapter 4 and Chapters 5-9
  2. Passing mapped conformance tests for the baseline
  3. Versioned evidence artifacts for regression comparability

12.2 Coverage Domains ​

Conformance covers:

  1. Accepted and rejected source forms
  2. Source-location attribution
  3. Semantic validation contracts
  4. Type and unit rules
  5. Preservation of meaning through execution preparation
  6. Runtime state transitions and error policy
  7. Material conservation and binding behavior
  8. Surface sugar to domain built-in lowering contracts
  9. Content classification whitelist and diagnostic-stage mapping
  10. Runtime material-accounting and report-projection behavior

Scope:

  1. Conformance scope includes single-source parsing, definition dependency loading, and CLI batch fan-out behavior.
  2. Source-loading diagnostics and entry-source/dependency-loading failures require evidence because loading is part of the public execution contract.
  3. Protocol parameterization (protocol params + named call args + PLAN_CALL_*) is part of scope.
  4. Repeat-binding scope coverage MUST accept name reuse across sibling repeat statements whose scopes do not overlap and reject shadowing of parameters, local let names, or active enclosing repeat bindings.
  5. Entry-source script execution and omission of dependency-file top-level statements from execution are part of scope.
  6. CLI single-run and batch execution surfaces are part of scope.
  7. Direct execution of an entry source without an executable entry fails, while the same source remains valid as a definition dependency.

12.3 Language Contracts and Evidence ​

The reference defines requirements, their owning chapters, and observable acceptance criteria. These definitions are independent of any implementation's source layout, test framework, or release schedule.

Each implementation maps the relevant language sections and observable behavior to its executable evidence and records the reference revision used for its conformance claim. Internal tracking identifiers, if used, belong to that implementation and are not part of the language reference. Tests provide evidence; they do not define additional language semantics or make the reference depend on implementation artifacts.

Typed open parameters require evidence across source validation, argument binding, serialized replay and runtime consumption:

Language contractOwning sectionsObservable behavior
Filtration parameter types6.3.12Standard and explicitly installed filtration drives preserve authored handling; legacy text remains accepted; centrifugal settings remain quantities. Foreign enum families, unknown qualified members and uninstalled extension identities are rejected.
Data-reference types6.3.16, 11.11Both local data constructors accept standard and installed kind members through aliases, branches and protocol arguments. Result schemas and old text remain compatible; extension identity survives serialized replay without conferring measurement behavior.

12.3.1 Quantity and Composition Requirements ​

Quantity arithmetic and material identity changes have separate owning contracts. Evidence must follow their effects through execution, rather than stop at accepting source syntax.

Language contractOwning sectionsObservable behavior
Configuration record fields5.4, 11.2, 8.4.0Aliases and nested/imported protocol calls preserve field values and units. A text value does not become a quantity through field access. Missing fields, non-record bases and binding cycles fail at their defined diagnostic boundaries; projected values remain subject to receiving-operation type and unit rules.
Quantity arithmetic11.2.1, 11.3–11.6Direct, bound, and parameter-derived load/transfer expressions produce equivalent physical amounts across compatible units. A separately loaded preparation protocol recalculates aliquots and diluent at different total volumes, preserves precision, and returns a usable container. Explicit/default arguments and later assignment use the correct values. Invalid dimensions, missing units, division by zero, non-finite values, and fractional authored counts retain their diagnostic boundaries.
Current contents volume6.2.3, 11.2.1, 11.5Reads reflect prior material changes without modifying material state. The resulting quantity retains its volume dimension through arithmetic and unit conversion. A local value binding captures the amount when evaluated; subsequent material changes affect new reads, not the captured value.
Component replacement6.3.5.1, 7.2.2, 11.2.2Selector-keyed replacement resolves every target against the pre-change snapshot and atomically splices one or more products at each source position. Counted-cell and known-mass sources, single and list values, index and exact-ID selectors, unknown-mass provenance, duplicate-target/product rejection, rollback, subsequent separation, and unchanged unrelated entries are covered.
Material quantity boundaries7.2Near-total volume and mass requests across compatible units, indexed contents, and density conversion move actual stock without negative residuals or material creation. Calculated preparation totals remain transferable. Capacity checks tolerate representation differences; shortages and overflow outside the bound still fail, and empty stock cannot satisfy a positive request.
Surface release6.3.12An adherent cell population becomes free in the explicitly selected separation output before collection, preserving cell count and carrier volume. The separation record attributes the transition to the author. Driver projections preserve cell-lifter handling and environmental conditions; later chemical replacement remains independently executable.

A conformance claim for replacement does not imply a calculated biological yield or a coupled multi-source transformation model.

12.3.2 Execution Requirements ​

Language contractOwning sectionsObservable behavior
Dropwise delivery6.3.10.1Block and trailing forms preserve total quantities for quantified and full transfers. Human instructions explicitly require dropwise delivery; robot command projections retain the requirement. Unsupported driver capabilities fail before material movement. Compatible nested constraints compose without leaking outside their scope; unrelated action families and unsupported drop parameters are rejected.
Surface spreading6.3.10.1Block and trailing constrained transfers preserve quantities and identities, require surface targets including protocol-bound targets, compose with aseptic handling, and reject unsupported driver capabilities before movement.
Qualified protocol calls3.5.3, 5.6Qualified named-argument calls work as statements, let initializers and return expressions; returned groups remain indexable and caller-owned references retain identity through nested calls.
Scoped sealed holds6.3.10.2A pure environment hold accepts sealed, preserves it through execution preparation, makes it explicit in human instructions and robot requirement flags, and rejects unsupported driver capabilities before the hold. The requirement does not leak beyond its lexical scope or apply to unrelated action families. Plate-level examples target the plate binding rather than a selected well group.

12.4 Conformance Scope ​

Evidence for a baseline claim covers accepted and rejected source forms, loading and binding, type and unit rules, observable execution effects, material conservation, diagnostics, and the language examples in Appendix A. Each implementation chooses its test organization and automation; internal AST, IR, plan representations and CI job layout are not prescribed here.

12.5 Evidence Artifacts ​

A claim identifies the reference revision, covered language sections, inputs, expected observable behavior, and recorded results, including failures. Evidence should distinguish protocol return values, derived reports, diagnostics, and material effects. Batch execution must demonstrate independent results for each input. Artifact filenames, test node names and internal serialization layouts belong to the implementation.

12.6 Change Management Rule ​

Spec-changing updates must be synchronized across:

  1. Requirement text
  2. Cross-references to the owning language sections
  3. Acceptance criteria and required evidence

Implementations adopting the changed reference update their corresponding tests and evidence mappings. A reference revision does not require a particular implementation commit or test layout to be meaningful.

12.7 Non-Conformance Cases ​

Typical non-conformance examples:

  1. Behavior changes without updating requirement mappings
  2. New diagnostics without stable code contracts
  3. Passing implementation tests that no longer map to declared requirements
  4. Sugar-lowering behavior changes without updating constructor contract tests
  5. Whitelist policy changes without updating semantic/type/runtime diagnostic mapping

12.8 Material Content Conformance ​

Content conformance covers the classification, metadata, compatibility, and diagnostic contracts in Chapters 6–8. The following requirements specify observable behavior; the choice of data structures, extraction tools, test names, and automation belongs to each implementation.

InvariantOwnerRequired coverage
Only canonical kind/type pairs form valid classificationsChapter 6 §6.2.5–6Accept every canonical pair; reject cross-kind pairs; use the declared other_* fallback for each kind in compatibility mode.
Container and content enum families remain distinct under lexical bindingChapter 6 §6.2.4 and §6.2.7Cover all four container kinds, exact member names, aliases, defaults, parameters, assignments, namespace shadowing, branches, and loops. Reject wrong-family and unknown-member inputs.
Legacy conversion preserves canonical meaning and historical metadataChapter 6 §6.2.7–8Run the listed legacy cases from source in bare and quoted forms; verify canonical output, original classification, inferred attributes, and explicit-attribute precedence.
Role recommendations do not close metadata or add constructor parametersChapter 6 §6.2.6 and §6.3Accept recommended, custom, and omitted attrs.role; preserve code/name and unknown attrs keys. Reject top-level role and unknown or repeated constructor parameters, including nested calls and aliases.
Failures appear at the earliest decidable stage without duplicate source reportsChapter 8 §8.2–8.2.2Check diagnostic code and severity, reject invalid final values before material writes, and preserve distinct source or bound-value diagnostics across repeated calls and dependency files. Explicit enum errors never use compatibility fallback.
Equivalent enum and text inputs preserve material resultsChapter 6 §6.2.7 and Chapter 7Compare volume, mass, and count operations through complete source execution; verify classification text, serialization/restoration, and event replay preserve material state.
Conformance evidence is traceable to its reference revisionChapter 12 §12.3–6Identify the reference revision and covered language contracts. Any derived contract data must retain provenance and detect drift from that reference; tests must detect implementation disagreement and missing evidence mappings.

A content-classification conformance claim MUST include source-entry validation and execution evidence as well as any tests of individual components. Repeated calls, dependency files, invalid inputs, and metadata preservation are part of that coverage. Passing this set does not by itself establish conformance for all operation/program contracts, unit tables, or other diagnostic and runtime rules.

Scientific-model and material-identity coverage also requires:

  1. Chapter 7 and the Scientific Model Extension Contract: authored-decision precedence, explicit capability binding, built-in default provider, provenance, proposal validation, and unresolved results without mutation.
  2. Built-in Material Rulebook provider behavior, including canonical classification, exact ideal routing, relationship transitions, and explicit UNRESOLVED instead of conservative equal-split guesses.
  3. Author-supplied sep.transitions behavior, including ordered live-material index selectors, exact container-local entry-ID selectors, static selector aliases, omission of zero-quantity entries, exact program-owned output-enum matching, every pair in the closed author-settable MaterialRelation domain, rejection of strings, bare identifiers, cross-program output members, unknown members, and UNRESOLVED, typed component-entry association targets, positive-output checks, atomic candidate rejection, and the bead_bound -> free elution regression.
  4. Distinct component entries retain unambiguous identities, including when their labels collide; pre-existing opaque identities remain unchanged. Internal collision-allocation algorithms are implementation choices.

12.9 Conformance Evidence Categories ​

Evidence identifies the applicable grammar, binding, operation, diagnostic, type/unit and execution contracts in this reference, together with the inputs, expected observable behavior and recorded results. Each implementation owns its executable tests and evidence mappings; their identifiers and locations are not reference artifacts.

12.10 Statement and Operation Coverage ​

Evidence for Chapter 6 covers the following statement and operation behavior:

  1. << parsing, ordered full-transfer and quantified items in one source list, and program source-shape constraints.
  2. source.partition(program)[i] mutation source parsing, accepted binary partition program family, invalid program rejection, static binary index validation, and mutation-source-only context rejection.
  3. container.contents[i] mutation source parsing, static index validation, mutation-source-only context rejection, missing/stale/preservation-context contents-state runtime diagnostics, selected-part transfer, and same-container disturbance behavior.
  4. with env shape and required target binding.
  5. sep core/program split binding, concrete *_program(...) family checks, program-specific material component partition coverage, let-bound group return compatibility, and standalone contents-state behavior.
  6. frac ordered return, stable index usage, let-bound group return compatibility, and standalone contents-state behavior.
  7. img/ecp/phy readout call contracts and return type checks.
  8. agit over a single container, an explicit container group, and a let-bound container group, including independent per-member effects, preservation of material quantities, invalidation of prior indexed-contents organization, and failure before group effects when any member cannot be resolved. Mode-specific parameter rules follow §6.3.15, including optional cycles and forbidden duration/rate for flick, and required positive time, optional positive rotation rate, and forbidden cycles for rotation. Omitted rotation rate remains unspecified, and parameter binding preserves these requirements; the selected method must not be silently substituted. Explicit ShakeMotion values retain identity through aliases, protocol arguments, stored plans and execution. Cover motion/mode mismatches, rocking's exclusive duration/count choice, positive integer counts, motion-specific rate dimensions and units, and deferred failures before effects. Generic SHAKE must not acquire a default trajectory; legacy ROTATION retains its accepted behavior. CENTRIFUGE coverage requires an action-local centrifugal drive and finite positive action duration, preserves the original container and material quantities, and permits subsequent whole-container replacement; genuine standalone sep still retains indexed parts and blocks that replacement. TAP retains its method identity and independent gentle requirement without inferred time, rate or count. Whole-plate tapping executes once, preserves each well's material quantities and relationships, and invalidates only the target carrier's prior indexed contents organization. Cover equal-label carriers, aliases, protocol arguments, allocating iterations, stored-plan replay and failures before dispatch. For stopped ELISA reactions, tapping must occur after stop-solution addition and before absorbance readout. Carrier compatibility (PC146-01–05) replays frozen v1.0.8 source, plans, environment/readout/non-TAP agitation behavior and selected-well material state. Cover declarations without bound geometry, deferred metadata/modes, inline TAP rejection and incomplete membership before whole-carrier effects. Returned plate carriers preserve the declared identity across protocol calls.
  9. plate(...) selector expansion, including inheritance of an explicit per-well capacity, static indexing of the resulting ordered well group, original-well identity preservation, and out-of-range index rejection.
  10. Chapter 7 logical container identity distinctions across definition scopes, repeated or nested invocations, and allocating iterations, including their independence from labels, external identifiers, and physical-carrier metadata. Coverage checks observable identity behavior and does not prescribe an identifier representation or encoding.

12.10.1 Electrical Control and Disruption Method Mapping ​

The following requirements cover the Chapter 6 program contracts and the Chapter 8/11 diagnostic and unit boundaries. Implementations demonstrate each criterion through their own executable evidence mapping.

Language contractObservable behavior
Electrical control selectionAccept exactly one of voltage, current, or the compatibility field alias; reject missing and conflicting controls.
Legacy field aliasEmit SEM_FIELD_PROGRAM_FIELD_ALIAS for field; canonicalize inline and let-bound descriptors to voltage.
Electrical dimensionsAccept electric-potential units for voltage/field and electric-current units for current; reject cross-dimension controls.
Disruption methodsAccept omitted method and all five controlled method values; reject unknown values.
Equipment separationKeep equipment binding outside disrupt_program; reject a device argument.

Additional coverage for environment targets and container target views:

Coverage areaRequired coverage
Env target declaration shapecanonical positional hold(target) form, scope legality, direct-child declaration collection, legacy named-argument compatibility, and preservation that hold(...) declarations do not narrow the lexical env context for executable body statements
Container target-view accessorsaccepted contents and structure.top/bottom/sidewall forms, plus rejection of incomplete, invalid, or deeper structure paths
Target-view typingtarget views accepted only in HoldTarget / ContainerTargetView positions and rejected as ordinary material containers
Grouped target viewsexplicit grouping of target-view expressions and rejection of unsupported broadcast-like member access
Diagnostic and error mappinghold scope/shape failures covered as source/compile hard errors; invalid target-view paths covered by SEM_CONTAINER_TARGET_VIEW_INVALID; target-view use in material-container positions covered by TYPE_CONTAINER_TARGET_VIEW_POSITION_INVALID

12.11 Observation Non-Mutation Coverage ​

Conformance should include checks that:

  1. img/ecp/phy do not mutate material-state quantities.
  2. Observation outputs are persisted as readout/result references.
  3. Material conservation assertions are not incorrectly applied to pure readout steps.

12.12 Protocol Return Projection Coverage ​

Conformance should include checks that:

  1. Returning a single concrete container projects container_ref.
  2. Returning multiple named concrete containers preserves named bindings and projects each binding as container_ref.
  3. Returning direct group([c1, c2]) projects container_group_ref with ordered members and member_count.
  4. Returning a let-bound group([c1, c2]) projects container_group_ref with ordered members and member_count.
  5. Returning a sep group projects both ordered material slots as container_group_ref.
  6. Returning a frac group projects all ordered material slots as container_group_ref.
  7. Returning a plate selector-derived well group projects all ordered selected wells as container_group_ref.
  8. Returning data_ref or data_group_ref remains a data/readout projection and is not coerced into material projection.
  9. CLI output renders container_group_ref clearly while preserving existing single-container display behavior.

12.13 Core Scope Boundary ​

Core conformance mapping stops at the atomic statement/operator layer.

Higher-level workflow libraries are outside the scope of this chapter.

12.14 Material-Accounting Report Coverage ​

Conformance tests for the Chapter 9 derived report contract MUST cover:

  1. registration of externally supplied initial inventory as input lots;
  2. registration of stocks introduced by LoadContent as input lots;
  3. source-to-destination accounting for multi-source and multi-target material movements;
  4. Chapter 9 runtime rejection with MAT_MOVEMENT_CONTRACT_MISSING when material quantities change without an auditable movement contract;
  5. exclusion of generated intermediate material from reagent consumption unless explicitly registered as inputs;
  6. complete, untruncated reagent-consumption output;
  7. Chapter 9 independent volume and mass accounting, including null for an unavailable quantity axis; and
  8. report assertions covering every semantic content area required by Chapter 9, independently of implementation-specific envelope or schema-title names.
  9. independent cell-count load, movement, accounting, and public-result projection without container-volume inflation; and
  10. preservation of count through sep and frac, including a suspension whose cellular count and carrier volume follow different partition fates.
  11. constructor finalization for explicit carrier, count-only inferred carrier, adherent count without carrier, invalid policy, and capacity overflow;
  12. count-to-volume resolution shared by ordinary, source-local partition, and indexed-contents transfers, including non-homogeneous rejection and quantity-axis conflicts; and
  13. separation fate precedence for authored rules and selected-provider decisions, including invalid rules, missing source content, invalid provider proposals, and no mutation on unresolved results.
  14. separation aggregate projection from routed component quantities for volume-only, mass-only, count-plus-carrier, and mixed-axis material; aggregate fields must equal the normalized detail projection; compatibility-only aggregate input must become movable, provenance-bearing component detail before separation, and stale aggregate cache values must not affect routing.
  15. exact built-in-provider routing of sedimentable cellular content under centrifuge_program: zero cellular count in supernatant, complete cellular count in pellet, conservation across both slots, independently routed carrier volume, and exclusion of zero-quantity cells from primary-component reporting.
  16. invariant material execution with and without external inventory input: undeclared sources and insufficient runtime material fail identically, conservation remains enforced, and no source is provisioned or topped up.
  17. optional post-runtime inventory reconciliation: checked/sufficient status, required/available/shortage/remaining quantities on independent axes, external shortage without runtime failure, and no mutation of runtime or supplied inventory state.
  18. cross-container movement of counted cells with container-surface association: the moved fraction becomes a suspension, the residual source remains adherent, canonical attrs.state and the compatibility attrs.culture_state spelling behave consistently, stale separation-output partition classes are replaced, and unrelated non-homogeneous states are not released.
  19. explicit third-party provider replacement and explicit composite-provider fallback, including recorded provider identity/version/configuration and proof that runtime never appends an implicit built-in fallback.

Culsma Language Reference · CC BY 4.0