Test Case / Test Result

Authoritative test case identity

How a reusable test case is uniquely and stably identified across authoring tools, repositories, management systems and execution systems, and how that identity survives renaming, relocation and tool migration. Identity is the anchor for every later reference from executions, evidence and release assurance.

1. Which system holds the authoritative identifier for this test case, and what identifier value does it issue? identity
2. Which alternate or legacy identifiers must resolve to this test case, and in which external systems do they live? interoperability
3. What identity guarantees hold when the test case is renamed, moved between repositories or migrated between tools? constraint
4. What distinguishes one test case from a variant, a duplicate and a differently-named copy of the same test? definition

Revision identity and definition immutability

How successive revisions of a test case definition are identified, superseded and frozen, so that any execution can name exactly the definition text it ran and a consumer can later prove the cited definition was not altered. Includes authorship and change-reason provenance of each revision.

1. How is a new revision of the test case definition created, numbered and superseded? lifecycle
2. Who authored or changed this revision, on what authority, and from which prior revision was it derived? provenance
3. Which timestamps distinguish when a revision became effective from when the register recorded it? temporal
4. Which changes to a definition require a new revision rather than an in-place editorial correction? constraint
5. How can a consumer prove that the definition referenced by a past execution has not been altered? evidence

Test objective, test item and classification

The single stated purpose of the test case expressed independently of how it is executed, the test item or component under test, and the controlled classification of test level, test type and quality characteristic that drives selection and reporting.

1. What single objective does this test case exist to verify, stated independently of how it is executed? definition
2. Which test level, test type and quality characteristic classify this test case, and from which controlled vocabulary? classification
3. Which test item, component or interface is under test, and how is it referenced? relationship
4. How is the objective checked for being single-purpose, observable and falsifiable? quality

Test basis traceability and derivation record

Typed links from a test case revision to the requirement, acceptance criterion, risk, specification statement or test assertion it was derived from, together with the design technique, coverage items and generation parameters that justify the derivation. Traceability is many-to-many by nature and does not claim one-to-one requirement coverage.

1. Which requirement, acceptance-criterion, risk or specification statements does this test case revision trace to, and with what link type? relationship
2. Which coverage items does this test case cover, and which test design technique produced them? composition
3. Which normative statement gives the expected outcome its authority, and what is its prescription level? authority
4. How is traceability completeness assessed without asserting one-to-one coverage of a requirement? validation
5. Was the case written manually, derived from a model, or generated combinatorially, and with which generation parameters? provenance

Preconditions and required entry state

The conditions that must hold before the case may be executed meaningfully, expressed so they can be checked rather than assumed, together with the disposition the definition declares when a precondition cannot be established. The definition declares intent; what actually happened in a given run is recorded by the execution structures of this model.

1. What state must the test item, its data and the referenced environment be in before execution begins? state
2. Which preconditions are mandatory gates and which are advisory assumptions that merely make the case inapplicable? constraint
3. How is each precondition established: by the case itself, by a referenced fixture, or by an external set-up step? process
4. What disposition does the definition declare when a precondition cannot be established? exception

Fixture and test data references

How the case names the fixtures, seed state and data sets it requires, with version, provisioning contract, determinism expectations and sensitivity classification, while the master lifecycle of that data stays with the owning test data system.

1. Which fixtures and test data sets does this case require, and how are they referenced and versioned? relationship
2. What sensitivity classification applies to the referenced test data, and is production-derived data permitted for this case? privacy
3. Which parts of the referenced data are inputs, which are seeded state and which are expected baselines? composition
4. What determinism and isolation guarantees must the data satisfy for the expected outcome to hold? constraint
5. How long must a referenced data set remain resolvable for past evidence to stay interpretable? retention

Inputs, parameters and parameterized variants

Declared inputs and parameters with types, defaults and value constraints, the basis on which values or ranges are chosen, the exclusion of invalid combinations, and how a parameter set produces data-driven variants without fragmenting the identity of the parent case.

1. Which parameters does the test case declare, with what types, defaults and value constraints? composition
2. When a parameter set produces many invocations, what is the identity of each variant relative to the parent test case? identity
3. On what sampling, boundary or interaction basis are the input values or ranges chosen? measurement
4. Which parameter combinations are excluded as invalid, unreachable or unsafe? constraint
5. How are parameter values bound at resolution time from external configuration or credential stores? interoperability

Ordered actions and step structure

The ordered actions the test case prescribes, the granularity and identity of a step so expectations and evidence can attach to it, shared set-up versus discriminating actions, ordering significance, and delegation to reusable keywords or shared step definitions. The boundary against a test procedure that orders several cases is stated explicitly.

1. What is the ordered sequence of actions the test case prescribes, and at what granularity is a step defined? process
2. How is an individual step identified so that expected outcomes and captured evidence can attach to it? identity
3. Which steps are shared set-up or teardown and which are the discriminating actions of this case? composition
4. Is the step order significant, and which steps may be reordered, repeated or run concurrently? constraint
5. Where a step delegates to a reusable keyword or shared step definition, how is that reference resolved? relationship

Expected outcomes, oracle and tolerances

What the case declares as correct behaviour per step and overall, the oracle and comparison rule used to decide agreement, tolerances and units for approximate comparisons, the baselines the comparison references, and the normalization or masking applied before comparison. The definition declares the comparison rule; adjudicating an actual observation against it and recording the resulting verdict are performed by the execution structures of this model.

1. What outcome must a conforming test item produce, stated per step and for the case overall? requirement
2. Which comparison rule, tolerance and units apply when the expected outcome is numeric or approximate? measurement
3. Which reference baseline or golden artifact does the comparison use, and how is it versioned? evidence
4. Which parts of an observed outcome are normalized, masked or ignored before comparison? constraint
5. What agreement criterion does the definition fix, and what is explicitly left for result adjudication to decide? decision

Postconditions, end state and side-effect limits

The state the case declares must hold after execution regardless of outcome, the cleanup or restoration obligations and who performs them, the state deliberately left for dependent cases, and the side effects that must never escape the test boundary.

1. What state must hold after the case completes, independently of the outcome it produced? state
2. Which cleanup or restoration obligations does the case declare, and who performs them? process
3. Which downstream cases depend on state that this case deliberately leaves behind? relationship
4. Which side effects are permitted, and which must never escape the test boundary? constraint

Automation binding to an executable implementation

How a test case revision names the executable implementation, keyword decomposition or generated harness that realises it, the framework contract that binding must satisfy, how broken or ambiguous bindings are detected, and the automation status of the case. The implementation's own repository lifecycle stays outside this model.

1. Which executable implementation realises this test case revision, and how is it addressed? relationship
2. Which automation framework contract must the implementation satisfy for the binding to be valid? interoperability
3. How is a binding detected as broken, ambiguous or pointing at a different revision than intended? validation
4. Is this case manual, automatable, automated or generated, and who decides that status? classification
5. What must remain true of the definition when only the implementation changes? constraint

Applicability, selection attributes and dependencies

The conditions under which a case is applicable, the tags, attributes and priority used to select it into a scope, time-bounded applicability, and declared dependencies on other cases. Evaluating a selection expression to build and dispatch an actual run belongs to the referenced suite, campaign and pipeline models.

1. Which tags, attributes and priority values are declared for selection, and from which vocabulary? classification
2. Under which product configurations, platforms, locales or feature flags is this case applicable? constraint
3. Which other test cases must have succeeded, or must not run concurrently, for this case to be meaningful? relationship
4. What selection expression would an agent evaluate to include this case in a given scope, and which model owns evaluating and scheduling it? decision
5. Is applicability time-bounded, for example pending a fix, a deprecation date or a seasonal window? temporal

Ownership, review and readiness for execution

The accountable owner and day-to-day maintainer of the definition, the review criteria and approval authority, the permitted readiness states and transitions of a definition revision, and the access distinctions that apply to reading and changing it. This concerns the definition's own readiness, not the state of any execution.

1. Which role or team owns this test case definition, and who maintains it day to day? ownership
2. Which readiness states can a definition revision hold, and which transitions between them are permitted? lifecycle
3. Who may approve a revision as ready for execution, and on what basis? authority
4. Who may read, propose changes to and publish this definition, and which parts are restricted? access
5. Which review criteria must a revision satisfy before it is marked ready? quality

Execution record identity and correlation

Every execution/result record is an independently identified entity, distinct from the test case it exercises, from the run that contains it and from any report that renders it. Identity is never derived from a date, a verdict value or a test-case identifier; a separate correlation key groups logically equivalent executions across runs.

1. Which system of record issues the authoritative identifier for this execution record, and what is that identifier? identity
2. When no master-system identifier exists, which governed IRI or Dimension-assigned UUID/ULID stands in, and how is that substitution marked? identity
3. Which stable correlation key groups executions that are logically the same check across different runs? relationship
4. What constraint prevents a date, a status value, a display name or a test-case identifier from acting as the record key? constraint

Binding to the exact test-case revision and parameter values

The execution binds to an immutable revision of the test case, its expected-result or oracle definition and the criterion or rule being evaluated, together with the concrete parameter values, data-set references and seeds actually used. A later edit of the test case must not silently change the meaning of a past result.

1. Which immutable test-case revision, and which version of its expected-result or oracle definition, does this execution bind to? composition
2. Which criterion or rule was evaluated, in which rule version and by which tool component version? identity
3. What concrete parameter values, data-set references and randomisation seeds were bound for this execution? measurement
4. What happens to this record if the referenced test case is subsequently modified, deprecated or withdrawn? constraint

Execution context and reproducibility references

The references that make an execution interpretable and repeatable: containing run and suite or campaign, the build or source revision under test identified by digest, the environment or configuration item, the executing actor, harness and tool version, and the observed invocation with its command line and exit status. All targets are externally owned records.

1. Which run, suite or campaign contains this execution, and what identifies that container authoritatively? composition
2. Which build, artifact or source revision was under test, identified by digest rather than by label? relationship
3. Which environment or configuration item hosted the execution, and which model owns that record? relationship
4. Which actor, harness or tool executed the case, in which version, and under what observed invocation? provenance
5. What minimum context set must be present before this record may be treated as reproducible? quality

Execution time points, duration and clock provenance

Four time semantics are kept distinct: when the attempt started and ended (event time), when each outcome was observed by the executing agent, and when the record was ingested into the store. All are RFC 3339 with seconds and an explicit offset or Z, and none may be collapsed into another.

1. What are the start and end times of this attempt, expressed with seconds and an explicit offset or Z? temporal
2. When was each outcome observed by the executing agent, and when was the record ingested, and do these differ from the event time? temporal
3. What duration is reported, measured from which clock and at what resolution? measurement
4. How are unsynchronised, unknown-offset or reconstructed timestamps represented without fabricating precision? quality

Attempts, retries and append-only accumulation

A retry produces a new attempt record; it never re-opens or overwrites an earlier one. The finding covers attempt ordinal, predecessor linkage, retry trigger and the referenced retry policy, and how a disagreeing attempt series is summarised without destroying any member.

1. What is this attempt's ordinal within the retry group, and which earlier attempt does it directly follow? event
2. What triggered this retry — harness policy, orchestration rule or human decision — and which policy record applies? process
3. Which rule guarantees that an earlier attempt's observations, timestamps and attachments cannot be mutated by a later attempt? constraint
4. When attempts in one group disagree, how is the group-level outcome reported and which attempt is authoritative? state

Actual outcome and comparison against expectation

The observed actual output or system state, the expectation compared against, the comparator and its version, the tolerance, normalisation or masking applied before comparison, the resulting delta, and the pointer identifying where in the subject the observation applies.

1. What actual value, output or system state was observed, and in what representation was it captured? measurement
2. Against which expected value or oracle was the observation compared, and by which comparator? validation
3. What tolerance, precision, normalisation or masking was applied before the comparison was judged? constraint
4. Where in the subject does this observation apply, expressed as a pointer, location or region? evidence
5. How is an observation that could not be evaluated recorded without asserting either pass or fail? exception

Per-step and per-assertion outcomes

Ordered step, assertion or sub-test outcomes inside one execution, each with its own status, message and position, plus the point of first deviation and the disposition of steps after it. A container outcome is derived from members and never replaces the members' own records.

1. Which ordered steps or assertions were executed, and what outcome does each carry in its own right? composition
2. At which step did execution first deviate, and were the following steps executed, skipped or blocked? state
3. How is the container or suite outcome derived from member outcomes, and is that derivation itself recorded? relationship
4. What distinguishes a step from a nested sub-test, and how deep may the hierarchy legitimately go? definition

Adjudicated verdict, assertor and status vocabulary

A verdict is an assertion made by a named assertor in a stated mode over recorded observations, expressed in a governed vocabulary covering passed, failed, error, blocked, skipped, inconclusive, not-applicable and untested, with explicit mappings to external vocabularies. The absence of a defect, of a failure element or of a report is never evidence of pass.

1. Which governed verdict value applies to this execution, and what is that value's precise definition in the adopting Dimension? classification
2. Who or what asserted the verdict, in which mode, and on whose authority? authority
3. Which recorded observations and which oracle support this verdict, and was it derived or directly reported? provenance
4. Which verdict and evidence combinations are prohibited, such as a pass with no evaluated expectation or a pass inferred from an absent defect? constraint
5. How does this verdict map onto external vocabularies, and which mappings lose information? interoperability

Non-determinism and flaky-test evidence

Evidence that an identical binding produced differing outcomes across an attempt set, recorded as a property of that set rather than as a mutation of any attempt. Covers determinism classification, the measure and window used, and whether the classification is permitted to affect the reported verdict.

1. Across which attempt set, under which proven-identical binding, did the observed outcomes disagree? quality
2. How is this execution classified — deterministic, flaky, environment-induced or unknown — and on what evidence? classification
3. May a non-determinism classification change the reported verdict, and which role is permitted to decide that? decision
4. What instability measure is reported, over which observation window and with which denominator? measurement

Correction, supersession and result revisions

Execution records are append-only: an adjudication is corrected by adding a superseding revision that cites the record it supersedes, the reason, the correcting actor and the effective time. A rerun is a new attempt, never a correction, and superseded revisions remain retrievable.

1. Which states may an execution record occupy, and which transitions between them are legal? lifecycle
2. Which revision supersedes which, for what reason, by whom, and effective from when? provenance
3. What distinguishes a correction of an adjudication from a new execution attempt, and which must be used in each case? constraint
4. For how long must a superseded revision remain retrievable, and which policy owns that decision? retention

Logs, captures, traces and attachments

Byte-level evidence attached to an attempt or observation: harness standard output and error, screenshots, recordings, distributed traces, coverage data and crash dumps. Each attachment declares its role, media type, size, durable location, capture time, sensitivity classification and the attempt, step or observation it is bound to.

1. Which evidence artifacts were captured for this attempt, and what role does each one play? evidence
2. To which attempt, step or observation is each attachment bound, and may one attachment serve several of them? composition
3. Do captures contain personal data, secrets or customer content, and what redaction was applied before storage? privacy
4. Where is each artifact stored, and which reference stays meaningful if the store is rotated or purged? access

Digests, sealing and result attestation

Evidence integrity rests on named cryptographic digests over each artifact and result document, and on a signed statement binding the result to the subject under test by digest with the configuration used. Signing keys, trust roots and verification policy remain with the referenced supply-chain and identity models; this model records digests, attestation references and any verification outcome reported back to it.

1. Which digest algorithm and value seals each evidence artifact and each emitted result document? evidence
2. Which signed attestation, if any, binds this result to the subject under test, and under which predicate type? security
3. What integrity-check outcome has a verifying system reported back, and how is it recorded here without this model performing the check? validation
4. What minimum integrity metadata must be present before this result may be exported as release evidence? requirement

Defect, waiver and consumer references

Typed outbound references from an execution record: defect or issue reports raised, reproduced or verified against it, waiver and known-issue references, and the builds or releases that consume the evidence. Only the reference, its role and its assertion time live here; every target keeps its own lifecycle.

1. Which defect or issue records does this execution reference, and in which role — raised, reproduced, verified-fixed or known-issue? relationship
2. Which model or system owns each referenced record's lifecycle, and which of its fields must never be copied into this record? ownership
3. What rule prevents a pass verdict from being inferred from the absence of a linked defect or an empty failure list? constraint
4. Which build or release records consume this evidence, and is that reference maintained here, at the consumer, or in both places? relationship

Result documents and format projections

The canonical execution record is format-neutral; JUnit-style XML, TAP 14, SARIF, Open Test Reporting documents and telemetry attribute sets are projections of it. This finding records which projection was emitted, its schema version, the semantics lost in the mapping, how identifiers survive projection and which side is authoritative on disagreement.

1. Which interchange format and schema version was emitted, and which semantics does that projection lose? interoperability
2. How do record identifiers survive projection into formats that identify tests only by name, class or ordinal? identity
3. Which representation is authoritative when the emitted projection and the internal record disagree? quality
4. How is an emitted document checked against its declared schema, and what is recorded when it does not validate? validation

Record ownership, stewardship and custody

Identifies the accountable owner of a test case or test result record and its assurance claims, the steward performing day-to-day maintenance under delegated authority, and the custodian holding stored evidence when custody is separated from ownership. Ownership is a reference into the adopting Dimension's party registry, held with the effective moment from which it applies so that historical accountability remains reconstructable after a transfer.

1. Which accountable party owns this test case or test result record and the assurance claims derived from it? ownership
2. Which steward maintains the record day to day, and under what delegated authority do they act? authority
3. Which custodian holds the stored evidence when custody is separated from record ownership? relationship
4. What evidence records a transfer of ownership, and from which moment did it take effect? provenance

Role separation and independence constraints

Declares the author, reviewer, approver and executor roles required for a record to progress, the role combinations prohibited on the same revision, and how independence between authoring and execution is demonstrated at a given integrity level. Includes the documented exception path when a role conflict must be tolerated, so that waivers are visible rather than implicit.

1. Which roles must have acted before a test case revision may reach an approved state? authority
2. Which role combinations are prohibited on the same record revision? constraint
3. How is the executor's independence from the author demonstrated at the applicable integrity level? evidence
4. Which documented exception permits a role conflict on this record, and who granted it? exception

Lifecycle states and approval gates

Defines the distinct state models for a test case definition and for a test result record, the transitions that require review and approval before a record may be cited as evidence, and the content of the approval act. Approval is captured with the signer, the moment of signing and the meaning of the signing, and is bound to the exact revision approved so it cannot be transferred to a later revision.

1. Which lifecycle states are defined for a test case definition, and which for a test result record? state
2. Which transitions require review and approval before the record becomes usable as evidence? lifecycle
3. What signature manifestation is captured when a record is approved? authority
4. How is an approval bound to the exact revision it approved rather than to the record as a whole? evidence
5. Under what conditions may an approved record be returned to an earlier state, and what is recorded? decision

Revision identity, correction and supersession

Distinguishes a new revision of an existing test case from a new test case, and fixes the rule that an approved or finalised record is corrected by a superseding revision rather than by in-place edit. Records the validity window of each revision and defines what happens to results that reference a revision once superseded, so historical results remain interpretable against the definition actually executed.

1. How is a revision of a test case identified, and what change makes it a new test case instead? identity
2. Under what rule is an approved or finalised record corrected, by edit or by superseding revision? process
3. Which timestamps establish the validity window of a revision that has been superseded? temporal
4. What happens to test results that reference a test case revision after that revision is superseded? relationship

Execution provenance and source or tool trust

Records which agent acted, under which plan, in which activity, and with which tool, harness or generator a result was produced, together with the environment and resolved dependencies relied on. Separates event time from observation and ingestion time so a delayed or replayed import cannot be mistaken for a fresh execution, and attaches a trust assessment to the producing tool so results from unqualified or self-reporting sources are distinguishable from results from qualified ones.

1. Which agent, acting under which plan and activity, produced this test result? provenance
2. How are execution event time, observation time and ingestion time recorded separately for one run? temporal
3. How is the tool, harness or generator that produced the result identified and trust-assessed? quality
4. Which environment and resolved dependency facts form part of the execution record? composition
5. What does this provenance record explicitly not attest about the run? constraint

Evidence binding, integrity and immutability

Binds each evidence artifact to the result that cites it by cryptographic digest, so that the artifact is matched by content rather than by filename or location, and defines when evidence becomes immutable. Records the outcome of every integrity verification, including failures, so an unverifiable artifact is visibly degraded rather than silently dropped or silently trusted.

1. What digest and algorithm bind an evidence artifact to the result record that cites it? security
2. How is an evidence artifact shown to be unaltered after ingestion? validation
3. At what point does evidence become immutable, and what may still change afterwards? constraint
4. How is a failed or unverifiable integrity check represented rather than discarded? exception

Record validation and confidence grading

Defines which fields and referential links must resolve before a result record is accepted, how outcomes that are neither pass nor fail are represented, and what confidence grade attaches to the record. Explicitly preserves inconclusive, blocked, aborted and error outcomes as first-class verdicts, and marks known-unreliable tests without discarding their history, so that aggregate figures are not silently improved by dropping inconvenient runs.

1. Which mandatory fields and referential links must resolve before a result record is accepted? validation
2. How is an inconclusive, blocked, aborted or errored execution outcome represented? exception
3. What confidence grade is attached to a result, and on what basis is it assigned? quality
4. How is a known-unreliable or intermittently failing test flagged without deleting its records? measurement
5. What limit does this model state on what a passing result establishes? constraint

Coverage measurement as a bounded claim

Treats a coverage figure as a claim with a declared coverage item type, measurement method, numerator, denominator, exclusions and aggregation basis, not as a bare percentage. Coverage is technique-relative, so the same test set yields different figures under different item definitions. The claim carries a mandatory caveat that a coverage figure measures exercised items and does not by itself establish test adequacy, correctness or fitness for release.

1. Which coverage item type, measurement method and denominator does this figure refer to? measurement
2. Which scope boundaries and exclusions limit this coverage figure? constraint
3. Which executions and definition revisions were aggregated to produce the figure? composition
4. What caveat is carried so the figure is not read as proof of adequacy? quality
5. How is a coverage claim referenced by an external gate without this model owning that gate? interoperability

Requirement, risk and control trace assertions

Holds the assertion that a test case exercises a stated requirement, risk or control, together with who asserted it, when it was last reconfirmed and whether the referenced target has since changed. Trace links are references outward: this model owns the assertion and its staleness state, while the requirement, risk or control model owns the target's definition, revision and approval.

1. Which requirement, risk or control does this test case assert that it exercises? relationship
2. Who asserted this trace link, and when was it last reconfirmed? provenance
3. What happens to the trace link when the referenced target revision changes? state
4. How is a trace link expressed so an external tool can resolve it without local knowledge? interoperability

Sensitivity classification and personal or production data

Assigns a sensitivity label at record level with overrides at field and artifact level, because a benign test case can cite a log containing production personal data. Records whether personal data is present, the origin class of the test data, and the minimisation or pseudonymisation measure applied before the data entered the record, so that later access, export and retention decisions rest on declared facts rather than on inspection of payloads.

1. What sensitivity label applies to this record, and does it differ for individual fields or artifacts? classification
2. Do the test inputs, logs or attachments contain personal or production-derived data? privacy
3. Which minimisation or pseudonymisation measure was applied before the data entered the record? security
4. Which fields must be masked for a reader holding only baseline access? access

Retention, legal hold and disposition

Binds each record class to a retention rule and disposition authority owned by the records-management model, records the trigger that starts the retention clock, and captures hold state that suspends disposition. Distinguishes the outcomes of disposition: full erasure, redacted stub, or tombstone that preserves the identifier and enough metadata for referential integrity. Retention clocks for a result and for its evidence artifacts may differ and are recorded separately.

1. Which retention rule and disposition authority governs this record class? retention
2. When does the retention clock start for the result, and when for its evidence artifacts? temporal
3. Which legal hold suspends disposition, and who may place or release it? authority
4. What remains after disposition: full erasure, redacted stub or tombstone? decision

Export packaging and redaction

Governs release of a test record and its evidence beyond its home boundary: which redaction profile applies, how integrity is re-established once redaction has changed artifact content, and what the recipient is told about what was withheld. Because artifacts are bound by digest, redaction necessarily produces new artifacts with new digests; the export manifest must therefore state the relationship to the originals rather than presenting redacted content as the original evidence.

1. Which redaction profile applies when a test record leaves its home boundary? access
2. How is integrity re-established for an export whose content has been redacted? security
3. What does the export manifest tell the recipient about what was withheld? evidence
4. Which approval is required before an export crosses an organisational or jurisdictional boundary? authority

Standards alignment, conformance limits and regional variation

Records which external standard or schema each field set aligns with, the status of each mapping, and what evidence would be needed before a conformance claim could be made. Alignment is a mapping assertion, not conformance: an implementation may align with a quality-management vocabulary and still fail its conformance requirements. Unresolved conflicts between aligned standards are held open as publication holds rather than resolved by silent preference, and regional or sector profiles that change governance obligations are recorded explicitly.

1. Which external standard, schema or vocabulary does a given field set claim to align with? interoperability
2. What evidence would be required before a conformance claim to that standard could be made? evidence
3. Where do two aligned standards conflict, and how is that conflict held open? decision
4. Which regional or sector-specific rule changes the governance obligations for these records? requirement
5. How is a tool-specific report format bound without becoming this model's semantics? definition