# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-09-03T05:21:53Z", "synthesisSha256": "2a9d56af6582698551d8fd52fad9d642c8fa22b2217a1f72f5d2aaa3e5f71ad5", "providerMode": "single-provider-waiver", "providers": [ "Claude" ], "waivedProviders": [ "Grok" ] }, "metaModel": { "id": "WM-SFT-015", "registryId": "vr.wm-sft-015", "name": "Test Case / Test Result", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.SFT.TST" ], "tags": [ "test", "case", "result", "inf.sft.tst" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-sft-015-test-case-test-result/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-sft-015", "model": { "registry_id": "vr.wm-sft-015", "model_id": "WM-SFT-015", "name": "Test Case / Test Result", "entry_kind": "aggregate", "purpose": "Provide a governed, format-neutral structure for repeatable software and system test cases together with the executions, results and evidence they produce, so an agent can define a reusable test, resolve it for execution, record what happened, adjudicate a governed verdict, retain defensible evidence, and expose that evidence to assurance and release consumers.", "scope_statement": "WM-SFT-015 models a versioned test-evidence aggregate. The reusable test case definition is the aggregate root: authoritative identity and revision, title and objective, classification, requirement, risk and acceptance-criterion traceability, preconditions, fixture and test-data references, inputs and parameters, ordered actions, expected outcomes, oracle and comparison rule with tolerances, postconditions, automation binding, applicability, dependencies, variants, ownership and readiness. Governed members are the executions of a specific frozen definition revision, their observed outcomes, adjudicated verdicts and result status, the evidence captured during execution, the assurance signals derived over that evidence, and the governance record of ownership, approval, access and retention that binds them. Test suites and test sets, test plans and campaigns, requirements and acceptance criteria, risks, builds and releases, defects and test environments are typed external references: the model carries the reference, the binding and subject-specific parameters, and never reproduces those neighbours' lifecycles or operational functions.", "in_scope": [ "Authoritative identity and revision history of a reusable test case, including the immutable definition snapshot that any execution cites.", "Test intent: title, objective, test level and test type classification, and the design technique and coverage items from which a case is derived.", "Typed traceability bindings from a test case revision to requirement, acceptance-criterion, risk, specification-statement and test-assertion references held by external models.", "Preconditions and required entry state, expressed so they can be checked rather than assumed.", "Fixture and test-data references with version, provisioning contract and sensitivity classification.", "Declared inputs, parameters, value constraints and parameterized variants, including combinatorial or boundary-derived value sets.", "Ordered actions and step structure, including delegation to reusable keywords or shared step definitions.", "Expected outcomes, the oracle and comparison rule, tolerances, units and normalization rules, and postconditions with cleanup obligations.", "Automation binding that names the executable implementation or keyword decomposition realising a test case revision.", "Applicability conditions, selection tags and attributes, priority, and declared inter-case dependencies.", "Governed execution records stating which definition revision was run, when, against which referenced test item and environment, by which actor and with which resolved parameters.", "Observed outcomes, adjudicated verdicts, result status and reason codes, including reruns, retries and quarantined or unreliable results.", "Evidence captured by an execution such as logs, measurements, screenshots, baselines and attachments, with provenance and integrity.", "Assurance signals derived over the aggregate: traceability completeness, coverage claims, result reliability and readiness statements consumed by release assurance.", "Governance of the aggregate: ownership and stewardship, review and approval state, access classification, and retention and disposition of test records." ], "out_of_scope": [ "Test suite and test set membership, ordering and suite-level lifecycle.", "Test plan, campaign and cycle scheduling, resourcing and exit-criteria management.", "Requirement, user story, acceptance-criterion and risk authoring, approval and change lifecycle.", "Build, release and deployment identity and release-gating decisions, which WM-SFT-008 owns.", "Defect and incident triage, assignment and resolution lifecycle.", "Test environment provisioning, configuration baselining and infrastructure state.", "Source code and executable test script implementation together with its repository lifecycle.", "Pipeline orchestration, runner scheduling and job dispatch mechanics.", "Runtime policy evaluation, enforcement engines and organisation-wide audit-trail semantics owned by referenced governance models.", "Test tool and framework product lifecycle, licensing and vendor management.", "Lawfulness assessment and erasure execution for production-derived personal data used as test data, which the adopting Dimension's privacy and storage models own." ], "boundary_notes": [ { "neighbor": "Test procedure / test procedure specification", "distinction": "A test case states what is verified, under which entry state, with which expected outcome. A test procedure sequences one or more test cases with set-up and wrap-up for a specific execution occasion and carries its own identity and lifecycle; this model references a procedure but does not own its ordering or approval.", "source_refs": [ "SRC-001", "SRC-004" ] }, { "neighbor": "Executable test script / automated implementation", "distinction": "The script is an artifact of a source repository with its own versioning, review and build lifecycle. This model holds only a resolvable binding reference plus the contract the implementation must satisfy, so implementation change does not fork the definition.", "source_refs": [ "SRC-011", "SRC-003" ] }, { "neighbor": "Test suite / test set", "distinction": "A suite is a grouping and ordering construct over cases. Membership, ordering and suite-level status live with the suite model; this model declares only the tags, attributes and traceability that make a case selectable.", "source_refs": [ "SRC-001", "SRC-011" ] }, { "neighbor": "Test plan / test campaign", "distinction": "Planning covers scope, schedule, resourcing, entry and exit criteria for an effort. This model supplies definitions and evidence that a plan consumes and never holds schedule, staffing or exit-criteria decisions.", "source_refs": [ "SRC-001", "SRC-004" ] }, { "neighbor": "Scenario / use case", "distinction": "A scenario describes intended usage for stakeholders and may be executable prose. A test case adds a verdict-bearing expectation with an oracle and comparison rule; an executable scenario is treated as one authoring form of a test case specification, not as a separate lifecycle.", "source_refs": [ "SRC-010", "SRC-006" ] }, { "neighbor": "Requirement / acceptance criterion / test assertion", "distinction": "Normative statements and the testable assertions derived from them sit in the test basis. One assertion may require several test cases and coverage is often imperfect, so traceability is a many-to-many typed reference, not ownership of the requirement lifecycle.", "source_refs": [ "SRC-006", "SRC-005" ] }, { "neighbor": "Defect / incident report", "distinction": "A defect is a reported anomaly with independent triage, assignment and closure. A failing result may cite a defect reference, but defect state never becomes result state inside this model.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Build / release (WM-SFT-008)", "distinction": "Release assurance references test evidence held here. Release identity, release lifecycle, gating decisions and the release audit trail remain with WM-SFT-008; this model publishes resolvable evidence references only.", "source_refs": [ "SRC-001", "SRC-009" ] }, { "neighbor": "Test environment / configuration", "distinction": "Environment identity, configuration baseline and provisioning are external. An execution record cites the environment reference so results stay interpretable, without importing environment lifecycle.", "source_refs": [ "SRC-001", "SRC-003" ] }, { "neighbor": "Test data management system", "distinction": "Master data sets have their own stewardship, versioning and privacy controls. This model references a data-set identifier and version and classifies sensitivity for the binding, but does not own generation, masking or erasure execution.", "source_refs": [ "SRC-003", "SRC-008" ] } ] }, "sources": [ { "id": "SRC-001", "title": "IEEE/ISO/IEC International Standard for Software and systems engineering--Software testing--Part 3: Test documentation", "organization": "IEEE Standards Association (IEEE/ISO/IEC)", "url": "https://standards.ieee.org/ieee/29119-3/7499/", "version_or_date": "IEEE/ISO/IEC 29119-3-2021, published 2021-10-28, active", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:05:00Z", "relevance": "Official catalogue record for the test documentation standard providing templates and examples organised by the 29119-2 test processes; establishes that test case, test procedure, plan and incident documentation are distinct, tailorable document types supporting manual, automated, scripted and unscripted testing. Used at scope level, not clause level." }, { "id": "SRC-002", "title": "IEEE/ISO/IEC International Standard - Software and systems engineering--Software testing--Part 4: Test techniques", "organization": "IEEE Standards Association (IEEE/ISO/IEC)", "url": "https://standards.ieee.org/ieee/29119-4/7500/", "version_or_date": "IEEE/ISO/IEC 29119-4-2021, published 2021-10-28, active", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:07:00Z", "relevance": "Official catalogue record for test design techniques used within test design and implementation; states that techniques derive test cases which when executed generate evidence that requirements are met or defects are present, and that risk-based testing determines applicable techniques. Grounds derivation and coverage-item structure." }, { "id": "SRC-003", "title": "ISO/IEC/IEEE International Standard Software and systems engineering -- Software testing -- Part 5: Keyword-Driven Testing", "organization": "IEEE Standards Association (ISO/IEC/IEEE)", "url": "https://standards.ieee.org/ieee/29119-5/11042/", "version_or_date": "ISO/IEC/IEEE 29119-5-2024, published 2024-12-19, active (supersedes 29119-5-2016)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:09:00Z", "relevance": "Defines keyword-driven testing as an approach to describing test cases in a modular way, sets framework and tool requirements, and defines a common data exchange format so tools can exchange test cases, test data and test results. Grounds automation binding, keyword decomposition and interchange." }, { "id": "SRC-004", "title": "ISO/IEC/IEEE International Standard - Software and systems engineering -- Software testing -- Part 1: General concepts", "organization": "IEEE Standards Association (ISO/IEC/IEEE)", "url": "https://standards.ieee.org/ieee/29119-1/10779/", "version_or_date": "ISO/IEC/IEEE 29119-1-2021, published 2022-01-27, active", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:10:00Z", "relevance": "Official catalogue record establishing the concepts and vocabulary on which the 29119 series is built; used to justify treating test case, test procedure, suite and plan as distinct concepts rather than one artifact." }, { "id": "SRC-005", "title": "Test Metadata", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/test-metadata/", "version_or_date": "W3C Working Group Note, 14 September 2005", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:12:00Z", "relevance": "Clause-level enumeration of test metadata: Identifier, Title, Purpose, Description, Status, SpecRef, Preconditions, Inputs, ExpectedResults, Version, Contributor, Rights, Grouping and SeeAlso, with required and optional marking. Primary evidence for identity, revision, objective, traceability, preconditions, inputs, expected results, ownership, rights and grouping." }, { "id": "SRC-006", "title": "Test Assertions Model Version 1.0", "organization": "OASIS", "url": "https://docs.oasis-open.org/tag/model/v1.0/os/testassertionsmodel-1.0-os.html", "version_or_date": "OASIS Standard, 15 October 2012", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:14:00Z", "relevance": "Defines identifier, normative source, target, prerequisite, predicate, prescription level, variable, tag and description, plus test assertion sets and implicit parts. States that one assertion may require several test cases and that test cases are indicators rather than proofs. Primary evidence for oracle predicates, prescription level, prerequisites, parameter variables and many-to-many traceability." }, { "id": "SRC-007", "title": "ITU-T Recommendation Z.161: Testing and Test Control Notation version 3: TTCN-3 core language", "organization": "International Telecommunication Union (ITU-T)", "url": "https://www.itu.int/rec/T-REC-Z.161/en", "version_or_date": "Z.161 (10/2023), in force", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T10:16:00Z", "relevance": "Standardised notation in which test cases are parameterized, reusable, declarative units with templates and matching mechanisms for expected values and an explicit verdict concept. Supports parameterization, template-based expected values, and the separation between declaring a comparison rule and resolving a verdict." }, { "id": "SRC-008", "title": "NIST Special Publication 800-142, Practical Combinatorial Testing", "organization": "National Institute of Standards and Technology (NIST), U.S. Department of Commerce", "url": "https://csrc.nist.gov/pubs/sp/800/142/final", "version_or_date": "October 2010; Kuhn, Kacker and Lei", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:18:00Z", "relevance": "Public-authority guidance on input parameter modelling, t-way interaction coverage, constraints among parameter values, generated test sets, and the use of formal models to determine expected results for each set of inputs. Grounds parameter value selection, exclusion constraints and generator provenance." }, { "id": "SRC-009", "title": "General Principles of Software Validation: Final Guidance for Industry and FDA Staff", "organization": "U.S. Food and Drug Administration (CDRH and CBER)", "url": "https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation", "version_or_date": "Version 2.0, issued January 2002", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T10:20:00Z", "relevance": "Regulated-context authority establishing that software validation rests on documented, requirement-traceable testing with predefined expected results and retained records. Used only as a regulated-context alignment for evidence retention and pre-declared expectations; clause text was not machine-readable in this research." }, { "id": "SRC-010", "title": "Gherkin Reference", "organization": "Cucumber Open Source Project", "url": "https://cucumber.io/docs/gherkin/reference/", "version_or_date": "Current documentation, accessed 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T10:22:00Z", "relevance": "First-party specification of an executable test case authoring form: Feature, Rule, Scenario, Given/When/Then steps, Background for shared set-up, Scenario Outline run once per Examples row for parameterized variants, data tables and doc strings for complex inputs, and tags for grouping independent of file structure." }, { "id": "SRC-011", "title": "JUnit User Guide", "organization": "JUnit Team", "url": "https://docs.junit.org/current/user-guide/", "version_or_date": "JUnit User Guide 6.1.3, accessed 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T10:24:00Z", "relevance": "First-party evidence from a mature automation ecosystem for unique identifiers and display names, tags with tag expressions for selection and filtering, parameterized tests with argument sources for data-driven variants, assumptions for conditional applicability, disabling, test ordering, test templates, and the TestPlan and TestDescriptor separation between describing tests and executing them." }, { "id": "SRC-012", "title": "Static Analysis Results Interchange Format (SARIF) Version 2.1.0 Plus Errata 01", "organization": "OASIS Open", "url": "https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os.html", "version_or_date": "Version 2.1.0 Errata 01, OASIS Approved Errata, 28 August 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:20:00Z", "relevance": "Normative separation of run, invocation, result and artifact; result kind versus level; automation details and correlation identifiers for grouping logically equivalent results across runs." }, { "id": "SRC-013", "title": "SARIF JSON Schema 2.1.0 (sarif-schema-2.1.0.json)", "organization": "OASIS Static Analysis Results Interchange Format TC", "url": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/main/sarif-2.1/schema/sarif-schema-2.1.0.json", "version_or_date": "2.1.0 schema, main branch, retrieved 2026-09-03", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:22:00Z", "relevance": "Exact property and enum definitions: invocation startTimeUtc/endTimeUtc/exitCode/executionSuccessful/commandLine/machine, result kind and level enums, baselineState, fingerprints and partialFingerprints, artifact hashes, attachment and runAutomationDetails." }, { "id": "SRC-014", "title": "Evaluation and Report Language (EARL) 1.0 Schema", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/EARL10-Schema/", "version_or_date": "W3C Working Group Note, 2 February 2017", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:18:00Z", "relevance": "Canonical separation of Assertion (assertedBy, subject, test, mode) from TestResult (outcome, pointer, info, date); outcome vocabulary passed/failed/cantTell/inapplicable/untested and test modes automatic/manual/semiAuto/undisclosed." }, { "id": "SRC-015", "title": "Accessibility Conformance Testing (ACT) Rules Format 1.1", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/act-rules-format/", "version_or_date": "W3C Recommendation, 5 February 2026", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:26:00Z", "relevance": "Normative treatment of test target, applicability, expectations and the five outcome values; consistency validation of an implementation against test cases with expected outcomes; requirement to report outcomes with pointers identifying the test target." }, { "id": "SRC-016", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "RFC 3339, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:24:00Z", "relevance": "Normative timestamp grammar: full-date, full-time, mandatory stated offset to UTC, seconds field including leap-second range, upper-case Z, and the distinct meaning of an unknown local offset -00:00." }, { "id": "SRC-017", "title": "IEEE/ISO/IEC 29119-3-2021 — Software and systems engineering — Software testing — Part 3: Test documentation", "organization": "IEEE Standards Association / ISO / IEC", "url": "https://standards.ieee.org/ieee/29119-3/7498/", "version_or_date": "Approved 2021-09-23, published 2021-10-28, active standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:28:00Z", "relevance": "International standard for test documentation arranged by test process, distinguishing test-design and test-case documentation from execution-time documentation such as execution logs and incident reports for manual, automated, scripted and unscripted testing." }, { "id": "SRC-018", "title": "TAP Version 14 Specification", "organization": "Test Anything Protocol", "url": "https://testanything.org/tap-version-14-specification.html", "version_or_date": "TAP version 14, March 2022", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:19:00Z", "relevance": "Streamable result grammar: plan, test points with ok/not ok, test-point identifiers with uniqueness guidance, SKIP and TODO directives that harnesses must not treat as failures, YAML diagnostic blocks, subtests and bail out." }, { "id": "SRC-019", "title": "in-toto Attestation Framework — Test Result predicate", "organization": "in-toto project", "url": "https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md", "version_or_date": "Predicate version 0.1.0, predicateType https://in-toto.io/attestation/test-result/v0.1", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:19:30Z", "relevance": "Binds a test result to the subject under test by digest, with a required result enum, required configuration resource descriptors and optional per-test name lists; states that test-name semantics are agreed between producer and consumer." }, { "id": "SRC-020", "title": "OpenTelemetry Semantic Conventions — Test attributes registry", "organization": "OpenTelemetry (Cloud Native Computing Foundation)", "url": "https://opentelemetry.io/docs/specs/semconv/registry/attributes/test/", "version_or_date": "Development stability, retrieved 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:21:00Z", "relevance": "Telemetry projection of test execution: test.case.name, test.case.result.status (pass, fail), test.suite.name and test.suite.run.status (success, failure, skipped, aborted, timed_out, in_progress); demonstrates a deliberately narrower status vocabulary than the record model." }, { "id": "SRC-021", "title": "Open Test Reporting", "organization": "JUnit team (ota4j-team)", "url": "https://github.com/ota4j-team/open-test-reporting", "version_or_date": "Version 0.2.7; core, events and hierarchy schemas 0.2.0", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:23:00Z", "relevance": "Event-based, streamable, language-agnostic test reporting with started/finished events, infrastructure metadata, arbitrary container hierarchies and result outcomes SUCCESSFUL/FAILED/ABORTED; explicitly a modernisation of the Ant-derived XML report." }, { "id": "SRC-022", "title": "Maven Surefire test report XSD (surefire-test-report.xsd)", "organization": "Apache Software Foundation", "url": "https://raw.githubusercontent.com/apache/maven-surefire/master/maven-surefire-plugin/src/site/resources/xsd/surefire-test-report.xsd", "version_or_date": "master branch, retrieved 2026-09-03; no targetNamespace declared", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T09:30:00Z", "relevance": "First-party schema for the de facto JUnit-style XML projection: testsuite/testcase with failure, error, skipped, rerunFailure, rerunError, flakyFailure, flakyError, stackTrace, system-out/system-err and properties; shows the format carries no record identifier." }, { "id": "SRC-023", "title": "Maven Surefire Plugin — Rerun failing tests", "organization": "Apache Software Foundation", "url": "https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html", "version_or_date": "Maven Surefire Plugin 3.6.0-M1 documentation, retrieved 2026-09-03", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-09-03T09:31:00Z", "relevance": "Documents retry semantics in a widely deployed harness: flakyFailure/flakyError when a test eventually passes versus failure plus rerunFailure/rerunError when all attempts fail, and the reported time being that of the last successful or first failing run." }, { "id": "SRC-024", "title": "OSLC Quality Management Version 2.1. Part 1: Specification", "organization": "OASIS", "url": "https://docs.oasis-open-projects.org/oslc-op/qm/v2.1/os/quality-management-spec.html", "version_or_date": "OASIS Standard, 19 January 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:13:00Z", "relevance": "Normative resource shapes for TestPlan, TestCase, TestScript, TestExecutionRecord and TestResult with validatesRequirement, executesTestScript, runsOnTestEnvironment, producedByTestExecutionRecord, status and change-request links; the primary interoperability alignment target for cross-tool exchange." }, { "id": "SRC-025", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:13:00Z", "relevance": "Entity/Activity/Agent model with wasGeneratedBy, wasDerivedFrom, wasAttributedTo, wasAssociatedWith, actedOnBehalfOf, startedAtTime, endedAtTime and qualified Association carrying hadRole and hadPlan; the alignment basis for execution provenance and role-qualified responsibility." }, { "id": "SRC-026", "title": "21 CFR Part 11 - Electronic Records; Electronic Signatures", "organization": "U.S. Food and Drug Administration / U.S. Government Publishing Office", "url": "https://www.govinfo.gov/content/pkg/CFR-2024-title21-vol1/xml/CFR-2024-title21-vol1-part11.xml", "version_or_date": "CFR revised as of April 1, 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:14:00Z", "relevance": "11.10 requires validation, accurate and complete human-readable and electronic copies, protection for ready retrieval through the retention period, access limitation, secure computer-generated time-stamped audit trails, operational system checks enforcing sequencing, authority checks, accountability policies and revision/change control. 11.50 requires printed name, date and time of signing and signature meaning such as review or approval; 11.70 requires signatures to be linked so they cannot be excised, copied or transferred." }, { "id": "SRC-027", "title": "Regulation (EU) 2016/679 (General Data Protection Regulation)", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679", "version_or_date": "Regulation (EU) 2016/679 of 27 April 2016", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:14:00Z", "relevance": "Article 5(1)(b) purpose limitation, 5(1)(c) minimisation, 5(1)(e) storage limitation and 5(2) accountability; Article 25 data protection by design and by default; Article 32(1)(a) pseudonymisation and encryption and 32(1)(d) regular testing of measures. Governs production-derived personal data appearing in test inputs, logs and attachments and bounds retention of such evidence." }, { "id": "SRC-028", "title": "Regulation (EU) 2024/1689 (Artificial Intelligence Act)", "organization": "European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202401689", "version_or_date": "Regulation (EU) 2024/1689 of 13 June 2024, OJ 12 July 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:15:00Z", "relevance": "Article 9 requires testing against prior defined metrics within a continuous risk management system; Article 17 requires examination, test and validation procedures in the quality management system; Article 18 requires technical documentation retention for ten years; Articles 12 and 19 require automatically generated logs kept at least six months. A concrete sector profile where retention and record-keeping obligations differ from the organisational default." }, { "id": "SRC-029", "title": "Universal Electronic Records Management (ERM) Requirements", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/records-mgmt/policy/universalermrequirements", "version_or_date": "Version 3, 23 June 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:15:00Z", "relevance": "Baseline electronic records requirements organised as capture, maintenance and use, disposal, transfer, metadata and reporting, with mandatory and preferred designations. Grounds the separation of retention binding, disposition authority and destruction execution used in this model's delete and tombstone rules." }, { "id": "SRC-030", "title": "in-toto Attestation Framework: Statement layer, version 1", "organization": "in-toto project (Open Source Security Foundation)", "url": "https://github.com/in-toto/attestation/blob/main/spec/v1/statement.md", "version_or_date": "Statement layer v1, _type https://in-toto.io/Statement/v1, accessed 2026-09-03", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:16:00Z", "relevance": "Defines _type, subject with required digest, predicateType and predicate, and states that subject artifacts are matched purely by digest regardless of content type and treated as immutable. Grounds digest-based binding of evidence artifacts to result records and the rule that redaction changes the digest." }, { "id": "SRC-031", "title": "SLSA Provenance", "organization": "SLSA / Open Source Security Foundation", "url": "https://slsa.dev/spec/v1.0/provenance", "version_or_date": "v1.0 (page marked retired; v1.2 is current)", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-09-03T09:16:00Z", "relevance": "buildDefinition with externalParameters, internalParameters and resolvedDependencies, and runDetails with builder.id, invocationId, startedOn, finishedOn and byproducts. Supplies the pattern for identifying the producing platform, its inputs and its start and finish times, and the discipline of stating what provenance does not attest." }, { "id": "SRC-032", "title": "Secure Software Development Framework (SSDF), NIST SP 800-218", "organization": "U.S. National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/Projects/ssdf", "version_or_date": "SP 800-218 Version 1.1, February 2022", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:17:00Z", "relevance": "Practice groups PO, PS, PW and RV; PS protects components from tampering and unauthorized access and version 1.1 added a task on collecting and sharing provenance data for all components of software releases. Supports evidence tamper-protection and provenance capture as named practices rather than local invention. Individual task text is in the PDF, not the project page." }, { "id": "SRC-033", "title": "IEEE Std 1012-2024, IEEE Standard for System, Software, and Hardware Verification and Validation", "organization": "IEEE", "url": "https://ieeexplore.ieee.org/document/11134780", "version_or_date": "IEEE Std 1012-2024", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-09-03T09:18:00Z", "relevance": "Maps likelihood and consequence onto four integrity levels and varies the intensity and depth of V&V activity by integrity level; establishes independence as a graded property of the V&V effort. Grounds integrity-level-driven separation of duties. Full text is paywalled; metadata and scope confirmed from the publisher record." } ], "structure": { "bundles": [ { "id": "tst-design-bundle-identity-intent", "name": "Test Case Identity and Intent", "description": "Everything needed to name a reusable test case unambiguously, to pin the exact revision an execution used, to state what the case exists to verify, and to bind it to the normative basis it was derived from.", "rationale": "Cited metadata and assertion specifications make an unambiguous identifier, a version, a stated purpose and a reference to the specification statements under test mandatory or near-mandatory properties of a test; without them a recorded result cannot be attributed to a definition and derivation from a test basis cannot be assessed. Technique and general-concept standards add the derivation chain from test basis through coverage items to cases.", "source_refs": [ "SRC-005", "SRC-006", "SRC-002", "SRC-004" ], "layers": [ { "id": "tst-design-layer-identity-revision", "name": "Identity and Revision Control", "description": "The authoritative identifier of a test case, the identity of each revision of its definition, and the immutability guarantees that let past evidence stay interpretable.", "source_refs": [ "SRC-005", "SRC-006", "SRC-001" ], "findings": [ { "id": "tst-design-finding-case-identity", "name": "Authoritative test case identity", "description": "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.", "source_refs": [ "SRC-005", "SRC-006", "SRC-011" ], "questions": [ { "id": "tst-design-q-identity-authority", "text": "Which system holds the authoritative identifier for this test case, and what identifier value does it issue?", "kind": "identity", "answer_data": [ "Master-system reference for test case identity", "Authoritative test case identifier value", "Identifier scheme or namespace reference" ] }, { "id": "tst-design-q-identity-alternates", "text": "Which alternate or legacy identifiers must resolve to this test case, and in which external systems do they live?", "kind": "interoperability", "answer_data": [ "Alternate identifier values", "Issuing system reference per alternate identifier", "Validity window of each mapping" ] }, { "id": "tst-design-q-identity-stability", "text": "What identity guarantees hold when the test case is renamed, moved between repositories or migrated between tools?", "kind": "constraint", "answer_data": [ "Identifier stability rule", "Rename and relocation handling rule", "Migration mapping record reference" ] }, { "id": "tst-design-q-identity-discrimination", "text": "What distinguishes one test case from a variant, a duplicate and a differently-named copy of the same test?", "kind": "definition", "answer_data": [ "Identity criteria set covering objective, oracle and parameter signature", "Duplicate detection rule", "Variant relationship reference" ] } ], "data_elements": [ { "id": "tst-design-de-case-identifier", "name": "Test case identifier", "description": "Authoritative identifier of the reusable test case, issued by the master system for test cases.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "tst-design-de-case-identifier-scheme", "name": "Identifier scheme", "description": "Coded scheme or namespace under which the authoritative identifier is unique.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-case-master-system", "name": "Master system reference", "description": "Reference to the system of record that issued and governs the authoritative identifier.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-case-alternate-identifiers", "name": "Alternate identifiers", "description": "Legacy or external identifiers that must resolve to this test case, each with its issuing system.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Identity here is pure reference data: an identifier value, its issuing scheme, the master-system pointer and alternate-identifier mappings are resolved inline by every consumer. Materialising identity as a separate stored artifact would create a second competing source of truth for the same identifier and would invite drift between that artifact and the master system." }, { "id": "tst-design-finding-revision-immutability", "name": "Revision identity and definition immutability", "description": "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.", "source_refs": [ "SRC-005", "SRC-001", "SRC-006" ], "questions": [ { "id": "tst-design-q-revision-creation", "text": "How is a new revision of the test case definition created, numbered and superseded?", "kind": "lifecycle", "answer_data": [ "Revision identifier", "Supersedes reference to prior revision", "Change reason code", "Revision status value" ] }, { "id": "tst-design-q-revision-provenance", "text": "Who authored or changed this revision, on what authority, and from which prior revision was it derived?", "kind": "provenance", "answer_data": [ "Author or editor reference", "Authorising role or approval reference", "Derived-from revision reference" ] }, { "id": "tst-design-q-revision-times", "text": "Which timestamps distinguish when a revision became effective from when the register recorded it?", "kind": "temporal", "answer_data": [ "Effective event time in RFC 3339 with explicit offset", "Recording or ingestion time in RFC 3339 with explicit offset", "Explanation where the two differ" ] }, { "id": "tst-design-q-revision-materiality", "text": "Which changes to a definition require a new revision rather than an in-place editorial correction?", "kind": "constraint", "answer_data": [ "Materiality rule", "Field-level change classification", "Editorial versus semantic change flag" ] }, { "id": "tst-design-q-revision-integrity", "text": "How can a consumer prove that the definition referenced by a past execution has not been altered?", "kind": "evidence", "answer_data": [ "Canonical serialization rule reference", "Digest algorithm and digest value", "Definition snapshot artifact reference" ] } ], "data_elements": [ { "id": "tst-design-de-revision-identifier", "name": "Revision identifier", "description": "Identifier of one revision of the test case definition, unique within the test case.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-revision-supersedes", "name": "Supersedes revision", "description": "Reference to the revision that this revision replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-revision-effective-time", "name": "Revision effective time", "description": "Event time at which the revision became the effective definition.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "tst-design-de-revision-recorded-time", "name": "Revision recorded time", "description": "Observation or ingestion time at which the model recorded the revision.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "tst-design-de-revision-digest", "name": "Revision content digest", "description": "Digest algorithm and value computed over the canonical serialization of the revision.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-003" ] }, { "id": "tst-design-de-revision-change-reason", "name": "Change reason", "description": "Coded reason for creating the revision, drawn from a controlled vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "tst-design-artifact-definition-snapshot", "name": "Test case definition snapshot", "description": "Immutable, canonically serialized capture of exactly one test case definition revision, addressable by content digest, cited by executions and evidence consumers to prove which definition text was in force.", "media_or_form": [ "canonical structured document", "content-addressed blob", "version-control tagged object" ], "serial": true, "identity_strategy": "Identity is the content digest over the canonical serialization, bound to the authoritative test case identifier plus the revision identifier; the revision identifier gives the ordinal position in the series and the digest gives integrity. No date component participates in the identity.", "source_refs": [ "SRC-005", "SRC-006", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-design-layer-intent-traceability", "name": "Objective, Classification and Test Basis Traceability", "description": "What the test case exists to verify, how it is classified for selection and reporting, and the typed links and derivation record connecting it to requirements, acceptance criteria, risks and coverage items.", "source_refs": [ "SRC-005", "SRC-006", "SRC-002", "SRC-008" ], "findings": [ { "id": "tst-design-finding-objective-classification", "name": "Test objective, test item and classification", "description": "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.", "source_refs": [ "SRC-005", "SRC-002", "SRC-004" ], "questions": [ { "id": "tst-design-q-objective-statement", "text": "What single objective does this test case exist to verify, stated independently of how it is executed?", "kind": "definition", "answer_data": [ "Objective statement text", "Test condition reference", "Scope limitation note" ] }, { "id": "tst-design-q-objective-classification", "text": "Which test level, test type and quality characteristic classify this test case, and from which controlled vocabulary?", "kind": "classification", "answer_data": [ "Test level code", "Test type codes", "Quality characteristic code", "Vocabulary reference" ] }, { "id": "tst-design-q-objective-test-item", "text": "Which test item, component or interface is under test, and how is it referenced?", "kind": "relationship", "answer_data": [ "Test item reference", "Component or interface identifier", "Applicable version constraint" ] }, { "id": "tst-design-q-objective-atomicity", "text": "How is the objective checked for being single-purpose, observable and falsifiable?", "kind": "quality", "answer_data": [ "Review checklist outcome", "Atomicity flag", "Reviewer reference" ] } ], "data_elements": [ { "id": "tst-design-de-case-title", "name": "Title", "description": "Short human-readable name of the test case.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-case-objective", "name": "Objective", "description": "Statement of why the test exists and what it verifies.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-test-level-code", "name": "Test level", "description": "Coded test level such as component, integration, system or acceptance.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-design-de-test-type-code", "name": "Test type", "description": "Coded test type or quality characteristic addressed by the case.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-design-de-test-item-reference", "name": "Test item reference", "description": "Typed reference to the item, component or interface under test.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-006", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Objective, title, classification codes and the test item pointer are short structured values consumed at query time by selection, reporting and traceability functions. They have no rendering, media form or integrity requirement of their own, and any document that displays them is a projection of the definition snapshot already declared in this model." }, { "id": "tst-design-finding-basis-traceability", "name": "Test basis traceability and derivation record", "description": "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.", "source_refs": [ "SRC-005", "SRC-006", "SRC-002", "SRC-008" ], "questions": [ { "id": "tst-design-q-trace-links", "text": "Which requirement, acceptance-criterion, risk or specification statements does this test case revision trace to, and with what link type?", "kind": "relationship", "answer_data": [ "Traceability link set with link type", "Target model reference per link", "Link direction and cardinality" ] }, { "id": "tst-design-q-trace-coverage-items", "text": "Which coverage items does this test case cover, and which test design technique produced them?", "kind": "composition", "answer_data": [ "Design technique code", "Coverage item identifiers", "Coverage model or test condition reference" ] }, { "id": "tst-design-q-trace-prescription", "text": "Which normative statement gives the expected outcome its authority, and what is its prescription level?", "kind": "authority", "answer_data": [ "Normative source reference", "Prescription level value such as mandatory, preferred or permitted", "Quoted or located statement pointer" ] }, { "id": "tst-design-q-trace-completeness", "text": "How is traceability completeness assessed without asserting one-to-one coverage of a requirement?", "kind": "validation", "answer_data": [ "Declared coverage claim", "List of uncovered coverage items", "Many-to-many link set with rationale" ] }, { "id": "tst-design-q-trace-derivation-method", "text": "Was the case written manually, derived from a model, or generated combinatorially, and with which generation parameters?", "kind": "provenance", "answer_data": [ "Derivation method code", "Generator or tool reference", "Generation parameters such as interaction strength and constraints", "Input parameter model reference" ] } ], "data_elements": [ { "id": "tst-design-de-trace-link", "name": "Traceability link", "description": "Typed link from the test case revision to a test basis element held by an external model.", "value_kind": "reference", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "tst-design-de-design-technique", "name": "Design technique", "description": "Coded test design technique used to derive the case.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-design-de-coverage-item", "name": "Coverage item", "description": "Identifier of a coverage item that this case is intended to cover.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-design-de-prescription-level", "name": "Prescription level", "description": "Imperative force of the normative statement behind the expected outcome.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "tst-design-de-derivation-method", "name": "Derivation method", "description": "Coded method by which the case was produced, including generator provenance where applicable.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Traceability is link data whose endpoints are owned by external requirement, acceptance-criterion and risk models. Storing a locally materialised traceability matrix would duplicate those models' content, would go stale on their change events, and would imply local ownership of requirement lifecycle that the reference boundary explicitly withholds; the links are therefore carried inline as typed references only." } ] } ] }, { "id": "tst-design-bundle-specification", "name": "Executable Test Specification", "description": "The verifiable substance of the test case: the entry state it needs, the fixtures and data it references, the stimulus it applies, the outcome it expects with the rule used to compare against it, and the end state it leaves behind.", "rationale": "Cited metadata and assertion specifications make preconditions, inputs, expected results and evaluable predicates first-class parts of a test; technique and combinatorial-testing guidance derives input values and expected results from coverage items and parameter models; and a standardised test notation expresses expected values as reusable, parameterized templates with explicit matching rules. This is the smallest coherent body of context that makes a case executable and its result adjudicable.", "source_refs": [ "SRC-005", "SRC-006", "SRC-002", "SRC-008", "SRC-007" ], "layers": [ { "id": "tst-design-layer-context-setup", "name": "Entry State, Fixtures and Test Data", "description": "Conditions that must hold before execution begins and the versioned fixtures and data sets the case depends on, referenced rather than owned.", "source_refs": [ "SRC-005", "SRC-003", "SRC-008" ], "findings": [ { "id": "tst-design-finding-preconditions", "name": "Preconditions and required entry state", "description": "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.", "source_refs": [ "SRC-005", "SRC-011", "SRC-010" ], "questions": [ { "id": "tst-design-q-precondition-state", "text": "What state must the test item, its data and the referenced environment be in before execution begins?", "kind": "state", "answer_data": [ "Precondition statements", "Required test item state", "Required data state", "Referenced environment expectation" ] }, { "id": "tst-design-q-precondition-gating", "text": "Which preconditions are mandatory gates and which are advisory assumptions that merely make the case inapplicable?", "kind": "constraint", "answer_data": [ "Gate versus assumption flag per precondition", "Declared inapplicability semantics", "Checkable expression where available" ] }, { "id": "tst-design-q-precondition-establishment", "text": "How is each precondition established: by the case itself, by a referenced fixture, or by an external set-up step?", "kind": "process", "answer_data": [ "Establishment mode code", "Fixture or shared background reference", "External set-up owner reference" ] }, { "id": "tst-design-q-precondition-unmet", "text": "What disposition does the definition declare when a precondition cannot be established?", "kind": "exception", "answer_data": [ "Declared not-run or skip disposition code", "Blocking dependency reference", "Escalation or notification reference" ] } ], "data_elements": [ { "id": "tst-design-de-precondition-statement", "name": "Precondition statement", "description": "One checkable condition required before execution.", "value_kind": "text", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-precondition-kind", "name": "Precondition kind", "description": "Whether the precondition is a mandatory gate or an applicability assumption.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tst-design-de-precondition-check-reference", "name": "Precondition check reference", "description": "Reference to an executable or documented check that evaluates the precondition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "tst-design-de-unmet-precondition-disposition", "name": "Unmet precondition disposition", "description": "Coded disposition the definition declares when a precondition cannot be established.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Preconditions are short declarative statements plus optional pointers to checks that live in fixtures or executable code owned elsewhere. They are read inline during authoring review and during resolution, and packaging them as a separate artifact would fragment one definition revision across two integrity anchors without adding any retrievable content." }, { "id": "tst-design-finding-fixtures-testdata", "name": "Fixture and test data references", "description": "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.", "source_refs": [ "SRC-003", "SRC-008", "SRC-010" ], "questions": [ { "id": "tst-design-q-data-references", "text": "Which fixtures and test data sets does this case require, and how are they referenced and versioned?", "kind": "relationship", "answer_data": [ "Fixture references", "Data set identifier and version", "Resolution rule for the reference" ] }, { "id": "tst-design-q-data-sensitivity", "text": "What sensitivity classification applies to the referenced test data, and is production-derived data permitted for this case?", "kind": "privacy", "answer_data": [ "Sensitivity classification code", "Production-derived data permission flag", "Masking or synthesis requirement reference" ] }, { "id": "tst-design-q-data-composition", "text": "Which parts of the referenced data are inputs, which are seeded state and which are expected baselines?", "kind": "composition", "answer_data": [ "Role assignment per data component", "Seed state description", "Baseline component reference" ] }, { "id": "tst-design-q-data-determinism", "text": "What determinism and isolation guarantees must the data satisfy for the expected outcome to hold?", "kind": "constraint", "answer_data": [ "Determinism guarantee statement", "Isolation or exclusivity requirement", "Refresh or reset expectation" ] }, { "id": "tst-design-q-data-resolvability", "text": "How long must a referenced data set remain resolvable for past evidence to stay interpretable?", "kind": "retention", "answer_data": [ "Minimum resolvability period", "Retention class reference", "Declared behaviour when a version is withdrawn" ] } ], "data_elements": [ { "id": "tst-design-de-fixture-reference", "name": "Fixture reference", "description": "Reference to a reusable fixture or shared background that establishes state for the case.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-003" ] }, { "id": "tst-design-de-dataset-reference", "name": "Test data set reference", "description": "Identifier and version of a referenced test data set.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "tst-design-de-data-sensitivity-class", "name": "Data sensitivity class", "description": "Classification of the referenced data governing access and masking.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "tst-design-de-data-provisioning-mode", "name": "Provisioning mode", "description": "How the data is made available: pre-seeded, generated at resolution, or supplied by the environment.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "tst-design-artifact-test-data-set", "name": "Referenced test data set version", "description": "A named, versioned collection of seed state and input values that a test case revision requires, held or referenced as a resolvable, integrity-checked object rather than re-authored per execution.", "media_or_form": [ "tabular data file", "structured data document", "database seed script", "binary fixture bundle" ], "serial": true, "identity_strategy": "Authoritative data-set identifier issued by the owning test data system where one exists; otherwise a governed data-set IRI in a controlled namespace; otherwise a UUID or ULID assigned by the adopting Dimension. Each version carries a content digest, and a test case reference names identifier plus version, never a file path or a date.", "source_refs": [ "SRC-003", "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-design-layer-stimulus", "name": "Inputs, Parameters and Ordered Actions", "description": "The declared parameter surface of the case, the value sets that produce data-driven variants, and the ordered actions that apply the stimulus.", "source_refs": [ "SRC-005", "SRC-008", "SRC-010", "SRC-007" ], "findings": [ { "id": "tst-design-finding-inputs-parameters", "name": "Inputs, parameters and parameterized variants", "description": "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.", "source_refs": [ "SRC-005", "SRC-008", "SRC-007", "SRC-011" ], "questions": [ { "id": "tst-design-q-parameter-declaration", "text": "Which parameters does the test case declare, with what types, defaults and value constraints?", "kind": "composition", "answer_data": [ "Parameter names and types", "Default values", "Value constraint expressions" ] }, { "id": "tst-design-q-variant-identity", "text": "When a parameter set produces many invocations, what is the identity of each variant relative to the parent test case?", "kind": "identity", "answer_data": [ "Variant key derivation rule", "Parent case reference", "Declared decision on whether a variant is a distinct case" ] }, { "id": "tst-design-q-value-selection-basis", "text": "On what sampling, boundary or interaction basis are the input values or ranges chosen?", "kind": "measurement", "answer_data": [ "Value set or range specification", "Boundary and equivalence rationale", "Interaction strength for combinatorial selection", "Input parameter model reference" ] }, { "id": "tst-design-q-parameter-exclusions", "text": "Which parameter combinations are excluded as invalid, unreachable or unsafe?", "kind": "constraint", "answer_data": [ "Constraint expressions", "Excluded combination list", "Reason code per exclusion" ] }, { "id": "tst-design-q-parameter-binding", "text": "How are parameter values bound at resolution time from external configuration or credential stores?", "kind": "interoperability", "answer_data": [ "Binding expression", "Source system reference", "Secret handling rule prohibiting stored secret values" ] } ], "data_elements": [ { "id": "tst-design-de-parameter-name", "name": "Parameter name", "description": "Declared name of a test case parameter.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-005" ] }, { "id": "tst-design-de-parameter-type", "name": "Parameter type", "description": "Declared type or value domain of a parameter.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "tst-design-de-parameter-constraint", "name": "Parameter constraint", "description": "Constraint restricting permitted values or combinations of values.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "tst-design-de-variant-key", "name": "Variant key", "description": "Stable key identifying one parameter set of the parent test case.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "tst-design-de-parameter-binding-expression", "name": "Parameter binding expression", "description": "Expression resolving a parameter value from an external source at resolution time.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Parameter declarations are structural metadata of the definition itself and belong inside the definition revision that is already snapshotted. The concrete value collections that fill them are held in the referenced test data set artifact declared in the fixture finding, so declaring a second artifact here would split one logical payload across two artifacts with competing versions." }, { "id": "tst-design-finding-action-sequence", "name": "Ordered actions and step structure", "description": "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.", "source_refs": [ "SRC-010", "SRC-003", "SRC-001", "SRC-007" ], "questions": [ { "id": "tst-design-q-action-sequence", "text": "What is the ordered sequence of actions the test case prescribes, and at what granularity is a step defined?", "kind": "process", "answer_data": [ "Ordered step list", "Step granularity rule", "Step text or keyword invocation" ] }, { "id": "tst-design-q-step-identity", "text": "How is an individual step identified so that expected outcomes and captured evidence can attach to it?", "kind": "identity", "answer_data": [ "Step identifier", "Step ordinal", "Stability rule when steps are inserted or removed" ] }, { "id": "tst-design-q-step-roles", "text": "Which steps are shared set-up or teardown and which are the discriminating actions of this case?", "kind": "composition", "answer_data": [ "Step role classification", "Shared background reference", "Discriminating step list" ] }, { "id": "tst-design-q-step-ordering-rules", "text": "Is the step order significant, and which steps may be reordered, repeated or run concurrently?", "kind": "constraint", "answer_data": [ "Order significance flag", "Repeatable step markers", "Concurrency permission per step" ] }, { "id": "tst-design-q-step-delegation", "text": "Where a step delegates to a reusable keyword or shared step definition, how is that reference resolved?", "kind": "relationship", "answer_data": [ "Keyword or step definition reference", "Resolution and versioning rule", "Owning library reference" ] } ], "data_elements": [ { "id": "tst-design-de-step-identifier", "name": "Step identifier", "description": "Stable identifier of one action step within the test case revision.", "value_kind": "identifier", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-003", "SRC-010" ] }, { "id": "tst-design-de-step-ordinal", "name": "Step ordinal", "description": "Position of the step in the prescribed order.", "value_kind": "number", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "tst-design-de-step-action-text", "name": "Step action", "description": "Statement of the action performed at this step.", "value_kind": "text", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "tst-design-de-step-keyword-reference", "name": "Step keyword reference", "description": "Reference to a reusable keyword or shared step definition realising the step.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "tst-design-de-step-concurrency-flag", "name": "Step concurrency permission", "description": "Whether the step may run concurrently with adjacent steps.", "value_kind": "boolean", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "tst-design-artifact-case-specification-document", "name": "Test case specification document", "description": "The authored, human- and machine-readable rendering of one test case revision covering objective, preconditions, ordered steps and expected outcomes, in the form in which authors maintain it, such as an executable scenario file, a keyword-driven step table or a structured specification document. Distinct from the definition snapshot, which is the canonical serialization used for integrity rather than for authoring.", "media_or_form": [ "executable scenario file", "keyword-driven step table", "structured specification document", "rendered human-readable page" ], "serial": false, "identity_strategy": "Bound to the authoritative test case identifier plus the revision identifier; where the document is the authoring source of truth its repository object identifier is recorded, and its content digest must reconcile with the digest recorded on the corresponding definition snapshot.", "source_refs": [ "SRC-010", "SRC-003", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-design-layer-oracle-outcome", "name": "Expected Outcome, Oracle and End State", "description": "What a conforming test item must produce, the rule and tolerance by which agreement is decided, the baselines the comparison uses, and the state the case must leave behind.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-008" ], "findings": [ { "id": "tst-design-finding-expected-outcome-oracle", "name": "Expected outcomes, oracle and tolerances", "description": "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.", "source_refs": [ "SRC-005", "SRC-006", "SRC-007", "SRC-008" ], "questions": [ { "id": "tst-design-q-expected-outcome", "text": "What outcome must a conforming test item produce, stated per step and for the case overall?", "kind": "requirement", "answer_data": [ "Expected outcome statements per step", "Overall expected outcome", "Observability point for each expectation" ] }, { "id": "tst-design-q-oracle-tolerance", "text": "Which comparison rule, tolerance and units apply when the expected outcome is numeric or approximate?", "kind": "measurement", "answer_data": [ "Comparison operator or predicate", "Tolerance value and unit", "Rounding and precision rule" ] }, { "id": "tst-design-q-oracle-baseline", "text": "Which reference baseline or golden artifact does the comparison use, and how is it versioned?", "kind": "evidence", "answer_data": [ "Baseline artifact reference and version", "Baseline digest", "Rule for approving a baseline update" ] }, { "id": "tst-design-q-oracle-normalization", "text": "Which parts of an observed outcome are normalized, masked or ignored before comparison?", "kind": "constraint", "answer_data": [ "Normalization rules", "Masked or volatile field list", "Order-insensitivity flags" ] }, { "id": "tst-design-q-oracle-handoff", "text": "What agreement criterion does the definition fix, and what is explicitly left for result adjudication to decide?", "kind": "decision", "answer_data": [ "Fixed agreement criterion expression", "Criteria intentionally left open", "Handoff note to the adjudicating structures" ] } ], "data_elements": [ { "id": "tst-design-de-expected-outcome", "name": "Expected outcome", "description": "Statement of the outcome a conforming test item must produce, per step or overall.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-comparison-rule", "name": "Comparison rule", "description": "Predicate or matching rule that decides agreement between expected and observed outcome.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "id": "tst-design-de-tolerance-value", "name": "Tolerance", "description": "Permitted deviation for an approximate comparison.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "tst-design-de-tolerance-unit", "name": "Tolerance unit", "description": "Unit of measure in which the tolerance is expressed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "tst-design-de-baseline-reference", "name": "Baseline reference", "description": "Reference to the reference baseline used by the comparison.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-normalization-rule", "name": "Normalization rule", "description": "Rule normalizing, masking or ignoring parts of an observed outcome before comparison.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "tst-design-artifact-expected-baseline", "name": "Expected outcome baseline", "description": "A versioned reference artifact holding the expected value, golden output, reference rendering or validation schema against which an observed outcome is compared.", "media_or_form": [ "golden output file", "reference image or rendering", "expected structured document", "validation schema" ], "serial": true, "identity_strategy": "Authoritative baseline identifier from the owning baseline store where one exists; otherwise a governed IRI; otherwise a UUID or ULID assigned by the adopting Dimension. Every baseline version records a content digest and the test case revision that approved it, and sequence position rather than a date orders the series.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "tst-design-finding-postconditions", "name": "Postconditions, end state and side-effect limits", "description": "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.", "source_refs": [ "SRC-005", "SRC-010", "SRC-011" ], "questions": [ { "id": "tst-design-q-postcondition-state", "text": "What state must hold after the case completes, independently of the outcome it produced?", "kind": "state", "answer_data": [ "Postcondition statements", "Required end state of the test item", "Required end state of referenced data" ] }, { "id": "tst-design-q-postcondition-cleanup", "text": "Which cleanup or restoration obligations does the case declare, and who performs them?", "kind": "process", "answer_data": [ "Cleanup obligation list", "Performing actor or fixture reference", "Order relative to the final step" ] }, { "id": "tst-design-q-postcondition-dependents", "text": "Which downstream cases depend on state that this case deliberately leaves behind?", "kind": "relationship", "answer_data": [ "Dependent case references", "Described residual state", "Coupling risk note" ] }, { "id": "tst-design-q-postcondition-side-effects", "text": "Which side effects are permitted, and which must never escape the test boundary?", "kind": "constraint", "answer_data": [ "Permitted side-effect list", "Prohibited side-effect list", "Containment control reference" ] } ], "data_elements": [ { "id": "tst-design-de-postcondition-statement", "name": "Postcondition statement", "description": "Condition required to hold after the case completes.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-cleanup-obligation", "name": "Cleanup obligation", "description": "Declared restoration or teardown duty and its performing actor.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "tst-design-de-side-effect-allowance", "name": "Side-effect allowance", "description": "Coded statement of permitted and prohibited side effects.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tst-design-de-leaves-state-flag", "name": "Leaves residual state", "description": "Whether the case intentionally leaves state for dependent cases.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Postconditions and side-effect limits are declarative constraints read during authoring review and during resolution; they produce no stored payload of their own. Any observed end state belongs to an execution record, which is a governed member of this aggregate rather than an artifact of the reusable definition." } ] } ] }, { "id": "tst-design-bundle-binding-readiness", "name": "Binding, Applicability and Readiness", "description": "What turns a reusable definition into something an agent may legitimately select and resolve: its binding to an executable implementation, the conditions and attributes that make it applicable and selectable, its dependencies, and the ownership and readiness state that authorises use.", "rationale": "Keyword-driven testing standards make the decomposition of a case into reusable keywords and its exchange between frameworks explicit; first-party automation ecosystems make unique identifiers, tags with selection expressions, parameterized variants and conditional applicability explicit; and cited metadata makes Status, Contributor and Rights required properties. A definition without binding, applicability and an accountable owner cannot be safely resolved for execution.", "source_refs": [ "SRC-003", "SRC-011", "SRC-010", "SRC-005" ], "layers": [ { "id": "tst-design-layer-binding-applicability", "name": "Automation Binding, Applicability and Dependencies", "description": "How a definition points at the implementation that realises it, and the declared conditions, attributes and dependencies that determine when it is applicable and selectable.", "source_refs": [ "SRC-003", "SRC-011", "SRC-010" ], "findings": [ { "id": "tst-design-finding-automation-binding", "name": "Automation binding to an executable implementation", "description": "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.", "source_refs": [ "SRC-003", "SRC-011", "SRC-007" ], "questions": [ { "id": "tst-design-q-binding-target", "text": "Which executable implementation realises this test case revision, and how is it addressed?", "kind": "relationship", "answer_data": [ "Implementation reference such as repository, path and symbol", "Keyword decomposition where modular", "Address resolution rule" ] }, { "id": "tst-design-q-binding-contract", "text": "Which automation framework contract must the implementation satisfy for the binding to be valid?", "kind": "interoperability", "answer_data": [ "Framework or engine identifier", "Required interface or annotation contract", "Exchange format reference" ] }, { "id": "tst-design-q-binding-integrity", "text": "How is a binding detected as broken, ambiguous or pointing at a different revision than intended?", "kind": "validation", "answer_data": [ "Binding validation check", "Ambiguity resolution rule", "Reported binding defect state" ] }, { "id": "tst-design-q-binding-automation-status", "text": "Is this case manual, automatable, automated or generated, and who decides that status?", "kind": "classification", "answer_data": [ "Automation status code", "Deciding role reference", "Status change reason" ] }, { "id": "tst-design-q-binding-stability", "text": "What must remain true of the definition when only the implementation changes?", "kind": "constraint", "answer_data": [ "Semantic equivalence rule", "Revision impact rule for implementation-only change", "Recorded previous binding value" ] } ], "data_elements": [ { "id": "tst-design-de-automation-status", "name": "Automation status", "description": "Coded status describing whether and how the case is automated.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "tst-design-de-implementation-reference", "name": "Implementation reference", "description": "Resolvable reference to the executable implementation realising the case.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-003" ] }, { "id": "tst-design-de-framework-identifier", "name": "Framework identifier", "description": "Identifier of the automation framework or engine that the binding targets.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tst-design-de-binding-resolution-rule", "name": "Binding resolution rule", "description": "Rule by which an implementation reference is resolved at resolution time.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [], "inline_only_rationale": "The executable script is an artifact of the source repository that owns its review, build and release lifecycle. Declaring it as an artifact of this model would fork that lifecycle and place implementation change control inside a model whose boundary explicitly withholds it, so only a resolvable binding reference and its validity contract are carried inline." }, { "id": "tst-design-finding-applicability-dependencies", "name": "Applicability, selection attributes and dependencies", "description": "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.", "source_refs": [ "SRC-011", "SRC-010", "SRC-005" ], "questions": [ { "id": "tst-design-q-applicability-tags", "text": "Which tags, attributes and priority values are declared for selection, and from which vocabulary?", "kind": "classification", "answer_data": [ "Tag values", "Priority code", "Controlled vocabulary reference" ] }, { "id": "tst-design-q-applicability-conditions", "text": "Under which product configurations, platforms, locales or feature flags is this case applicable?", "kind": "constraint", "answer_data": [ "Applicability condition expressions", "Platform and locale constraints", "Feature flag dependency" ] }, { "id": "tst-design-q-applicability-dependencies", "text": "Which other test cases must have succeeded, or must not run concurrently, for this case to be meaningful?", "kind": "relationship", "answer_data": [ "Depends-on case references", "Mutual exclusion references", "Coupling rationale" ] }, { "id": "tst-design-q-applicability-selection-ownership", "text": "What selection expression would an agent evaluate to include this case in a given scope, and which model owns evaluating and scheduling it?", "kind": "decision", "answer_data": [ "Selection expression grammar reference", "Declared selectable attributes", "Statement that evaluation, sequencing and dispatch are owned by referenced suite, campaign and pipeline models" ] }, { "id": "tst-design-q-applicability-time-bound", "text": "Is applicability time-bounded, for example pending a fix, a deprecation date or a seasonal window?", "kind": "temporal", "answer_data": [ "Applicable-from time in RFC 3339 with explicit offset", "Applicable-until time in RFC 3339 with explicit offset", "Reason code for the bound" ] } ], "data_elements": [ { "id": "tst-design-de-selection-tag", "name": "Selection tag", "description": "Tag value declared on the case for grouping and selection.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "tst-design-de-priority-code", "name": "Priority", "description": "Coded priority or importance used during selection.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-applicability-condition", "name": "Applicability condition", "description": "Condition restricting the configurations, platforms or locales where the case applies.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tst-design-de-depends-on-case", "name": "Depends-on case reference", "description": "Reference to another test case whose outcome or residual state this case depends on.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "tst-design-de-applicable-from", "name": "Applicable from", "description": "Event time from which the case is applicable.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-applicable-until", "name": "Applicable until", "description": "Event time after which the case ceases to be applicable.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Applicability conditions, tags, priority and dependency pointers are queryable attributes of the definition consumed by selection at request time. Persisting them as a stored artifact would snapshot a selection surface that changes with each revision, and any materialised candidate list belongs to the referenced suite or campaign model rather than here." } ] }, { "id": "tst-design-layer-stewardship-readiness", "name": "Stewardship and Readiness", "description": "Who is accountable for a definition, how it is reviewed, who may read or change it, and the readiness state that declares a revision fit to be resolved for execution.", "source_refs": [ "SRC-005", "SRC-009", "SRC-001" ], "findings": [ { "id": "tst-design-finding-ownership-readiness", "name": "Ownership, review and readiness for execution", "description": "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.", "source_refs": [ "SRC-005", "SRC-009", "SRC-001" ], "questions": [ { "id": "tst-design-q-readiness-owner", "text": "Which role or team owns this test case definition, and who maintains it day to day?", "kind": "ownership", "answer_data": [ "Accountable owner reference", "Maintainer reference", "Owning package reference" ] }, { "id": "tst-design-q-readiness-states", "text": "Which readiness states can a definition revision hold, and which transitions between them are permitted?", "kind": "lifecycle", "answer_data": [ "Readiness state vocabulary", "Permitted transition set", "Transition event time and actor" ] }, { "id": "tst-design-q-readiness-authority", "text": "Who may approve a revision as ready for execution, and on what basis?", "kind": "authority", "answer_data": [ "Approver role reference", "Approval basis or criteria reference", "Delegation rule" ] }, { "id": "tst-design-q-readiness-access", "text": "Who may read, propose changes to and publish this definition, and which parts are restricted?", "kind": "access", "answer_data": [ "Read, propose and publish role assignments", "Restricted field or artifact list", "Classification driving the restriction" ] }, { "id": "tst-design-q-readiness-review-criteria", "text": "Which review criteria must a revision satisfy before it is marked ready?", "kind": "quality", "answer_data": [ "Review criteria checklist", "Per-criterion outcome", "Reviewer reference and review time" ] } ], "data_elements": [ { "id": "tst-design-de-owner-reference", "name": "Owner reference", "description": "Reference to the accountable owner of the test case definition.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-maintainer-reference", "name": "Maintainer reference", "description": "Reference to the party maintaining the definition day to day.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-readiness-state", "name": "Readiness state", "description": "Coded state of the definition revision such as draft, in review, ready, deprecated or retired.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "tst-design-de-approver-reference", "name": "Approver reference", "description": "Reference to the party that approved the revision as ready for execution.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "tst-design-de-rights-statement", "name": "Rights statement", "description": "Intellectual property and usage rights attached to the definition and its rendering.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Readiness is a small inline state field with role references and review outcomes. The durable approval record and its audit trail are held by this model's governance structures and by the adopting Dimension's approval and audit systems, so declaring a separate design-side artifact here would create a competing copy of a record this layer does not own." } ] } ] }, { "id": "tst-exec-run-record-bundle", "name": "Execution Record and Run Context", "description": "The identified execution event itself: which frozen test-case revision was exercised, with which parameter values, inside which run, against which build, in which environment, by which actor or tool, at which times, and as which attempt in a retained attempt series.", "rationale": "ISO/IEC/IEEE 29119-3 arranges test documentation by process, keeping execution-time documentation distinct from test-design documentation, and SARIF separates the run and its invocation from the results produced. Without an identified record bound to an immutable definition and a stated context, an observation cannot be interpreted, compared or reproduced.", "source_refs": [ "SRC-017", "SRC-012", "SRC-013", "SRC-021" ], "layers": [ { "id": "tst-exec-identity-binding-layer", "name": "Execution identity and definitional binding", "description": "How an execution record is identified in its own right, how it is pinned to an exact test-case revision and criterion version, and which external records give it context and reproducibility.", "source_refs": [ "SRC-012", "SRC-013", "SRC-017", "SRC-019" ], "findings": [ { "id": "tst-exec-result-identity", "name": "Execution record identity and correlation", "description": "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.", "source_refs": [ "SRC-012", "SRC-013", "SRC-019" ], "questions": [ { "id": "tst-exec-q-identity-authority", "text": "Which system of record issues the authoritative identifier for this execution record, and what is that identifier?", "kind": "identity", "answer_data": [ "Master-system execution identifier value", "Reference to the issuing system of record", "Identifier scheme or format declaration" ] }, { "id": "tst-exec-q-identity-fallback", "text": "When no master-system identifier exists, which governed IRI or Dimension-assigned UUID/ULID stands in, and how is that substitution marked?", "kind": "identity", "answer_data": [ "Governed global identifier or IRI", "Locally minted UUID or ULID", "Assignment authority and locally-assigned flag" ] }, { "id": "tst-exec-q-identity-correlation", "text": "Which stable correlation key groups executions that are logically the same check across different runs?", "kind": "relationship", "answer_data": [ "Correlation identifier for the equivalence class", "Fingerprint or partial-fingerprint set", "Scope over which the correlation key is stable" ] }, { "id": "tst-exec-q-identity-prohibited-keys", "text": "What constraint prevents a date, a status value, a display name or a test-case identifier from acting as the record key?", "kind": "constraint", "answer_data": [ "Uniqueness constraint definition", "Explicitly forbidden key components", "Collision detection and resolution rule" ] } ], "data_elements": [ { "id": "tst-exec-de-execution-id", "name": "Execution record identifier", "description": "Authoritative identifier of this execution/attempt record as issued by its system of record, or the governed or locally minted substitute.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "tst-exec-de-execution-id-system", "name": "Issuing system reference", "description": "Reference to the test-management, harness or CI system that issued the execution identifier, so the identifier can be resolved and its authority judged.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-019" ] }, { "id": "tst-exec-de-execution-correlation-key", "name": "Result correlation key", "description": "Stable key identifying the equivalence class of logically identical executions across runs, modelled on SARIF correlationGuid semantics.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "tst-exec-de-execution-fingerprints", "name": "Result fingerprints", "description": "Named fingerprint strings that let consumers recognise the same logical result after cosmetic changes, without relying on the record identifier.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Identity here is reference data carried on the record itself: identifier values, the issuing-system reference, a correlation key and fingerprint strings. There is no separate document that constitutes the identity, and minting an identity certificate would create a second, competing source of truth alongside the master system." }, { "id": "tst-exec-case-binding", "name": "Binding to the exact test-case revision and parameter values", "description": "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.", "source_refs": [ "SRC-017", "SRC-015", "SRC-013", "SRC-019" ], "questions": [ { "id": "tst-exec-q-binding-revision", "text": "Which immutable test-case revision, and which version of its expected-result or oracle definition, does this execution bind to?", "kind": "composition", "answer_data": [ "Test-case identifier plus revision or digest", "Expected-result / oracle definition version", "Reference to the definition record in the sibling design pass" ] }, { "id": "tst-exec-q-binding-criterion", "text": "Which criterion or rule was evaluated, in which rule version and by which tool component version?", "kind": "identity", "answer_data": [ "Criterion or rule identifier", "Rule or criterion version", "Tool component name and version" ] }, { "id": "tst-exec-q-binding-parameters", "text": "What concrete parameter values, data-set references and randomisation seeds were bound for this execution?", "kind": "measurement", "answer_data": [ "Parameter name and value pairs", "Data-set reference with digest", "Random seed or generator state" ] }, { "id": "tst-exec-q-binding-drift", "text": "What happens to this record if the referenced test case is subsequently modified, deprecated or withdrawn?", "kind": "constraint", "answer_data": [ "Binding immutability rule", "Revision-pinning strategy", "Orphaned-binding handling and flag" ] } ], "data_elements": [ { "id": "tst-exec-de-case-revision-ref", "name": "Bound test-case revision reference", "description": "Reference to the exact, immutable test-case revision exercised, resolvable independently of the current head revision of that case.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-017", "SRC-019" ] }, { "id": "tst-exec-de-case-revision-digest", "name": "Test-case definition digest", "description": "Cryptographic digest over the bound definition, so that a change to the definition is detectable from the result record alone.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "tst-exec-de-criterion-ref", "name": "Evaluated criterion or rule reference", "description": "Identifier and version of the rule, requirement or accessibility criterion evaluated, following SARIF ruleId and ACT rule identification practice.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "tst-exec-de-parameter-binding", "name": "Bound parameter values", "description": "The concrete name/value bindings, data-set references and configuration inputs used for this execution, corresponding to in-toto configuration resource descriptors.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-017" ] }, { "id": "tst-exec-de-random-seed", "name": "Randomisation seed", "description": "Seed or generator state that makes a randomised or property-based execution repeatable.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "The binding is a set of typed references, digests and value pairs held on the record. The test-case definition itself is a document owned by the definition/design pass of this aggregate; reproducing it here as a local artifact would duplicate an externally owned artifact and invite divergence between two copies of the same expectation." }, { "id": "tst-exec-context-refs", "name": "Execution context and reproducibility references", "description": "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.", "source_refs": [ "SRC-013", "SRC-017", "SRC-019", "SRC-020", "SRC-021" ], "questions": [ { "id": "tst-exec-q-context-container", "text": "Which run, suite or campaign contains this execution, and what identifies that container authoritatively?", "kind": "composition", "answer_data": [ "Run identifier and automation details", "Suite or campaign identifier", "Container hierarchy path or parent reference" ] }, { "id": "tst-exec-q-context-subject", "text": "Which build, artifact or source revision was under test, identified by digest rather than by label?", "kind": "relationship", "answer_data": [ "Subject descriptor with name and digest", "Build or release record reference", "Source commit or artifact identifier" ] }, { "id": "tst-exec-q-context-environment", "text": "Which environment or configuration item hosted the execution, and which model owns that record?", "kind": "relationship", "answer_data": [ "Environment or configuration-item reference", "Observed runtime facts such as machine and platform", "Owning model or system for the environment record" ] }, { "id": "tst-exec-q-context-executor", "text": "Which actor, harness or tool executed the case, in which version, and under what observed invocation?", "kind": "provenance", "answer_data": [ "Executing actor or service account reference", "Harness and tool name with version", "Command line, working directory and exit code" ] }, { "id": "tst-exec-q-context-sufficiency", "text": "What minimum context set must be present before this record may be treated as reproducible?", "kind": "quality", "answer_data": [ "Required context field list", "Reproducibility completeness classification", "Reason code for each missing context element" ] } ], "data_elements": [ { "id": "tst-exec-de-run-ref", "name": "Containing run reference", "description": "Reference to the run or invocation that contains this execution, aligned with SARIF run automation details and Open Test Reporting container events.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-021" ] }, { "id": "tst-exec-de-suite-ref", "name": "Suite or campaign reference", "description": "Reference to the suite, campaign or container grouping to which this execution belongs; nesting may be arbitrarily deep.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-020" ] }, { "id": "tst-exec-de-subject-under-test", "name": "Subject under test descriptor", "description": "Name plus digest of the artifact, build or source revision under test, following in-toto subject and ResourceDescriptor semantics.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-019" ] }, { "id": "tst-exec-de-environment-ref", "name": "Execution environment reference", "description": "Reference to the environment or configuration item that hosted the execution, plus the minimal observed runtime facts (machine, platform, account) needed to interpret the result.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013", "SRC-017" ] }, { "id": "tst-exec-de-executor-ref", "name": "Executing actor or tool reference", "description": "Reference to the human tester, service account, harness or analysis tool that performed the execution, with the tool version.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-014", "SRC-013" ] }, { "id": "tst-exec-de-invocation-record", "name": "Observed invocation record", "description": "Command line, arguments, working directory, exit code and execution-successful flag as observed, modelled on the SARIF invocation object.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Context is expressed as typed references into models that own the referenced entities plus a small set of observed runtime facts. Materialising an environment or build description here would copy a target model's state into this record and would go stale the moment the target changes; the reference plus the observed invocation facts is the defensible minimum." } ] }, { "id": "tst-exec-temporal-attempt-layer", "name": "Execution time and attempt series", "description": "Time semantics for an execution attempt, and the append-only series of attempts produced by retries under one logical binding.", "source_refs": [ "SRC-016", "SRC-013", "SRC-021", "SRC-023" ], "findings": [ { "id": "tst-exec-time-points", "name": "Execution time points, duration and clock provenance", "description": "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.", "source_refs": [ "SRC-016", "SRC-013", "SRC-014", "SRC-022" ], "questions": [ { "id": "tst-exec-q-time-event", "text": "What are the start and end times of this attempt, expressed with seconds and an explicit offset or Z?", "kind": "temporal", "answer_data": [ "Attempt start timestamp", "Attempt end timestamp", "Offset or Z designator as recorded" ] }, { "id": "tst-exec-q-time-observation-vs-ingestion", "text": "When was each outcome observed by the executing agent, and when was the record ingested, and do these differ from the event time?", "kind": "temporal", "answer_data": [ "Observation timestamp per outcome", "Record ingestion timestamp", "Recorded reason for any divergence or backfill" ] }, { "id": "tst-exec-q-time-duration", "text": "What duration is reported, measured from which clock and at what resolution?", "kind": "measurement", "answer_data": [ "Duration value with unit", "Clock source and synchronisation status", "Resolution or precision of the measurement" ] }, { "id": "tst-exec-q-time-unknown", "text": "How are unsynchronised, unknown-offset or reconstructed timestamps represented without fabricating precision?", "kind": "quality", "answer_data": [ "Unknown-local-offset convention such as -00:00", "Backfill or reconstruction flag", "Timestamp confidence or provenance note" ] } ], "data_elements": [ { "id": "tst-exec-de-attempt-start-time", "name": "Attempt start time", "description": "RFC 3339 event time at which this attempt began, with seconds and an explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016", "SRC-013" ] }, { "id": "tst-exec-de-attempt-end-time", "name": "Attempt end time", "description": "RFC 3339 event time at which this attempt ended; absent while the attempt is still in progress or was lost.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016", "SRC-013" ] }, { "id": "tst-exec-de-observation-time", "name": "Observation time", "description": "RFC 3339 time at which a specific outcome or measurement was observed by the executing agent, recorded per observation where it differs from the attempt boundaries.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-016" ] }, { "id": "tst-exec-de-ingestion-time", "name": "Record ingestion time", "description": "RFC 3339 time at which the record entered the result store; always recorded separately from event and observation time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "tst-exec-de-attempt-duration", "name": "Attempt duration", "description": "Measured elapsed time of the attempt with its unit and resolution; the JUnit-style projection carries only a bare float here, which is a known lossy mapping.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-023" ] } ], "artifacts": [], "inline_only_rationale": "Time points are scalar values on the record with a declared format rule. There is no document that could carry them more faithfully, and any external time certificate would itself need the same RFC 3339 representation, so an artifact adds indirection without adding evidentiary weight." }, { "id": "tst-exec-attempt-sequence", "name": "Attempts, retries and append-only accumulation", "description": "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.", "source_refs": [ "SRC-023", "SRC-022", "SRC-021", "SRC-018" ], "questions": [ { "id": "tst-exec-q-attempt-ordinal", "text": "What is this attempt's ordinal within the retry group, and which earlier attempt does it directly follow?", "kind": "event", "answer_data": [ "Attempt ordinal number", "Predecessor attempt reference", "Retry group key shared by the series" ] }, { "id": "tst-exec-q-attempt-trigger", "text": "What triggered this retry — harness policy, orchestration rule or human decision — and which policy record applies?", "kind": "process", "answer_data": [ "Retry trigger classification code", "Reference to the governing retry policy record", "Requesting actor reference where human-initiated" ] }, { "id": "tst-exec-q-attempt-immutability", "text": "Which rule guarantees that an earlier attempt's observations, timestamps and attachments cannot be mutated by a later attempt?", "kind": "constraint", "answer_data": [ "Append-only storage constraint", "Immutability marker or sealed-at timestamp", "Rejection behaviour for mutating writes" ] }, { "id": "tst-exec-q-attempt-aggregate", "text": "When attempts in one group disagree, how is the group-level outcome reported and which attempt is authoritative?", "kind": "state", "answer_data": [ "Group aggregation rule", "Authoritative attempt reference", "Disagreement flag and retained member outcomes" ] } ], "data_elements": [ { "id": "tst-exec-de-attempt-ordinal", "name": "Attempt ordinal", "description": "One-based position of this attempt within its retry group; ordinals are never reused or renumbered.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-023", "SRC-022" ] }, { "id": "tst-exec-de-attempt-predecessor", "name": "Predecessor attempt reference", "description": "Reference to the attempt this one retries, making the series traversable in both directions.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-023" ] }, { "id": "tst-exec-de-retry-trigger", "name": "Retry trigger code", "description": "Governed code stating what caused the retry, for example automatic harness rerun, orchestration policy or explicit human request.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "tst-exec-de-retry-policy-ref", "name": "Retry policy reference", "description": "Reference to the externally owned retry policy in force; this model records which policy applied, not the policy's evaluation or enforcement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] } ], "artifacts": [], "inline_only_rationale": "Attempt sequencing is relational metadata linking records that already exist. The evidence produced by each attempt is represented by that attempt's own attachments; introducing a separate retry-log artifact would create a third copy of facts already held on the attempt records and on the referenced policy." } ] } ] }, { "id": "tst-exec-outcome-verdict-bundle", "name": "Observed Outcome and Adjudicated Verdict", "description": "What was actually observed and compared, step by step, and separately what verdict an assertor reached over those observations, including non-determinism evidence and the correction history of adjudications.", "rationale": "EARL models an Assertion as made by an assertor in a stated mode over a subject and criterion, with the TestResult carrying the outcome; ACT Rules Format keeps applicability and expectations separate from the reported outcome; SARIF separates the objective kind of a result from its interpreted level. Collapsing observation into verdict makes a result unfalsifiable and unreviewable.", "source_refs": [ "SRC-014", "SRC-015", "SRC-012", "SRC-013" ], "layers": [ { "id": "tst-exec-observation-layer", "name": "Observed outcome and comparison", "description": "The observable facts of an execution: the actual value or system state, how it was compared with the expectation, under what tolerance, and where in the subject the observation applies, including per-step granularity.", "source_refs": [ "SRC-014", "SRC-015", "SRC-013", "SRC-018" ], "findings": [ { "id": "tst-exec-actual-outcome", "name": "Actual outcome and comparison against expectation", "description": "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.", "source_refs": [ "SRC-014", "SRC-015", "SRC-013", "SRC-017" ], "questions": [ { "id": "tst-exec-q-outcome-actual", "text": "What actual value, output or system state was observed, and in what representation was it captured?", "kind": "measurement", "answer_data": [ "Observed actual value or output", "Representation and media type", "Capture method and capturing agent" ] }, { "id": "tst-exec-q-outcome-comparison", "text": "Against which expected value or oracle was the observation compared, and by which comparator?", "kind": "validation", "answer_data": [ "Expected value or oracle reference", "Oracle type classification", "Comparator identity and version" ] }, { "id": "tst-exec-q-outcome-tolerance", "text": "What tolerance, precision, normalisation or masking was applied before the comparison was judged?", "kind": "constraint", "answer_data": [ "Tolerance value with unit or percentage", "Normalisation and canonicalisation rules applied", "Masked or ignored regions and fields" ] }, { "id": "tst-exec-q-outcome-pointer", "text": "Where in the subject does this observation apply, expressed as a pointer, location or region?", "kind": "evidence", "answer_data": [ "Location pointer into the subject", "Region, range or rectangle of interest", "Artifact location URI for the pointed-at content" ] }, { "id": "tst-exec-q-outcome-unevaluable", "text": "How is an observation that could not be evaluated recorded without asserting either pass or fail?", "kind": "exception", "answer_data": [ "Unevaluable or cantTell marker", "Reason code for non-evaluation", "Diagnostic message and partial observation retained" ] } ], "data_elements": [ { "id": "tst-exec-de-actual-value", "name": "Observed actual outcome", "description": "The actual value, output or system state observed, in a declared representation; large payloads are carried by reference to an evidence artifact.", "value_kind": "other", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-014" ] }, { "id": "tst-exec-de-expected-value-ref", "name": "Expected value or oracle reference", "description": "Reference to the expectation actually used at execution time, resolving into the bound test-case revision rather than into the current definition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-017" ] }, { "id": "tst-exec-de-comparator-ref", "name": "Comparator identity and version", "description": "The comparison function, matcher or assertion library and version that produced the comparison result.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "tst-exec-de-tolerance", "name": "Applied tolerance", "description": "Numeric or structural tolerance, precision limit or similarity threshold applied before the comparison was judged.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "tst-exec-de-location-pointer", "name": "Observation pointer", "description": "Pointer, region or range identifying the part of the subject the observation concerns, modelled on EARL pointer and SARIF location semantics.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-013" ] } ], "artifacts": [ { "id": "tst-exec-artifact-comparison-record", "name": "Comparison record", "description": "The materialised comparison between expectation and observation for one attempt: textual diff, structural diff or visual difference image, together with the tolerance actually applied.", "media_or_form": [ "unified text diff", "structured data diff document", "visual difference raster image" ], "serial": true, "identity_strategy": "Authoritative attachment identifier from the artifact store where one exists; otherwise the content digest combined with the owning execution identifier and attempt ordinal.", "source_refs": [ "SRC-013", "SRC-015" ] }, { "id": "tst-exec-artifact-actual-output-capture", "name": "Captured actual output", "description": "The raw observed output or system-state capture that the comparison was performed against, retained so that the comparison can be independently re-derived.", "media_or_form": [ "plain text capture", "structured data document", "binary payload capture" ], "serial": true, "identity_strategy": "Content digest plus owning attempt identifier; where the harness assigns a capture identifier, that master-system identifier takes precedence.", "source_refs": [ "SRC-013", "SRC-022" ] } ], "inline_only_rationale": null }, { "id": "tst-exec-step-outcomes", "name": "Per-step and per-assertion outcomes", "description": "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.", "source_refs": [ "SRC-018", "SRC-021", "SRC-022", "SRC-017" ], "questions": [ { "id": "tst-exec-q-step-inventory", "text": "Which ordered steps or assertions were executed, and what outcome does each carry in its own right?", "kind": "composition", "answer_data": [ "Step ordinal and identifier", "Reference to the step in the bound procedure", "Per-step outcome code and message" ] }, { "id": "tst-exec-q-step-first-deviation", "text": "At which step did execution first deviate, and were the following steps executed, skipped or blocked?", "kind": "state", "answer_data": [ "First deviating step reference", "Disposition of downstream steps", "Abort or bail-out point" ] }, { "id": "tst-exec-q-step-aggregation", "text": "How is the container or suite outcome derived from member outcomes, and is that derivation itself recorded?", "kind": "relationship", "answer_data": [ "Aggregation rule applied", "Derived-outcome flag", "Member counts by outcome value" ] }, { "id": "tst-exec-q-step-granularity", "text": "What distinguishes a step from a nested sub-test, and how deep may the hierarchy legitimately go?", "kind": "definition", "answer_data": [ "Step versus sub-test definition", "Container type code", "Maximum or declared nesting depth" ] } ], "data_elements": [ { "id": "tst-exec-de-step-ordinal", "name": "Step ordinal", "description": "Position of the step or assertion within the executed procedure; TAP test-point identifiers must fall within the declared plan range and should be unique.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "tst-exec-de-step-outcome", "name": "Per-step outcome", "description": "Outcome code for one step, assertion or sub-test, held independently of the parent execution's adjudicated verdict.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-021" ] }, { "id": "tst-exec-de-step-message", "name": "Per-step diagnostic message", "description": "Human-readable message, directive reason or structured diagnostic attached to a step outcome, such as a TAP YAML diagnostic block.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-022" ] }, { "id": "tst-exec-de-container-derivation", "name": "Container outcome derivation", "description": "Record of how a container, suite or sub-test parent outcome was derived from its members, including member counts by outcome.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-022" ] } ], "artifacts": [], "inline_only_rationale": "Step outcomes are a structured, ordered collection of small records on the execution rather than a document; the narrative and byte-level evidence for the same steps is represented once in the attachment finding. Duplicating the step list as a separate artifact would create two orderings that could drift apart under retry." } ] }, { "id": "tst-exec-adjudication-layer", "name": "Verdict, non-determinism and correction", "description": "The asserted verdict over the observations, its authority and mode, the classification of non-deterministic behaviour across attempts, and the append-only correction history of adjudications.", "source_refs": [ "SRC-014", "SRC-015", "SRC-012", "SRC-023" ], "findings": [ { "id": "tst-exec-verdict", "name": "Adjudicated verdict, assertor and status vocabulary", "description": "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.", "source_refs": [ "SRC-014", "SRC-015", "SRC-012", "SRC-013", "SRC-018", "SRC-020" ], "questions": [ { "id": "tst-exec-q-verdict-value", "text": "Which governed verdict value applies to this execution, and what is that value's precise definition in the adopting Dimension?", "kind": "classification", "answer_data": [ "Verdict code value", "Code-list version in force", "Normative definition text for the value" ] }, { "id": "tst-exec-q-verdict-assertor", "text": "Who or what asserted the verdict, in which mode, and on whose authority?", "kind": "authority", "answer_data": [ "Assertor reference", "Assertion mode such as automatic, manual or semi-automatic", "Authority basis or delegation record" ] }, { "id": "tst-exec-q-verdict-basis", "text": "Which recorded observations and which oracle support this verdict, and was it derived or directly reported?", "kind": "provenance", "answer_data": [ "Supporting observation references", "Oracle or criterion reference", "Derived-versus-reported flag" ] }, { "id": "tst-exec-q-verdict-prohibited", "text": "Which verdict and evidence combinations are prohibited, such as a pass with no evaluated expectation or a pass inferred from an absent defect?", "kind": "constraint", "answer_data": [ "Prohibited combination rules", "Required positive-evidence rule for pass", "Validation error codes raised on violation" ] }, { "id": "tst-exec-q-verdict-mapping", "text": "How does this verdict map onto external vocabularies, and which mappings lose information?", "kind": "interoperability", "answer_data": [ "Mapping table with target vocabulary versions", "Lossy-mapping flags per target", "Verbatim source-format value retained" ] } ], "data_elements": [ { "id": "tst-exec-de-verdict-code", "name": "Verdict code", "description": "Governed verdict value for the execution, distinct from any per-step outcome and from the observed facts that support it.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "tst-exec-de-verdict-assertor", "name": "Verdict assertor reference", "description": "Reference to the agent, tool or person that asserted the verdict, following EARL assertedBy semantics.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "tst-exec-de-verdict-mode", "name": "Assertion mode", "description": "How the verdict was reached: automatic, manual, semi-automatic, undisclosed or unknown.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014" ] }, { "id": "tst-exec-de-verdict-basis", "name": "Verdict supporting basis", "description": "References to the observations, comparisons and attachments relied on, so that the verdict can be re-derived and challenged.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-013" ] }, { "id": "tst-exec-de-verdict-severity", "name": "Interpreted severity", "description": "Optional interpreted severity or level accompanying a failing verdict, kept separate from the objective verdict value as SARIF separates level from kind.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "tst-exec-de-verdict-source-value", "name": "Source-format verdict value", "description": "The verbatim status token emitted by the originating harness or format, retained alongside the canonical code so lossy mappings stay auditable.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-020", "SRC-022" ] } ], "artifacts": [], "inline_only_rationale": "A verdict is a single governed code plus assertion metadata and references to its basis; the evidence supporting it is represented once elsewhere. Issuing a separate verdict certificate would either duplicate the record or become a competing authority, and any signed statement over the verdict already belongs to the evidence-integrity finding." }, { "id": "tst-exec-nondeterminism", "name": "Non-determinism and flaky-test evidence", "description": "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.", "source_refs": [ "SRC-023", "SRC-022", "SRC-013", "SRC-015" ], "questions": [ { "id": "tst-exec-q-flaky-evidence", "text": "Across which attempt set, under which proven-identical binding, did the observed outcomes disagree?", "kind": "quality", "answer_data": [ "Attempt set references", "Binding-equality evidence such as matching definition and parameter digests", "Observed disagreement pattern" ] }, { "id": "tst-exec-q-flaky-classification", "text": "How is this execution classified — deterministic, flaky, environment-induced or unknown — and on what evidence?", "kind": "classification", "answer_data": [ "Determinism classification code", "Evidence references supporting the classification", "Classification confidence and classifying agent" ] }, { "id": "tst-exec-q-flaky-verdict-effect", "text": "May a non-determinism classification change the reported verdict, and which role is permitted to decide that?", "kind": "decision", "answer_data": [ "Verdict-effect rule", "Deciding role and authority basis", "Reference to the recorded decision" ] }, { "id": "tst-exec-q-flaky-measure", "text": "What instability measure is reported, over which observation window and with which denominator?", "kind": "measurement", "answer_data": [ "Instability or flake-rate value", "Observation window bounds", "Denominator definition and excluded attempts" ] } ], "data_elements": [ { "id": "tst-exec-de-determinism-class", "name": "Determinism classification", "description": "Governed code recording whether the execution is treated as deterministic, flaky, environment-induced or unclassified.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "tst-exec-de-flake-measure", "name": "Instability measure", "description": "Quantified instability such as a flake rate, with its window and denominator, so the figure is interpretable and comparable.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-023" ] }, { "id": "tst-exec-de-quarantine-ref", "name": "Quarantine or suppression reference", "description": "Reference to an externally owned quarantine, suppression or known-issue record; this model records that the reference exists, not the suppression policy or its enforcement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Non-determinism is a derived property of an attempt set whose underlying evidence already exists on the individual attempts. Materialising a flakiness dossier would freeze a derived judgement as a document and risk it being consumed as primary evidence, which is exactly the observation/adjudication confusion this bundle exists to prevent." }, { "id": "tst-exec-supersession", "name": "Correction, supersession and result revisions", "description": "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.", "source_refs": [ "SRC-012", "SRC-013", "SRC-021", "SRC-017" ], "questions": [ { "id": "tst-exec-q-supersede-states", "text": "Which states may an execution record occupy, and which transitions between them are legal?", "kind": "lifecycle", "answer_data": [ "State code list such as in-progress, recorded, adjudicated, superseded, withdrawn", "Permitted transitions", "Preconditions and required evidence per transition" ] }, { "id": "tst-exec-q-supersede-linkage", "text": "Which revision supersedes which, for what reason, by whom, and effective from when?", "kind": "provenance", "answer_data": [ "Supersedes and superseded-by references", "Reason code and free-text justification", "Correcting actor reference and effective timestamp" ] }, { "id": "tst-exec-q-supersede-versus-retry", "text": "What distinguishes a correction of an adjudication from a new execution attempt, and which must be used in each case?", "kind": "constraint", "answer_data": [ "Correction-versus-retry decision rule", "Evidence-unchanged assertion", "Prohibited-overwrite rule and rejection behaviour" ] }, { "id": "tst-exec-q-supersede-retention", "text": "For how long must a superseded revision remain retrievable, and which policy owns that decision?", "kind": "retention", "answer_data": [ "Minimum retrievability period", "Owning retention policy reference", "Disposition action recorded when the period expires" ] } ], "data_elements": [ { "id": "tst-exec-de-record-state", "name": "Execution record state", "description": "Current lifecycle state of the record, distinct from the verdict it carries.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-017" ] }, { "id": "tst-exec-de-supersedes-ref", "name": "Supersedes reference", "description": "Reference to the revision this record replaces; the replaced revision is retained and remains resolvable.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "tst-exec-de-correction-reason", "name": "Correction reason", "description": "Coded reason plus justification for a superseding adjudication, such as misclassified error, wrong binding or oracle defect.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "tst-exec-de-correction-actor", "name": "Correcting actor reference", "description": "Reference to the actor who issued the correction, recorded with the RFC 3339 effective timestamp of the change.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-016" ] }, { "id": "tst-exec-de-baseline-state", "name": "Baseline comparison state", "description": "Optional state of this result relative to a declared baseline run, aligned with SARIF baselineState values new, unchanged, updated and absent.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [], "inline_only_rationale": "Supersession is expressed as versioned links and reason codes between records that already exist in the store. A standalone correction notice would be a second place where the same change is asserted, and the durable, tamper-evident record of who changed what is owned by the referenced audit-log model rather than by this one." } ] } ] }, { "id": "tst-exec-evidence-bundle", "name": "Evidence, Integrity and Interchange", "description": "The byte-level evidence produced by an execution, the digests and attestations that seal it, the outbound references to defects and consumers, and the format projections through which results leave this model.", "rationale": "SARIF binds artifacts and attachments to results with cryptographic hashes; the in-toto test-result predicate binds a result to the subject under test by digest and requires the configuration used. ISO/IEC/IEEE 29119-3 keeps incident reporting separate from execution logging. Interchange formats such as TAP, Open Test Reporting and JUnit-style XML are distinct projections with differing and lossy semantics.", "source_refs": [ "SRC-013", "SRC-019", "SRC-017", "SRC-018", "SRC-021", "SRC-022" ], "layers": [ { "id": "tst-exec-evidence-artifact-layer", "name": "Evidence capture and integrity", "description": "Which byte-level evidence was captured for an attempt, how it is bound and classified, and how digests and signed attestations make the evidence set tamper-evident.", "source_refs": [ "SRC-013", "SRC-019", "SRC-022" ], "findings": [ { "id": "tst-exec-attachments", "name": "Logs, captures, traces and attachments", "description": "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.", "source_refs": [ "SRC-013", "SRC-022", "SRC-018", "SRC-020" ], "questions": [ { "id": "tst-exec-q-attach-inventory", "text": "Which evidence artifacts were captured for this attempt, and what role does each one play?", "kind": "evidence", "answer_data": [ "Attachment reference and role description", "Media type and byte length", "Capture time and capturing agent" ] }, { "id": "tst-exec-q-attach-binding", "text": "To which attempt, step or observation is each attachment bound, and may one attachment serve several of them?", "kind": "composition", "answer_data": [ "Binding target reference", "Binding cardinality rule", "Region, offset or timecode within the attachment" ] }, { "id": "tst-exec-q-attach-sensitivity", "text": "Do captures contain personal data, secrets or customer content, and what redaction was applied before storage?", "kind": "privacy", "answer_data": [ "Sensitivity classification", "Redaction method and applying agent", "Residual risk note and reviewer" ] }, { "id": "tst-exec-q-attach-durability", "text": "Where is each artifact stored, and which reference stays meaningful if the store is rotated or purged?", "kind": "access", "answer_data": [ "Storage location URI", "Durable reference and content digest", "Availability status such as present, archived or purged" ] } ], "data_elements": [ { "id": "tst-exec-de-attachment-ref", "name": "Attachment reference", "description": "Durable reference to a stored evidence artifact, resolvable independently of the harness working directory.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "tst-exec-de-attachment-role", "name": "Attachment role", "description": "Governed code describing what the attachment evidences, for example harness output, screenshot at failure, trace or coverage data.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-022" ] }, { "id": "tst-exec-de-attachment-media-type", "name": "Attachment media type and length", "description": "Media type and byte length of the stored artifact, enabling safe handling without opening it.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "tst-exec-de-attachment-sensitivity", "name": "Attachment sensitivity classification", "description": "Classification of the artifact's contents for access and retention purposes; the governing policy itself is owned by the adopting Dimension.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "tst-exec-artifact-execution-log", "name": "Execution log capture", "description": "Standard output, standard error and structured harness log emitted during one attempt, retained per attempt so that a retry never displaces the earlier log.", "media_or_form": [ "plain text log file", "structured log record stream", "harness standard output and error capture" ], "serial": true, "identity_strategy": "Master-system attachment identifier from the artifact store; otherwise content digest combined with the owning execution identifier and attempt ordinal.", "source_refs": [ "SRC-022", "SRC-018", "SRC-013" ] }, { "id": "tst-exec-artifact-visual-capture", "name": "Visual capture", "description": "Screenshot, rendered page capture or screen recording taken during an attempt, typically at the point of first deviation.", "media_or_form": [ "raster screenshot image", "screen recording video", "rendered page snapshot" ], "serial": true, "identity_strategy": "Master-system attachment identifier where the capture service assigns one; otherwise content digest plus attempt ordinal and capture timestamp.", "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "tst-exec-artifact-telemetry-trace", "name": "Telemetry trace reference set", "description": "Distributed trace, span set or metric series captured during the attempt and correlated to it by test attributes, referenced rather than copied where the telemetry store owns retention.", "media_or_form": [ "distributed trace export", "metric time-series export", "telemetry correlation reference list" ], "serial": true, "identity_strategy": "Trace or span identifier issued by the telemetry backend as the master-system identifier; otherwise the correlation attribute set plus the attempt identifier.", "source_refs": [ "SRC-020", "SRC-013" ] } ], "inline_only_rationale": null }, { "id": "tst-exec-evidence-integrity", "name": "Digests, sealing and result attestation", "description": "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.", "source_refs": [ "SRC-019", "SRC-013", "SRC-012" ], "questions": [ { "id": "tst-exec-q-integrity-digest", "text": "Which digest algorithm and value seals each evidence artifact and each emitted result document?", "kind": "evidence", "answer_data": [ "Named digest algorithm", "Digest value", "Byte range or canonical form that was digested" ] }, { "id": "tst-exec-q-integrity-attestation", "text": "Which signed attestation, if any, binds this result to the subject under test, and under which predicate type?", "kind": "security", "answer_data": [ "Attestation reference", "Predicate type URI and version", "Subject descriptor with name and digest" ] }, { "id": "tst-exec-q-integrity-reported-check", "text": "What integrity-check outcome has a verifying system reported back, and how is it recorded here without this model performing the check?", "kind": "validation", "answer_data": [ "Reported verification outcome", "Verifying system reference", "Timestamp at which the outcome was recorded" ] }, { "id": "tst-exec-q-integrity-minimum", "text": "What minimum integrity metadata must be present before this result may be exported as release evidence?", "kind": "requirement", "answer_data": [ "Required digest set", "Completeness rule for the evidence manifest", "Handling of artifacts lacking a digest" ] } ], "data_elements": [ { "id": "tst-exec-de-artifact-digest", "name": "Artifact digest", "description": "Named-algorithm digest over an evidence artifact or emitted result document, following SARIF artifact hashes and in-toto ResourceDescriptor digest practice.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-019" ] }, { "id": "tst-exec-de-attestation-ref", "name": "Result attestation reference", "description": "Reference to a signed statement binding this result to the subject under test, with its predicate type URI; the signing and verification lifecycle is external.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "tst-exec-de-reported-verification", "name": "Reported verification outcome", "description": "Outcome of an integrity check as reported by an external verifier, recorded with the verifier reference and the recording time; this model performs no verification itself.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-013" ] } ], "artifacts": [ { "id": "tst-exec-artifact-evidence-manifest", "name": "Evidence manifest", "description": "Enumeration of every evidence artifact belonging to an execution record with its role, location, length and digest, so that omission or substitution of evidence is detectable.", "media_or_form": [ "digest manifest document", "resource descriptor list" ], "serial": false, "identity_strategy": "Owning execution identifier as the master key, with the manifest's own content digest distinguishing successive reissues.", "source_refs": [ "SRC-019", "SRC-013" ] }, { "id": "tst-exec-artifact-signed-attestation", "name": "Signed test-result attestation", "description": "Signed statement carrying a test-result predicate that binds the adjudicated result and its configuration to the digest-identified subject under test, for consumption by release assurance.", "media_or_form": [ "signed statement envelope", "attestation predicate document" ], "serial": false, "identity_strategy": "Predicate type URI plus subject digest and owning execution identifier; the signing infrastructure's own identifier is recorded as a reference, not adopted as this record's key.", "source_refs": [ "SRC-019" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-exec-interchange-layer", "name": "Outbound references and result interchange", "description": "How execution records point outward to defects, waivers and consuming builds, and how the format-neutral record is projected into interchange formats without those projections becoming authoritative.", "source_refs": [ "SRC-017", "SRC-018", "SRC-021", "SRC-022", "SRC-020" ], "findings": [ { "id": "tst-exec-outbound-links", "name": "Defect, waiver and consumer references", "description": "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.", "source_refs": [ "SRC-017", "SRC-019", "SRC-013" ], "questions": [ { "id": "tst-exec-q-links-defect-role", "text": "Which defect or issue records does this execution reference, and in which role — raised, reproduced, verified-fixed or known-issue?", "kind": "relationship", "answer_data": [ "Defect or issue record reference", "Link role code", "Timestamp at which the link was asserted and by whom" ] }, { "id": "tst-exec-q-links-ownership", "text": "Which model or system owns each referenced record's lifecycle, and which of its fields must never be copied into this record?", "kind": "ownership", "answer_data": [ "Owning model or system reference", "Prohibited-copy field list such as defect state and severity", "Resolution rule when the local reference and the target disagree" ] }, { "id": "tst-exec-q-links-no-inference", "text": "What rule prevents a pass verdict from being inferred from the absence of a linked defect or an empty failure list?", "kind": "constraint", "answer_data": [ "Inference prohibition rule", "Required positive evidence for a pass", "Validation error code raised on violation" ] }, { "id": "tst-exec-q-links-consumer", "text": "Which build or release records consume this evidence, and is that reference maintained here, at the consumer, or in both places?", "kind": "relationship", "answer_data": [ "Consuming build or release reference", "Reference directionality declaration", "Back-reference maintenance and staleness rule" ] } ], "data_elements": [ { "id": "tst-exec-de-defect-ref", "name": "Defect or issue reference", "description": "Reference to an externally owned defect record together with the role it plays for this execution and the time the link was asserted.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "tst-exec-de-link-role", "name": "Outbound link role", "description": "Governed code stating the role of an outbound reference, for example raised, reproduced, verified-fixed, waived or known-issue.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-013" ] }, { "id": "tst-exec-de-consumer-ref", "name": "Consuming build or release reference", "description": "Optional back-reference to a build or release that cites this evidence; the release lifecycle and any gating decision remain outside this model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] } ], "artifacts": [], "inline_only_rationale": "These are typed pointers into models that own the referenced entities. Producing a local linkage document would materialise another model's state inside this one, would go stale as targets change, and would blur the ownership boundary this finding exists to enforce." }, { "id": "tst-exec-result-interchange", "name": "Result documents and format projections", "description": "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.", "source_refs": [ "SRC-018", "SRC-021", "SRC-022", "SRC-023", "SRC-020", "SRC-012" ], "questions": [ { "id": "tst-exec-q-interchange-format", "text": "Which interchange format and schema version was emitted, and which semantics does that projection lose?", "kind": "interoperability", "answer_data": [ "Format name and schema version", "Reference to the mapping table used", "List of fields and distinctions dropped in projection" ] }, { "id": "tst-exec-q-interchange-identity", "text": "How do record identifiers survive projection into formats that identify tests only by name, class or ordinal?", "kind": "identity", "answer_data": [ "Identifier carriage mechanism such as a property or extension element", "Name-to-identifier mapping rule", "Collision handling for identical names across products" ] }, { "id": "tst-exec-q-interchange-authority", "text": "Which representation is authoritative when the emitted projection and the internal record disagree?", "kind": "quality", "answer_data": [ "Authority declaration", "Round-trip fidelity class", "Reconstruction limits and known asymmetries" ] }, { "id": "tst-exec-q-interchange-conformance", "text": "How is an emitted document checked against its declared schema, and what is recorded when it does not validate?", "kind": "validation", "answer_data": [ "Declared schema or grammar reference", "Validation outcome record", "Non-conformance note and downstream handling" ] } ], "data_elements": [ { "id": "tst-exec-de-projection-format", "name": "Emitted projection format", "description": "Name and schema or specification version of each interchange format emitted from this record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-021", "SRC-022" ] }, { "id": "tst-exec-de-projection-mapping-ref", "name": "Projection mapping reference", "description": "Reference to the governed mapping table applied for the projection, with its lossy-mapping flags.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020", "SRC-012" ] }, { "id": "tst-exec-de-projection-authority", "name": "Projection authority declaration", "description": "Statement of which representation governs on disagreement; in this model the internal record is authoritative and the projection is derived.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021", "SRC-022" ] } ], "artifacts": [ { "id": "tst-exec-artifact-result-report", "name": "Canonical execution result report", "description": "The format-neutral, self-contained rendering of an execution record set with its bindings, attempts, outcomes, verdicts and evidence manifest, used as the source from which projections are derived.", "media_or_form": [ "structured result document", "tabular result summary", "human-readable report page" ], "serial": true, "identity_strategy": "Owning run or execution identifier from the system of record, combined with the report's content digest to distinguish reissues.", "source_refs": [ "SRC-021", "SRC-017" ] }, { "id": "tst-exec-artifact-format-projection", "name": "Interchange format projection", "description": "A derived, non-authoritative document expressing the result set in an external format for a consuming toolchain, carrying its declared schema version and mapping reference.", "media_or_form": [ "JUnit-style XML report", "TAP 14 stream", "SARIF log file", "Open Test Reporting event document" ], "serial": true, "identity_strategy": "Derived identity: source execution or run identifier plus format name, schema version and content digest; the projection never mints an independent record identity.", "source_refs": [ "SRC-022", "SRC-018", "SRC-012", "SRC-021" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "tst-gov-b-stewardship-lifecycle", "name": "Stewardship and controlled lifecycle", "description": "Who is accountable for a test case or test result record, which roles must act before it becomes usable, and how it moves through defined states, revisions and supersession without losing its earlier meaning.", "rationale": "Test documentation is only reusable as evidence if an accountable owner, an approval act and a controlled revision history are recoverable from the record itself. 21 CFR Part 11 requires accountability policies, authority checks, revision and change control, and signature manifestations carrying the signer, the date and time and the meaning of the signing; IEEE 1012 grades the depth of verification and the independence expected by integrity level; ISO/IEC/IEEE 29119-3 places documentation items inside a defined test process rather than treating them as free-standing files.", "source_refs": [ "SRC-001", "SRC-026", "SRC-033" ], "layers": [ { "id": "tst-gov-l-accountability-assignment", "name": "Accountability and role assignment", "description": "Assignment of ownership, stewardship and custody for records, and the role model that separates authoring, reviewing, approving and executing.", "source_refs": [ "SRC-026", "SRC-033", "SRC-025" ], "findings": [ { "id": "tst-gov-f-ownership-stewardship", "name": "Record ownership, stewardship and custody", "description": "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.", "source_refs": [ "SRC-026", "SRC-025", "SRC-032" ], "questions": [ { "id": "tst-gov-q-accountable-owner", "text": "Which accountable party owns this test case or test result record and the assurance claims derived from it?", "kind": "ownership", "answer_data": [ "Owner party reference resolved in the adopting Dimension's party registry", "Owning organisational unit reference", "Scope of the ownership: definition only, results only, or the whole aggregate" ] }, { "id": "tst-gov-q-steward-delegation", "text": "Which steward maintains the record day to day, and under what delegated authority do they act?", "kind": "authority", "answer_data": [ "Steward party reference", "Delegation instrument reference and its granting authority", "Operations the delegation permits and those it withholds" ] }, { "id": "tst-gov-q-custody-split", "text": "Which custodian holds the stored evidence when custody is separated from record ownership?", "kind": "relationship", "answer_data": [ "Custodian party or system reference", "Storage boundary or jurisdiction in which the evidence resides", "Custody agreement reference governing the split" ] }, { "id": "tst-gov-q-ownership-transfer", "text": "What evidence records a transfer of ownership, and from which moment did it take effect?", "kind": "provenance", "answer_data": [ "Prior owner reference", "Transfer effective-from timestamp", "Transfer authorisation reference and reason" ] } ], "data_elements": [ { "id": "tst-gov-de-owner-party-ref", "name": "Owner party reference", "description": "Reference to the accountable owning party in the adopting Dimension's party registry.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-steward-party-ref", "name": "Steward party reference", "description": "Reference to the party performing day-to-day maintenance under delegated authority.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-custodian-party-ref", "name": "Evidence custodian reference", "description": "Reference to the party or system holding stored evidence when custody differs from ownership.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-032" ] }, { "id": "tst-gov-de-ownership-effective-from", "name": "Ownership effective-from time", "description": "Moment from which the recorded ownership applies, enabling reconstruction of historical accountability.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-ownership-transfer-ref", "name": "Ownership transfer authorisation reference", "description": "Reference to the instrument that authorised a change of owner or steward.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Ownership, stewardship and custody are reference assertions resolved against the adopting Dimension's party registry and delegation instruments. Materialising them as a separate governed artifact would copy party data into this model and create a second, silently divergent source of truth for accountability; the record carries only the references, the effective moment and the transfer authorisation pointer." }, { "id": "tst-gov-f-duty-separation", "name": "Role separation and independence constraints", "description": "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.", "source_refs": [ "SRC-033", "SRC-026", "SRC-009" ], "questions": [ { "id": "tst-gov-q-required-roles", "text": "Which roles must have acted before a test case revision may reach an approved state?", "kind": "authority", "answer_data": [ "Required role set for the target state", "Minimum number of distinct parties per role", "Role qualification or training reference where required" ] }, { "id": "tst-gov-q-prohibited-role-pairs", "text": "Which role combinations are prohibited on the same record revision?", "kind": "constraint", "answer_data": [ "Prohibited role pair codes such as author-and-approver", "Scope of the prohibition: per revision, per record or per campaign", "Enforcement point: admissibility determination at operation time" ] }, { "id": "tst-gov-q-independence-demonstration", "text": "How is the executor's independence from the author demonstrated at the applicable integrity level?", "kind": "evidence", "answer_data": [ "Assigned integrity or criticality level", "Independence dimension claimed: technical, managerial or financial", "Supporting evidence reference for the independence claim" ] }, { "id": "tst-gov-q-conflict-waiver", "text": "Which documented exception permits a role conflict on this record, and who granted it?", "kind": "exception", "answer_data": [ "Waiver reference and grantor party reference", "Waiver validity window", "Compensating control described for the waived separation" ] } ], "data_elements": [ { "id": "tst-gov-de-role-assignment", "name": "Role assignment entry", "description": "Structured assignment binding a party reference to a governance role for a specific record revision.", "value_kind": "object", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-025", "SRC-026" ] }, { "id": "tst-gov-de-prohibited-role-pair", "name": "Prohibited role pair code", "description": "Coded pair of roles that may not be held by the same party on the same revision.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-integrity-level", "name": "Assigned integrity level", "description": "Graded criticality level that determines the required depth of verification and independence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-033" ] }, { "id": "tst-gov-de-independence-claim", "name": "Independence claim", "description": "Declared independence dimension between executor and author, with its supporting evidence reference.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-033" ] }, { "id": "tst-gov-de-conflict-waiver-ref", "name": "Separation-of-duties waiver reference", "description": "Reference to the documented exception permitting an otherwise prohibited role combination.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-026" ] } ], "artifacts": [ { "id": "tst-gov-art-duty-separation-matrix", "name": "Separation-of-duties matrix", "description": "Governed matrix mapping record operations and target states to required roles, prohibited role pairs and the integrity level at which each constraint applies. Referenced by the authorization function rather than re-derived per record.", "media_or_form": [ "structured rule set", "tabular role-by-operation matrix", "human-readable governance document rendition" ], "serial": false, "identity_strategy": "Authoritative identifier of the governing policy record in the adopting Dimension's governance master system; where none exists, a governed IRI in the Dimension namespace; failing that, a UUID or ULID assigned by the adopting Dimension. Each published state carries a revision identifier and an effective-from timestamp.", "source_refs": [ "SRC-026", "SRC-033" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-gov-l-lifecycle-control", "name": "Lifecycle, approval and supersession", "description": "Defined states and transitions for test case definitions and result records, the approval act that gates them, and the rules that govern revision, correction and supersession.", "source_refs": [ "SRC-001", "SRC-026", "SRC-029" ], "findings": [ { "id": "tst-gov-f-state-approval-gates", "name": "Lifecycle states and approval gates", "description": "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.", "source_refs": [ "SRC-026", "SRC-001", "SRC-024" ], "questions": [ { "id": "tst-gov-q-definition-states", "text": "Which lifecycle states are defined for a test case definition, and which for a test result record?", "kind": "state", "answer_data": [ "Definition state vocabulary such as draft, in-review, approved, active, deprecated, retired", "Result state vocabulary such as recorded, validated, adjudicated, final, withdrawn", "Statement of which states permit citation as evidence" ] }, { "id": "tst-gov-q-gated-transitions", "text": "Which transitions require review and approval before the record becomes usable as evidence?", "kind": "lifecycle", "answer_data": [ "Transition identifier with source and target state", "Required role set and any independence condition", "Preconditions that must hold before the transition is admissible" ] }, { "id": "tst-gov-q-signature-manifestation", "text": "What signature manifestation is captured when a record is approved?", "kind": "authority", "answer_data": [ "Printed name of the signer and the signer party reference", "Date and time the signature was executed", "Meaning of the signing such as review, approval, responsibility or authorship" ] }, { "id": "tst-gov-q-approval-binding", "text": "How is an approval bound to the exact revision it approved rather than to the record as a whole?", "kind": "evidence", "answer_data": [ "Approved revision identifier and its content digest", "Binding method that prevents excision, copying or transfer of the signature", "Behaviour when the record is later revised: prior approval retained, new approval required" ] }, { "id": "tst-gov-q-state-rollback", "text": "Under what conditions may an approved record be returned to an earlier state, and what is recorded?", "kind": "decision", "answer_data": [ "Permitted regression transitions and their authorising role", "Reason code and free-text justification", "Effect on results already produced under the approved revision" ] } ], "data_elements": [ { "id": "tst-gov-de-definition-state", "name": "Definition lifecycle state", "description": "Current state of the test case definition within its declared state vocabulary.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-result-state", "name": "Result record state", "description": "Current state of the test result record, distinguishing recorded, validated, adjudicated, final and withdrawn.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-transition-event", "name": "State transition event", "description": "Recorded transition with source state, target state, acting party, moment and reason.", "value_kind": "object", "cardinality": "0..n", "required": true, "source_refs": [ "SRC-026", "SRC-025" ] }, { "id": "tst-gov-de-approval-signature", "name": "Approval signature manifestation", "description": "Signer name and party reference, moment of signing and declared meaning of the signing.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-approved-revision-digest", "name": "Approved revision content digest", "description": "Digest of the exact revision content to which an approval is bound.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-030", "SRC-026" ] } ], "artifacts": [ { "id": "tst-gov-art-state-transition-model", "name": "Lifecycle state and transition model", "description": "Declared state vocabularies for definitions and results with the admissible transitions, their gating roles and preconditions, and which states permit evidentiary citation.", "media_or_form": [ "structured state and transition definition", "directed transition table", "human-readable lifecycle document rendition" ], "serial": false, "identity_strategy": "Authoritative identifier of the lifecycle policy record in the governance master system; otherwise a governed IRI in the Dimension namespace; otherwise a UUID or ULID assigned by the adopting Dimension, with a revision identifier per published state.", "source_refs": [ "SRC-001", "SRC-024" ] }, { "id": "tst-gov-art-approval-record", "name": "Revision approval record", "description": "Immutable record of one approval act carrying the signer, the moment of signing, the declared meaning and the digest of the revision approved. Written once and never edited; a mistaken approval is withdrawn by a superseding record.", "media_or_form": [ "structured signed assertion", "human-readable approval statement" ], "serial": true, "identity_strategy": "Authoritative approval identifier issued by the governing quality or records master system; otherwise a governed IRI; otherwise a UUID or ULID assigned by the adopting Dimension. Serial members are numbered within the scope of one record identifier.", "source_refs": [ "SRC-026", "SRC-030" ] } ], "inline_only_rationale": null }, { "id": "tst-gov-f-revision-supersession", "name": "Revision identity, correction and supersession", "description": "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.", "source_refs": [ "SRC-001", "SRC-029", "SRC-026" ], "questions": [ { "id": "tst-gov-q-revision-identity", "text": "How is a revision of a test case identified, and what change makes it a new test case instead?", "kind": "identity", "answer_data": [ "Stable record identifier and separate revision identifier", "Criteria that force a new record identity, such as a changed test objective or test object class", "Rule that a date alone never serves as a revision identifier" ] }, { "id": "tst-gov-q-correction-method", "text": "Under what rule is an approved or finalised record corrected, by edit or by superseding revision?", "kind": "process", "answer_data": [ "States in which in-place edit remains permitted", "States in which correction requires a superseding revision", "Required correction reason code and narrative" ] }, { "id": "tst-gov-q-revision-validity-window", "text": "Which timestamps establish the validity window of a revision that has been superseded?", "kind": "temporal", "answer_data": [ "Revision valid-from timestamp", "Revision valid-until or superseded-at timestamp", "Whether the window is closed at supersession time or at the successor's effective time" ] }, { "id": "tst-gov-q-orphaned-result-links", "text": "What happens to test results that reference a test case revision after that revision is superseded?", "kind": "relationship", "answer_data": [ "Retained pointer to the exact executed revision", "Staleness or drift flag on the result's definition link", "Rule forbidding silent repointing of a historical result to a newer revision" ] } ], "data_elements": [ { "id": "tst-gov-de-record-identifier", "name": "Stable record identifier", "description": "Identifier that persists across all revisions of one test case or result record.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-revision-identifier", "name": "Revision identifier", "description": "Identifier distinguishing one revision of a record from another; never a bare date.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-supersedes-ref", "name": "Supersedes reference", "description": "Reference from a revision to the revision it replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-029" ] }, { "id": "tst-gov-de-superseded-by-ref", "name": "Superseded-by reference", "description": "Reference from a superseded revision to its replacement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-029" ] }, { "id": "tst-gov-de-revision-valid-window", "name": "Revision validity window", "description": "Valid-from and valid-until moments bounding the period in which a revision was the effective definition.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-correction-reason", "name": "Correction reason", "description": "Coded and narrative justification for a superseding correction.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Revision, supersession and validity-window facts are structural attributes and links carried on the record itself; every projection of the record already exposes them. Emitting a separate supersession artifact would introduce a parallel history that could disagree with the record's own links, and would create a second object needing its own retention and access treatment for no added evidentiary value." } ] } ] }, { "id": "tst-gov-b-assurance-evidence", "name": "Provenance, evidence integrity and assurance claims", "description": "How a result's origin and producing tools are recorded, how evidence artifacts are bound and proven unaltered, and how coverage, traceability and confidence claims are stated with their limits explicit.", "rationale": "An agent can only rely on a test result if it can recover who or what produced it, under which plan and in which environment, and can verify that the cited evidence is the evidence originally produced. PROV-O supplies the agent, activity, plan and qualified-role vocabulary; SLSA Provenance supplies the builder, external parameters, resolved dependencies and start and finish metadata pattern, together with explicit statements of what provenance does not attest; the in-toto Statement layer matches subject artifacts purely by digest and treats them as immutable; NIST SSDF names protection from tampering and provenance-data collection as practices. ISO/IEC/IEEE 29119-4 makes coverage technique-relative, which forbids reporting a bare coverage percentage as an adequacy claim.", "source_refs": [ "SRC-002", "SRC-025", "SRC-030", "SRC-031", "SRC-032" ], "layers": [ { "id": "tst-gov-l-provenance-integrity", "name": "Execution provenance and evidence integrity", "description": "Origin, agency and tool trust for a result, and the digest, attestation and immutability rules that keep its evidence verifiable.", "source_refs": [ "SRC-025", "SRC-030", "SRC-031", "SRC-032" ], "findings": [ { "id": "tst-gov-f-execution-provenance", "name": "Execution provenance and source or tool trust", "description": "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.", "source_refs": [ "SRC-025", "SRC-031", "SRC-032", "SRC-024" ], "questions": [ { "id": "tst-gov-q-producing-agent", "text": "Which agent, acting under which plan and activity, produced this test result?", "kind": "provenance", "answer_data": [ "Executing agent reference, human or software, with its qualified role", "Plan or test procedure revision reference the agent followed", "Activity or execution-run identifier that generated the result" ] }, { "id": "tst-gov-q-time-separation", "text": "How are execution event time, observation time and ingestion time recorded separately for one run?", "kind": "temporal", "answer_data": [ "Execution started and finished moments", "Observation or measurement moment where it differs from execution", "Ingestion moment at which the record entered this model's custody" ] }, { "id": "tst-gov-q-tool-trust", "text": "How is the tool, harness or generator that produced the result identified and trust-assessed?", "kind": "quality", "answer_data": [ "Producing tool or platform identifier and version", "Trust or qualification level and the basis for it", "Whether the tool self-reports its own verdict without independent observation" ] }, { "id": "tst-gov-q-environment-facts", "text": "Which environment and resolved dependency facts form part of the execution record?", "kind": "composition", "answer_data": [ "Test environment descriptor reference", "Resolved dependency set with identifiers and digests", "External parameters supplied to the run, distinguished from platform-internal parameters" ] }, { "id": "tst-gov-q-provenance-limits", "text": "What does this provenance record explicitly not attest about the run?", "kind": "constraint", "answer_data": [ "Facts implicit in the platform identity rather than captured directly", "Unobserved side effects and out-of-band operator actions", "Statement that provenance establishes origin, not correctness of the verdict" ] } ], "data_elements": [ { "id": "tst-gov-de-execution-agent-ref", "name": "Executing agent reference", "description": "Reference to the human or software agent responsible for the execution, with its qualified role.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-producing-tool-id", "name": "Producing tool or platform identifier", "description": "Identifier and version of the tool, harness or platform that generated the result.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-031" ] }, { "id": "tst-gov-de-tool-trust-level", "name": "Tool trust or qualification level", "description": "Graded assessment of how far the producing tool's output may be relied on without corroboration.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-032", "SRC-033" ] }, { "id": "tst-gov-de-execution-event-time", "name": "Execution event time", "description": "Moment at which the execution actually started and finished in the test environment.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-031", "SRC-025" ] }, { "id": "tst-gov-de-ingestion-time", "name": "Ingestion time", "description": "Moment at which the result record entered this model's custody, recorded independently of event time.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-environment-descriptor", "name": "Environment and dependency descriptor", "description": "Environment reference with resolved dependencies and the external parameters supplied to the run.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-031", "SRC-024" ] } ], "artifacts": [ { "id": "tst-gov-art-execution-provenance-record", "name": "Execution provenance record", "description": "Structured origin record for one execution: agent, qualified role, plan, activity, producing platform, resolved dependencies, external parameters, start and finish moments, ingestion moment, and an explicit statement of what is not attested.", "media_or_form": [ "structured provenance assertion", "graph-serialisable statement set", "human-readable provenance summary" ], "serial": true, "identity_strategy": "Authoritative execution-run identifier issued by the executing platform's master system; otherwise a governed IRI in the Dimension namespace; otherwise a UUID or ULID assigned by the adopting Dimension. Serial members are ordered by execution event time, never by ingestion time.", "source_refs": [ "SRC-025", "SRC-031" ] } ], "inline_only_rationale": null }, { "id": "tst-gov-f-evidence-integrity", "name": "Evidence binding, integrity and immutability", "description": "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.", "source_refs": [ "SRC-030", "SRC-032", "SRC-026", "SRC-031" ], "questions": [ { "id": "tst-gov-q-evidence-binding", "text": "What digest and algorithm bind an evidence artifact to the result record that cites it?", "kind": "security", "answer_data": [ "Digest value and named digest algorithm", "Artifact name or locator, held as a convenience rather than as the identity", "Rule that matching is by digest regardless of content type or filename" ] }, { "id": "tst-gov-q-integrity-verification", "text": "How is an evidence artifact shown to be unaltered after ingestion?", "kind": "validation", "answer_data": [ "Verification method and the attestation or signature checked", "Moment of the most recent verification", "Verifying party or service reference" ] }, { "id": "tst-gov-q-evidence-immutability", "text": "At what point does evidence become immutable, and what may still change afterwards?", "kind": "constraint", "answer_data": [ "State at which the evidence set is frozen", "Mutable governance metadata that remains editable, such as sensitivity label or hold status", "Rule that a content change after freezing produces a new artifact, not an edited one" ] }, { "id": "tst-gov-q-integrity-failure", "text": "How is a failed or unverifiable integrity check represented rather than discarded?", "kind": "exception", "answer_data": [ "Integrity status code such as verified, unverifiable, mismatched or missing", "Effect on the citing result's confidence grade", "Escalation reference raised for the discrepancy" ] } ], "data_elements": [ { "id": "tst-gov-de-evidence-digest", "name": "Evidence artifact digest", "description": "Content digest that identifies and binds an evidence artifact to the citing result.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-030" ] }, { "id": "tst-gov-de-digest-algorithm", "name": "Digest algorithm", "description": "Named algorithm used to compute the evidence digest.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-030" ] }, { "id": "tst-gov-de-attestation-ref", "name": "Attestation reference", "description": "Reference to a signed statement whose subject digest matches the evidence artifact.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-030", "SRC-031" ] }, { "id": "tst-gov-de-integrity-status", "name": "Integrity verification status", "description": "Outcome of the most recent integrity check, including unverifiable and mismatched outcomes.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-032", "SRC-026" ] }, { "id": "tst-gov-de-integrity-checked-at", "name": "Integrity verification time", "description": "Moment at which the recorded integrity status was determined.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "tst-gov-art-evidence-manifest", "name": "Evidence manifest", "description": "Enumeration of every evidence artifact cited by a result, each with its digest, algorithm, size class, sensitivity label, attestation references and last verification status. The manifest is the integrity boundary of the result: an artifact absent from it is not evidence for that result.", "media_or_form": [ "structured manifest record", "signed statement set", "human-readable evidence index" ], "serial": false, "identity_strategy": "Derived from the authoritative identifier of the result record it manifests, plus the manifest revision identifier; where the result has no master-system identifier, a governed IRI, and failing that a UUID or ULID assigned by the adopting Dimension.", "source_refs": [ "SRC-030", "SRC-032" ] } ], "inline_only_rationale": null } ] }, { "id": "tst-gov-l-assurance-claims", "name": "Validation, coverage and traceability claims", "description": "Rules that make a record acceptable, and the disciplined statement of coverage, trace and confidence claims with their scope and caveats attached.", "source_refs": [ "SRC-002", "SRC-024", "SRC-009", "SRC-033" ], "findings": [ { "id": "tst-gov-f-validation-confidence", "name": "Record validation and confidence grading", "description": "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.", "source_refs": [ "SRC-024", "SRC-026", "SRC-009" ], "questions": [ { "id": "tst-gov-q-acceptance-rules", "text": "Which mandatory fields and referential links must resolve before a result record is accepted?", "kind": "validation", "answer_data": [ "Mandatory field set for the record class", "Referential links that must resolve, such as executed definition revision and environment", "Behaviour on failure: rejection, quarantine or acceptance with a defect flag" ] }, { "id": "tst-gov-q-nonbinary-outcome", "text": "How is an inconclusive, blocked, aborted or errored execution outcome represented?", "kind": "exception", "answer_data": [ "Verdict vocabulary beyond pass and fail", "Distinction between a failed assertion and a failed execution", "Rule forbidding silent coercion of a non-binary outcome to pass or fail" ] }, { "id": "tst-gov-q-confidence-grade", "text": "What confidence grade is attached to a result, and on what basis is it assigned?", "kind": "quality", "answer_data": [ "Confidence grade code and its defined scale", "Basis factors: tool trust level, integrity status, independence, environment fidelity", "Party or function that assigned the grade and when" ] }, { "id": "tst-gov-q-flaky-marking", "text": "How is a known-unreliable or intermittently failing test flagged without deleting its records?", "kind": "measurement", "answer_data": [ "Reliability flag and the observation window supporting it", "Count of divergent outcomes over unchanged definition and environment", "Rule that flagged results remain retrievable and are excluded only with an explicit, stated exclusion" ] }, { "id": "tst-gov-q-defect-limits", "text": "What limit does this model state on what a passing result establishes?", "kind": "constraint", "answer_data": [ "Statement that a pass evidences the exercised conditions only", "Statement that absence of observed failure is not evidence of absence of defects", "Scope note naming the conditions, data and environment actually exercised" ] } ], "data_elements": [ { "id": "tst-gov-de-outcome-verdict", "name": "Outcome verdict", "description": "Coded verdict including pass, fail, inconclusive, blocked, error and not-run.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-record-validation-status", "name": "Record validation status", "description": "Whether the record satisfied the acceptance rules, and which rule failed if it did not.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-validation-rule-ref", "name": "Validation rule set reference", "description": "Reference to the rule set against which the record was validated, with its revision.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-confidence-grade", "name": "Confidence grade", "description": "Graded reliance the record supports, derived from tool trust, integrity status and independence.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-033", "SRC-009" ] }, { "id": "tst-gov-de-reliability-flag", "name": "Known-unreliable flag", "description": "Marker that the test has produced divergent outcomes under unchanged definition and environment.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-evidential-scope-note", "name": "Evidential scope note", "description": "Statement of the conditions actually exercised, bounding what the verdict evidences.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Acceptance status, verdict, confidence grade and reliability marking are attributes of the result record and of the referenced rule set; they have no existence apart from the record they qualify. Emitting a separate validation artifact would duplicate the record's own state and would need reconciliation whenever the rule set was revised, which is precisely the divergence the reconciliation function exists to prevent." }, { "id": "tst-gov-f-coverage-claim", "name": "Coverage measurement as a bounded claim", "description": "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.", "source_refs": [ "SRC-002", "SRC-009", "SRC-032" ], "questions": [ { "id": "tst-gov-q-coverage-item-basis", "text": "Which coverage item type, measurement method and denominator does this figure refer to?", "kind": "measurement", "answer_data": [ "Coverage item type such as requirement, branch, condition, state or equivalence partition", "Measurement method and the technique it derives from", "Numerator and denominator counts with their definitions" ] }, { "id": "tst-gov-q-coverage-scope-limits", "text": "Which scope boundaries and exclusions limit this coverage figure?", "kind": "constraint", "answer_data": [ "Test object scope actually measured", "Excluded units, paths or requirements with the reason for exclusion", "Whether excluded items are removed from the denominator or counted as uncovered" ] }, { "id": "tst-gov-q-coverage-aggregation", "text": "Which executions and definition revisions were aggregated to produce the figure?", "kind": "composition", "answer_data": [ "Set of execution record references included", "Definition revisions in force for those executions", "Handling of repeated executions of the same item" ] }, { "id": "tst-gov-q-coverage-caveat", "text": "What caveat is carried so the figure is not read as proof of adequacy?", "kind": "quality", "answer_data": [ "Explicit statement that coverage measures exercised items, not adequacy or correctness", "Statement that unexercised behaviour is unmeasured rather than absent", "Named limitation of the measurement instrument itself" ] }, { "id": "tst-gov-q-coverage-gate-use", "text": "How is a coverage claim referenced by an external gate without this model owning that gate?", "kind": "interoperability", "answer_data": [ "Stable claim identifier and revision a gate can cite", "Claim validity window and the moment it was computed", "Statement that threshold definition and gate verdict belong to the referencing release model" ] } ], "data_elements": [ { "id": "tst-gov-de-coverage-item-type", "name": "Coverage item type", "description": "Coded type of item counted, such as requirement, branch, condition or partition.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-coverage-method", "name": "Coverage measurement method", "description": "Method and instrument used to determine which items were exercised.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-coverage-numerator", "name": "Covered item count", "description": "Number of coverage items observed as exercised within the declared scope.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-coverage-denominator", "name": "Total item count", "description": "Number of coverage items in the declared scope, after stated exclusions.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-coverage-exclusion", "name": "Coverage exclusion", "description": "Item or region excluded from measurement, with its reason and denominator treatment.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "tst-gov-de-coverage-caveat", "name": "Coverage caveat statement", "description": "Mandatory statement bounding the inference the figure supports.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-002" ] }, { "id": "tst-gov-de-coverage-computed-at", "name": "Coverage computation time", "description": "Moment at which the figure was computed, distinct from the execution event times aggregated.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "tst-gov-art-coverage-claim-statement", "name": "Coverage claim statement", "description": "Self-describing coverage claim carrying item type, method, numerator, denominator, exclusions, the aggregated execution references, the computation moment and the mandatory caveat. Citable by an external release gate, which supplies its own threshold and verdict.", "media_or_form": [ "structured claim record", "tabular coverage breakdown", "human-readable assurance statement" ], "serial": true, "identity_strategy": "Authoritative claim identifier from the quality master system where one exists; otherwise a governed IRI in the Dimension namespace; otherwise a UUID or ULID assigned by the adopting Dimension. Serial members are numbered per scope and revision, never by computation date.", "source_refs": [ "SRC-002", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "tst-gov-f-traceability-assertions", "name": "Requirement, risk and control trace assertions", "description": "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.", "source_refs": [ "SRC-024", "SRC-001", "SRC-028" ], "questions": [ { "id": "tst-gov-q-trace-target", "text": "Which requirement, risk or control does this test case assert that it exercises?", "kind": "relationship", "answer_data": [ "Target reference and target model identity", "Link type such as validates, verifies, mitigates or evidences", "Whether the assertion covers the target wholly or partially" ] }, { "id": "tst-gov-q-trace-assertion-origin", "text": "Who asserted this trace link, and when was it last reconfirmed?", "kind": "provenance", "answer_data": [ "Asserting party or tool reference", "Assertion moment and last reconfirmation moment", "Method: manual assertion, derived from identifiers, or inferred by a tool" ] }, { "id": "tst-gov-q-trace-staleness", "text": "What happens to the trace link when the referenced target revision changes?", "kind": "state", "answer_data": [ "Pinned target revision at assertion time", "Staleness or drift flag raised on target revision change", "Reconfirmation obligation and the role that discharges it" ] }, { "id": "tst-gov-q-trace-resolution", "text": "How is a trace link expressed so an external tool can resolve it without local knowledge?", "kind": "interoperability", "answer_data": [ "Resolvable target reference form", "Alignment to an external quality-management link property", "Fallback when the target system is unreachable" ] } ], "data_elements": [ { "id": "tst-gov-de-trace-target-ref", "name": "Trace target reference", "description": "Resolvable reference to the requirement, risk or control asserted to be exercised.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-trace-link-type", "name": "Trace link type", "description": "Coded nature of the assertion, such as validates, verifies, mitigates or evidences.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-trace-pinned-revision", "name": "Pinned target revision", "description": "Revision of the target that was in force when the assertion was made.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "tst-gov-de-trace-asserted-by", "name": "Trace asserting party", "description": "Party or tool that made the trace assertion.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-trace-confirmed-at", "name": "Trace reconfirmation time", "description": "Moment at which the assertion was last actively reconfirmed against the target.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-025" ] }, { "id": "tst-gov-de-trace-staleness-flag", "name": "Trace staleness flag", "description": "Marker that the referenced target has changed since the assertion was pinned.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024" ] } ], "artifacts": [], "inline_only_rationale": "Trace assertions are directed reference data whose targets are mastered by requirement, risk and control models. Producing a local traceability matrix artifact would materialise a snapshot that begins diverging from both endpoints immediately and would tempt consumers to treat the copy as authoritative; the reconciliation function instead recomputes trace state on demand from the live references and their pinned revisions." } ] } ] }, { "id": "tst-gov-b-information-governance", "name": "Sensitivity, retention and controlled disclosure", "description": "Classification and protection of test records that may carry personal or production data, the retention, hold and disposition regime for this model's own records, and the redaction, export and interoperability rules governing their release.", "rationale": "Test inputs, logs and attachments routinely absorb production and personal data, which brings the records under purpose limitation, minimisation, storage limitation and by-design obligations, and requires pseudonymisation or encryption where appropriate. Records-management practice separates capture, maintenance and use, and disposal, and separates the disposition authority from the act of destruction. Regulated sectors impose their own retention floors, such as ten-year technical documentation retention and minimum log-retention periods for high-risk AI systems. 21 CFR Part 11 requires that copies released from the system be accurate and complete in both human-readable and electronic form, which constrains how redacted exports may be described.", "source_refs": [ "SRC-026", "SRC-027", "SRC-028", "SRC-029" ], "layers": [ { "id": "tst-gov-l-sensitivity-retention", "name": "Sensitivity, personal data and retention", "description": "Classification at record, field and artifact level, treatment of personal or production-derived data, and the retention, hold and disposition regime.", "source_refs": [ "SRC-027", "SRC-028", "SRC-029", "SRC-026" ], "findings": [ { "id": "tst-gov-f-sensitivity-personal-data", "name": "Sensitivity classification and personal or production data", "description": "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.", "source_refs": [ "SRC-027", "SRC-026", "SRC-028" ], "questions": [ { "id": "tst-gov-q-sensitivity-label", "text": "What sensitivity label applies to this record, and does it differ for individual fields or artifacts?", "kind": "classification", "answer_data": [ "Record-level sensitivity label", "Field-level and artifact-level overrides with their scope", "Label vocabulary reference and the authority that maintains it" ] }, { "id": "tst-gov-q-personal-data-presence", "text": "Do the test inputs, logs or attachments contain personal or production-derived data?", "kind": "privacy", "answer_data": [ "Personal data present indicator and the categories involved", "Data origin class: synthetic, masked, production-derived or production copy", "Lawful basis or authorisation reference held in the privacy model" ] }, { "id": "tst-gov-q-minimisation-measure", "text": "Which minimisation or pseudonymisation measure was applied before the data entered the record?", "kind": "security", "answer_data": [ "Measure applied, such as pseudonymisation, masking, subsetting or encryption", "Party or process that applied it and when", "Residual re-identification risk noted by the applying party" ] }, { "id": "tst-gov-q-field-masking", "text": "Which fields must be masked for a reader holding only baseline access?", "kind": "access", "answer_data": [ "Field list requiring masking at baseline access", "Masking behaviour: withheld, redacted or tokenised", "Elevated scope required to see the unmasked value" ] } ], "data_elements": [ { "id": "tst-gov-de-record-sensitivity-label", "name": "Record sensitivity label", "description": "Coded sensitivity classification applying to the record as a whole.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-field-sensitivity-override", "name": "Field or artifact sensitivity override", "description": "More restrictive label bound to a named field or evidence artifact.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-027" ] }, { "id": "tst-gov-de-personal-data-present", "name": "Personal data present indicator", "description": "Declared presence of personal data anywhere in the record or its cited evidence.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-027" ] }, { "id": "tst-gov-de-data-origin-class", "name": "Test data origin class", "description": "Whether the data is synthetic, masked, production-derived or an unmodified production copy.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-027" ] }, { "id": "tst-gov-de-minimisation-measure", "name": "Minimisation or pseudonymisation measure", "description": "Measure applied to reduce identifiability before the data entered the test record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-027" ] } ], "artifacts": [ { "id": "tst-gov-art-sensitivity-profile", "name": "Sensitivity and masking profile", "description": "Profile binding a record class to its default sensitivity label, the field and artifact overrides that apply, the masking behaviour per access scope, and the declared handling for production-derived and personal data.", "media_or_form": [ "structured classification profile", "field-by-scope masking table", "human-readable handling instruction" ], "serial": false, "identity_strategy": "Authoritative identifier of the information-classification policy record in the adopting Dimension's governance master system; otherwise a governed IRI; otherwise a UUID or ULID assigned by the adopting Dimension, with a revision identifier per published state.", "source_refs": [ "SRC-027", "SRC-026" ] } ], "inline_only_rationale": null }, { "id": "tst-gov-f-retention-disposition", "name": "Retention, legal hold and disposition", "description": "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.", "source_refs": [ "SRC-029", "SRC-027", "SRC-028", "SRC-026" ], "questions": [ { "id": "tst-gov-q-retention-binding", "text": "Which retention rule and disposition authority governs this record class?", "kind": "retention", "answer_data": [ "Retention rule reference and the schedule that contains it", "Disposition authority reference and the body that issued it", "Sector or jurisdiction profile that raises the retention floor" ] }, { "id": "tst-gov-q-retention-clock", "text": "When does the retention clock start for the result, and when for its evidence artifacts?", "kind": "temporal", "answer_data": [ "Retention trigger event code per record class", "Trigger occurrence moment", "Computed disposition-due moment, and whether result and artifact clocks differ" ] }, { "id": "tst-gov-q-legal-hold", "text": "Which legal hold suspends disposition, and who may place or release it?", "kind": "authority", "answer_data": [ "Hold reference, scope and issuing authority", "Roles permitted to place and to release the hold", "Effect on already-scheduled disposition actions" ] }, { "id": "tst-gov-q-disposition-outcome", "text": "What remains after disposition: full erasure, redacted stub or tombstone?", "kind": "decision", "answer_data": [ "Disposition outcome code", "Metadata retained in a tombstone and the reason each element is retained", "Confirmation reference from the executing records system" ] } ], "data_elements": [ { "id": "tst-gov-de-retention-rule-ref", "name": "Retention rule reference", "description": "Reference to the governing retention rule in the records-management model.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-029" ] }, { "id": "tst-gov-de-retention-trigger-event", "name": "Retention trigger event", "description": "Event whose occurrence starts the retention period for this record class.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-029" ] }, { "id": "tst-gov-de-disposition-due-at", "name": "Disposition due moment", "description": "Computed moment at which disposition becomes due, absent a hold.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-029", "SRC-028" ] }, { "id": "tst-gov-de-legal-hold-ref", "name": "Legal hold reference", "description": "Reference to an active hold that suspends disposition for this record.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-029" ] }, { "id": "tst-gov-de-tombstone-marker", "name": "Tombstone marker", "description": "Structure retained after disposition carrying the identifier, disposition outcome, authority and confirmation reference.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-029", "SRC-026" ] } ], "artifacts": [], "inline_only_rationale": "Retention schedules, disposition authorities and destruction confirmations are mastered by the records-management model and the adopting Dimension; this model holds only the binding, the clock trigger, the hold state and the tombstone marker as attributes on its own records. Generating a local retention artifact would create an unauthorised second schedule that could outlive or contradict the governing one." } ] }, { "id": "tst-gov-l-disclosure-interoperability", "name": "Export, redaction and standards alignment", "description": "Controlled release of test records beyond their home boundary, and the disciplined mapping of this model onto external standards without unearned conformance claims.", "source_refs": [ "SRC-024", "SRC-001", "SRC-026", "SRC-030" ], "findings": [ { "id": "tst-gov-f-export-redaction", "name": "Export packaging and redaction", "description": "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.", "source_refs": [ "SRC-026", "SRC-030", "SRC-027", "SRC-024" ], "questions": [ { "id": "tst-gov-q-redaction-profile", "text": "Which redaction profile applies when a test record leaves its home boundary?", "kind": "access", "answer_data": [ "Redaction profile reference and the recipient class it serves", "Fields and artifacts withheld, masked or tokenised under that profile", "Sensitivity labels that force withholding regardless of recipient" ] }, { "id": "tst-gov-q-export-integrity", "text": "How is integrity re-established for an export whose content has been redacted?", "kind": "security", "answer_data": [ "Digests of the redacted artifacts as issued", "Reference from each redacted artifact to the original digest it derives from", "Signature or attestation over the export manifest and its signer" ] }, { "id": "tst-gov-q-export-disclosure", "text": "What does the export manifest tell the recipient about what was withheld?", "kind": "evidence", "answer_data": [ "Count and class of withheld elements", "Statement that the package is a redacted derivation, not a complete copy", "Contact or process for requesting the unredacted record" ] }, { "id": "tst-gov-q-export-authorisation", "text": "Which approval is required before an export crosses an organisational or jurisdictional boundary?", "kind": "authority", "answer_data": [ "Approving role and party reference", "Destination boundary and any transfer condition attached", "Approval moment and validity window of the authorisation" ] } ], "data_elements": [ { "id": "tst-gov-de-export-package-id", "name": "Export package identifier", "description": "Identifier of one released package, stable for recipient reference and recall.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-redaction-profile-ref", "name": "Redaction profile reference", "description": "Reference to the profile determining what is withheld, masked or tokenised.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-027" ] }, { "id": "tst-gov-de-withheld-element-summary", "name": "Withheld element summary", "description": "Counts and classes of elements withheld, disclosed to the recipient without revealing content.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-export-approver-ref", "name": "Export approver reference", "description": "Party who authorised the release across the stated boundary.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-026" ] }, { "id": "tst-gov-de-export-generated-at", "name": "Export generation moment", "description": "Moment at which the export package was produced, distinct from the event times of its content.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-025" ] } ], "artifacts": [ { "id": "tst-gov-art-export-package-manifest", "name": "Export package manifest", "description": "Manifest for one released package listing included records, redacted artifact digests with their derivation from original digests, withheld element counts and classes, applied profile, approver, generation moment and an explicit statement that the package is a redacted derivation rather than a complete copy.", "media_or_form": [ "structured manifest record", "signed statement over the package", "human-readable disclosure cover note" ], "serial": true, "identity_strategy": "Authoritative export identifier issued by the releasing system of record; otherwise a governed IRI in the Dimension namespace; otherwise a UUID or ULID assigned by the adopting Dimension. Serial members are numbered per requesting recipient and boundary, not by generation date.", "source_refs": [ "SRC-026", "SRC-030" ] } ], "inline_only_rationale": null }, { "id": "tst-gov-f-alignment-conformance", "name": "Standards alignment, conformance limits and regional variation", "description": "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.", "source_refs": [ "SRC-024", "SRC-001", "SRC-028", "SRC-030", "SRC-031" ], "questions": [ { "id": "tst-gov-q-alignment-target", "text": "Which external standard, schema or vocabulary does a given field set claim to align with?", "kind": "interoperability", "answer_data": [ "Alignment target identifier with its version or edition", "Field or relationship subset covered by the mapping", "Direction of the mapping and any lossy elements" ] }, { "id": "tst-gov-q-conformance-evidence", "text": "What evidence would be required before a conformance claim to that standard could be made?", "kind": "evidence", "answer_data": [ "Conformance requirements the standard states", "Test or assessment evidence that would demonstrate them", "Current claim status, defaulting to aligned-not-conformant" ] }, { "id": "tst-gov-q-alignment-conflict", "text": "Where do two aligned standards conflict, and how is that conflict held open?", "kind": "decision", "answer_data": [ "Conflicting element pair and the nature of the disagreement", "Mapping status code such as partial, conflict or hold", "Reason the conflict is not resolved locally and who would resolve it" ] }, { "id": "tst-gov-q-regional-profile", "text": "Which regional or sector-specific rule changes the governance obligations for these records?", "kind": "requirement", "answer_data": [ "Jurisdiction or sector profile identifier", "Obligation altered, such as a retention floor or a log-keeping minimum", "Precedence rule when a profile is stricter than the organisational default" ] }, { "id": "tst-gov-q-tool-format-binding", "text": "How is a tool-specific report format bound without becoming this model's semantics?", "kind": "definition", "answer_data": [ "Source format identifier and version", "Mapping from format fields to this model's data elements", "Elements the format cannot express, recorded as import gaps" ] } ], "data_elements": [ { "id": "tst-gov-de-alignment-target", "name": "Alignment target reference", "description": "Reference to an external standard, schema or vocabulary with which a field set aligns.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024", "SRC-001" ] }, { "id": "tst-gov-de-alignment-status", "name": "Alignment mapping status", "description": "Status of one mapping: aligned, partial, conflict or publication hold.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-024" ] }, { "id": "tst-gov-de-conformance-claim-flag", "name": "Conformance claim indicator", "description": "Whether a conformance claim is asserted, defaulting to false where evidence is absent.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "tst-gov-de-conformance-evidence-ref", "name": "Conformance evidence reference", "description": "Reference to assessment evidence supporting any asserted conformance claim.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "tst-gov-de-jurisdiction-profile", "name": "Jurisdiction or sector profile", "description": "Profile that alters governance obligations such as retention floors or log-keeping minima.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-028", "SRC-027" ] } ], "artifacts": [ { "id": "tst-gov-art-alignment-map", "name": "Standards alignment map", "description": "Element-by-element mapping between this model's governance data elements and external standards and schemas, with per-element status, lossy-mapping notes, recorded conflicts held as publication holds, and the evidence that would be required for any conformance claim.", "media_or_form": [ "structured mapping table", "crosswalk record set", "human-readable alignment note" ], "serial": false, "identity_strategy": "Authoritative identifier of the interoperability mapping record in the adopting Dimension's governance master system; otherwise a governed IRI; otherwise a UUID or ULID assigned by the adopting Dimension, with a revision identifier per published state and a per-row target version pin.", "source_refs": [ "SRC-024", "SRC-001", "SRC-030" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "tst-design-function-define-test-case", "name": "Define a reusable test case", "description": "Author a new test case definition from a stated objective and test basis references, capturing preconditions, fixture and data references, parameters, ordered actions, expected outcomes with a comparison rule, postconditions, applicability and ownership.", "inputs": [ "Objective statement and title", "Test item reference", "Test basis references covering requirement, acceptance criterion, risk and assertion", "Preconditions and fixture or data-set references", "Parameter declarations and value constraints", "Ordered actions and per-step expectations", "Expected outcomes, comparison rule and tolerances", "Postconditions and side-effect limits", "Applicability attributes, tags and ownership" ], "outputs": [ "Draft test case definition revision", "Assigned authoritative identifier or identifier request", "Recorded authorship with event time and observation time" ], "preconditions": [ "The test item reference resolves", "Declared test basis references resolve in their owning models", "The requesting actor holds an authoring role in the owning package" ], "effects": [ "Creates a draft definition revision in the register with event time and recording time", "Registers typed references to external models without copying their content", "Creates no execution record and adjudicates no result" ], "source_refs": [ "SRC-005", "SRC-002", "SRC-001" ] }, { "id": "tst-design-function-version-test-case", "name": "Version and freeze a test case revision", "description": "Create the next revision of a definition when a semantic change occurs, freeze the superseded revision, and publish the canonical snapshot and digest that executions and evidence will cite.", "inputs": [ "Existing revision reference", "Proposed field-scoped changes", "Change reason code", "Materiality classification" ], "outputs": [ "New revision identifier", "Canonical snapshot with content digest", "Supersession link to the prior revision" ], "preconditions": [ "The prior revision resolves", "The change is classified as semantic under the materiality rule", "Canonicalization rules are available for the target projection" ], "effects": [ "Freezes the superseded revision so past citations stay valid", "Publishes an immutable definition snapshot addressable by digest", "Leaves already-recorded executions pointing at the revision they actually used" ], "source_refs": [ "SRC-005", "SRC-001", "SRC-006" ] }, { "id": "tst-design-function-validate-definition", "name": "Validate a test case definition", "description": "Statically assess one definition revision for completeness, internal consistency and traceability sufficiency against a declared validation profile, and report findings to authors and reviewers.", "inputs": [ "Definition revision reference", "Validation profile naming required fields and rules", "Controlled vocabularies for classification and status" ], "outputs": [ "Validation finding list with severity", "Completeness flags per required field", "Ready-for-review determination" ], "preconditions": [ "The revision resolves", "The validation profile declares which fields are required in this Dimension", "Referenced vocabularies resolve" ], "effects": [ "Records static validation findings against the definition revision", "Blocks the readiness transition while a mandatory finding is open", "Does not exercise the test item and produces no test verdict" ], "source_refs": [ "SRC-005", "SRC-006", "SRC-001" ] }, { "id": "tst-design-function-select-test-cases", "name": "Select candidate test case revisions", "description": "Return the set of test case revisions matching a selection expression over declared tags, attributes, traceability links and applicability context at a stated point in time, with the reason each case was included or excluded.", "inputs": [ "Selection expression over tags, attributes and traceability", "Applicability context such as platform, configuration, locale and feature flags", "Point in time for time-bounded applicability", "Minimum readiness state" ], "outputs": [ "Candidate set of test case revisions", "Inclusion and exclusion reasons per case", "Unresolved attribute report" ], "preconditions": [ "Selectable attributes are populated on the candidate definitions", "Referenced vocabularies resolve", "The selection expression parses against the declared grammar" ], "effects": [ "Returns a candidate set as a read-only result", "Leaves sequencing into suites, scheduling and dispatch to the referenced suite, campaign and pipeline models", "Creates no execution record and changes no definition state" ], "source_refs": [ "SRC-011", "SRC-010", "SRC-005" ] }, { "id": "tst-design-function-resolve-executable-definition", "name": "Resolve a definition for execution", "description": "Bind one test case revision, one parameter set, the referenced fixture and data-set versions and the automation binding into a fully-resolved definition handle that the execution structures cite when they record what was run.", "inputs": [ "Test case revision reference", "Parameter set or variant key", "Fixture and data-set resolution context", "Automation binding context and framework identifier" ], "outputs": [ "Resolved definition handle carrying resolved parameters, data-set versions, implementation reference, comparison rule and tolerances", "Resolution report listing every reference that was resolved", "Unresolvable reference list where resolution failed" ], "preconditions": [ "The revision is in a readiness state permitted for execution", "All required bindings and data-set versions resolve", "Excluded parameter combinations are not requested" ], "effects": [ "Emits an immutable resolved-definition handle bound to the revision digest", "Hands that handle to the execution structures, which own running the test and recording and adjudicating its result", "Performs no execution itself and adjudicates no verdict itself" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-011" ] }, { "id": "tst-exec-fn-execute-attempt", "name": "Execute a bound test-case attempt", "description": "Run one attempt of an immutably bound test-case revision with declared parameter values in a referenced environment, emitting an observation stream and creating the attempt record.", "inputs": [ "Bound test-case revision reference with digest", "Parameter values, data-set references and seed", "Environment reference and executing actor or tool reference" ], "outputs": [ "Attempt record with its own identifier and ordinal", "Observation stream with per-step outcomes", "Observed invocation facts including command line and exit code" ], "preconditions": [ "The bound test-case revision resolves and is immutable", "An attempt ordinal is available in the retry group and no earlier attempt is reopened", "The environment and subject-under-test references resolve with a digest" ], "effects": [ "Creates a new attempt record with an RFC 3339 start time", "Appends observations without adjudicating a verdict", "Does not alter the referenced test-case definition, environment or build record" ], "source_refs": [ "SRC-017", "SRC-013", "SRC-021", "SRC-019" ] }, { "id": "tst-exec-fn-record-observation", "name": "Record an observation and its evidence", "description": "Append an observed outcome, per-step result, diagnostic message or evidence attachment to an open attempt, with its observation time and capturing agent.", "inputs": [ "Attempt reference", "Observed value, step outcome or attachment with role and media type", "Observation timestamp and capturing agent reference" ], "outputs": [ "Persisted observation record", "Attachment reference with durable location and media type", "Updated per-step outcome collection" ], "preconditions": [ "The attempt exists and has not been sealed", "The observation carries an RFC 3339 time with seconds and an explicit offset or Z", "Attachments carry a sensitivity classification before storage" ], "effects": [ "Appends to the attempt; never edits or removes an existing observation", "Records observation time separately from record ingestion time", "Leaves the verdict field untouched" ], "source_refs": [ "SRC-014", "SRC-016", "SRC-013", "SRC-018" ] }, { "id": "tst-exec-fn-compare-outcome", "name": "Compare observed outcome against expectation", "description": "Apply the declared comparator, normalisation and tolerance to an observation and its bound expectation, producing a comparison record and delta without asserting a verdict.", "inputs": [ "Observed actual value or capture reference", "Expected value or oracle reference from the bound revision", "Comparator identity and version, tolerance and masking rules" ], "outputs": [ "Comparison record with delta and applied tolerance", "Pointer identifying the affected location or region", "Unevaluable marker with reason where comparison could not complete" ], "preconditions": [ "Both the observation and the bound expectation resolve", "The comparator and its version are recorded", "Normalisation and masking rules are declared before comparison" ], "effects": [ "Creates a comparison artifact bound to the attempt", "Records an unevaluable outcome rather than defaulting to pass or fail", "Does not modify the expectation or the observation it compared" ], "source_refs": [ "SRC-015", "SRC-013", "SRC-014" ] }, { "id": "tst-exec-fn-adjudicate-verdict", "name": "Adjudicate a verdict over recorded observations", "description": "Assert a governed verdict for an execution, naming the assertor, the assertion mode and the observations relied upon, and rejecting prohibited verdict-and-evidence combinations.", "inputs": [ "Execution or attempt reference", "Observation and comparison references forming the basis", "Assertor reference, assertion mode and governed verdict code" ], "outputs": [ "Verdict record with assertor, mode and supporting basis", "Interpreted severity where the vocabulary distinguishes it", "Validation errors for prohibited combinations" ], "preconditions": [ "At least one evaluated expectation exists when the verdict is pass", "The verdict code belongs to the code-list version in force", "The assertor and mode are recorded, including for automated assertions" ], "effects": [ "Writes an adjudication distinct from the observations it cites", "Rejects a pass inferred solely from an absent defect or an empty failure list", "Does not evaluate or enforce any release gate or downstream policy" ], "source_refs": [ "SRC-014", "SRC-015", "SRC-012", "SRC-013" ] }, { "id": "tst-exec-fn-retry-attempt", "name": "Create a retry attempt", "description": "Open a new attempt under the same binding in response to a retry trigger, linking it to its predecessor and preserving all earlier attempt evidence unchanged.", "inputs": [ "Predecessor attempt reference and retry group key", "Retry trigger code and referenced retry policy", "Requesting actor reference where the retry is human-initiated" ], "outputs": [ "New attempt record with the next ordinal", "Predecessor linkage and retry group membership", "Unchanged predecessor attempt with its original evidence" ], "preconditions": [ "The binding is identical to the predecessor attempt's binding", "The retry policy reference resolves; this function does not evaluate the policy", "The predecessor attempt is finished and sealed" ], "effects": [ "Adds an attempt; never mutates, deletes or renumbers an earlier attempt", "Records the trigger and policy reference for later non-determinism analysis", "Leaves any existing verdict on earlier attempts intact" ], "source_refs": [ "SRC-023", "SRC-022", "SRC-021" ] }, { "id": "tst-exec-fn-classify-nondeterminism", "name": "Classify non-determinism across an attempt set", "description": "Adjudicate whether an attempt set with a proven-identical binding shows deterministic or flaky behaviour, record the instability measure and window, and state whether the classification affects the reported verdict.", "inputs": [ "Attempt set references within one retry group", "Binding-equality evidence such as matching definition and parameter digests", "Observation window and denominator definition" ], "outputs": [ "Determinism classification code with confidence", "Instability measure with its window and denominator", "Recorded decision on any verdict effect and the deciding role" ], "preconditions": [ "All attempts in the set share an identical, digest-verified binding", "At least two attempts with differing outcomes exist", "The classifying agent and the governing decision rule are recorded" ], "effects": [ "Writes a classification as a property of the attempt set", "Never rewrites an individual attempt's observations or verdict", "Records but does not enforce any quarantine or suppression decision" ], "source_refs": [ "SRC-023", "SRC-013", "SRC-015" ] }, { "id": "tst-exec-fn-supersede-result", "name": "Supersede an adjudicated result", "description": "Issue a superseding revision that corrects a previous adjudication, citing the superseded revision, the reason, the correcting actor and the effective time, while retaining the original.", "inputs": [ "Reference to the revision being superseded", "Correction reason code and justification", "Correcting actor reference and effective timestamp" ], "outputs": [ "New revision carrying supersedes linkage", "Superseded revision marked and retained as retrievable", "Reason and actor recorded on the new revision" ], "preconditions": [ "The underlying observations are unchanged; a changed observation requires a retry instead", "The correcting actor holds the adjudication role", "The retention rule for superseded revisions is known" ], "effects": [ "Adds a revision; never erases or edits the superseded record", "Preserves the original verdict and its basis for review", "Emits the actor, time and reason for the referenced audit-log model to record durably" ], "source_refs": [ "SRC-012", "SRC-017", "SRC-016" ] }, { "id": "tst-exec-fn-seal-evidence", "name": "Seal the evidence set", "description": "Close an attempt, compute named digests over every evidence artifact and the canonical result document, and assemble the evidence manifest optionally bound into a signed result attestation.", "inputs": [ "Attempt or execution reference with its attachments", "Digest algorithm selection", "Subject-under-test descriptor with digest and the configuration used" ], "outputs": [ "Evidence manifest listing every artifact with role, length and digest", "Signed result attestation reference where an attestation service is used", "Sealed-at timestamp on the attempt" ], "preconditions": [ "The attempt is finished and no further observations are pending", "Every artifact in scope is resolvable at its durable location", "The subject-under-test digest is available" ], "effects": [ "Makes subsequent mutation of the attempt detectable", "Records only attestation references and reported verification outcomes; signing, key custody and verification remain external", "Does not gate, approve or block any downstream release" ], "source_refs": [ "SRC-019", "SRC-013", "SRC-012" ] }, { "id": "tst-exec-fn-export-result", "name": "Export a result projection", "description": "Derive a non-authoritative interchange document for a consuming toolchain from the canonical record, applying the governed mapping table and recording the lossy mappings and schema version used.", "inputs": [ "Execution or run record set reference", "Target format name, schema version and mapping table reference", "Identifier carriage and redaction options" ], "outputs": [ "Projection document in the requested format", "Recorded mapping reference with lossy-field list", "Schema validation outcome for the emitted document" ], "preconditions": [ "The mapping table for the target format and version resolves", "Restricted attachments are excluded or redacted while retaining their digests", "The canonical record is complete enough to satisfy the target's required fields" ], "effects": [ "Creates a derived document that never becomes authoritative over the internal record", "Records information dropped by the projection so the loss is auditable", "Makes no change to the source execution records" ], "source_refs": [ "SRC-022", "SRC-018", "SRC-021", "SRC-012", "SRC-020" ] }, { "id": "tst-gov-fn-authorize-record-operation", "name": "Determine admissibility of a record operation", "description": "Determines whether a requested operation on a test case or test result record is admissible under this model's role assignments, separation-of-duties matrix and sensitivity profile, and records the determination with its basis. Authentication, external policy evaluation and enforcement at a runtime policy enforcement point are outside this model; the determination is a governance statement about the record operation, and the resulting audit entry is written to the adopting Dimension's audit model, which this model only references.", "inputs": [ "Requested operation and target record with revision", "Requesting party reference and held role assignments", "Separation-of-duties matrix revision and sensitivity profile revision" ], "outputs": [ "Admissibility determination with permit or refuse outcome", "Basis: the matched rule, role set and any waiver reference", "Reference to the audit entry written by the audit model" ], "preconditions": [ "Requesting party resolves in the adopting Dimension's party registry", "Target record revision exists and is not in a state that forbids the operation", "Applicable matrix and sensitivity profile revisions are effective at the request moment" ], "effects": [ "Determination recorded against the record operation with its rule basis", "Refused operations leave record content unchanged", "No enforcement is executed and no audit trail is stored by this model" ], "source_refs": [ "SRC-026", "SRC-033" ] }, { "id": "tst-gov-fn-capture-review-approval", "name": "Capture review and approval of a revision", "description": "Captures a review outcome or approval act against one specific record revision, recording the signer, the moment of signing and the declared meaning of the signing, bound to the digest of the revision so the act cannot be transferred to another revision. Advances the record state only when the required role set and independence conditions for the target transition are satisfied.", "inputs": [ "Target record revision identifier and content digest", "Signer party reference and declared meaning of the signing", "Target state and the transition's required role set" ], "outputs": [ "Immutable approval or review record", "Updated lifecycle state where the transition succeeded", "Refusal reason where the required roles or independence conditions were unmet" ], "preconditions": [ "Signer holds a role permitted for the transition and violates no prohibited role pair without a valid waiver", "Revision digest matches the content being approved", "Prior gated transitions for the target state are complete" ], "effects": [ "Approval record written once and never edited", "Lifecycle state advanced or left unchanged with a recorded refusal", "Later revisions do not inherit the approval" ], "source_refs": [ "SRC-026", "SRC-001", "SRC-033" ] }, { "id": "tst-gov-fn-supersede-revision", "name": "Correct a record by superseding revision", "description": "Produces a successor revision that supersedes an approved or finalised revision, closing the predecessor's validity window and recording the correction reason, rather than editing the predecessor in place. Preserves every existing result's pointer to the revision actually executed, so historical results remain interpretable.", "inputs": [ "Predecessor revision identifier", "Proposed successor content and correction reason", "Acting party reference and expected predecessor revision for concurrency checking" ], "outputs": [ "Successor revision with supersedes and superseded-by links", "Closed validity window on the predecessor", "Conflict outcome where the expected predecessor revision no longer matches" ], "preconditions": [ "Predecessor is in a state that forbids in-place edit", "Acting party is authorised for the supersession operation", "No unreleased legal hold prohibits the change" ], "effects": [ "Predecessor content preserved unchanged and marked superseded", "Successor requires its own approval before it becomes usable as evidence", "Existing result pointers to the predecessor are not repointed" ], "source_refs": [ "SRC-026", "SRC-029", "SRC-001" ] }, { "id": "tst-gov-fn-compute-assurance-summary", "name": "Compute a bounded assurance summary", "description": "Aggregates validated result records and coverage measurements into an assurance summary carrying the item type, method, numerator, denominator, exclusions, aggregated execution references, computation moment and mandatory caveats. The summary is a claim about exercised items and observed outcomes; it states no adequacy conclusion, defines no threshold and issues no gate verdict, which remain owned by the referencing build or release model.", "inputs": [ "Set of result record references within the declared scope", "Coverage item definition, measurement method and exclusion list", "Confidence grades and integrity statuses of the included records" ], "outputs": [ "Assurance summary with coverage claim and outcome distribution", "Enumerated exclusions and unverifiable records with their effect on the figures", "Mandatory caveat statement bounding the supported inference" ], "preconditions": [ "Every included record has a resolved validation status", "Coverage item type and denominator definition are declared before computation", "Records under legal hold or with failed integrity checks are flagged, not silently dropped" ], "effects": [ "Summary published as a citable claim with a stable identifier and revision", "Non-binary and unverifiable outcomes remain visible in the summary", "No release, gate or deployment decision is produced" ], "source_refs": [ "SRC-002", "SRC-009", "SRC-032" ] }, { "id": "tst-gov-fn-reconcile-result-to-definition", "name": "Reconcile results against definitions and trace targets", "description": "Recomputes referential state between result records, the definition revisions they executed and the requirement, risk or control targets they assert, flagging orphaned pointers, superseded definitions and stale trace assertions. Reports divergence; it does not repair references or alter target models.", "inputs": [ "Result record set and their executed definition revision pointers", "Trace assertions with pinned target revisions", "Current revisions reported by the referenced definition and target models" ], "outputs": [ "Reconciliation report of orphaned, superseded and stale references", "Staleness flags applied to affected trace assertions", "Escalation items for unresolvable references" ], "preconditions": [ "Referenced models are reachable or their unreachability is recordable", "Pinned target revisions were captured at assertion time", "Reconciliation scope and cut-off moment are declared" ], "effects": [ "Staleness and drift state updated on this model's own records", "No target model record is created, altered or repointed", "Unreachable references are reported rather than assumed valid" ], "source_refs": [ "SRC-024", "SRC-001", "SRC-029" ] }, { "id": "tst-gov-fn-verify-evidence-integrity", "name": "Verify evidence integrity", "description": "Recomputes digests for cited evidence artifacts, checks any attestations whose subject digest should match, and records the verification outcome and moment against the evidence manifest. Reports verified, unverifiable, mismatched or missing outcomes; it neither quarantines nor deletes artifacts, and it does not act as an enforcement point.", "inputs": [ "Evidence manifest revision with digests and algorithms", "Retrieved artifact content or its custodian's attestation", "Trusted signer or key references supplied by the adopting Dimension" ], "outputs": [ "Per-artifact integrity status with the verification moment", "Discrepancy report for mismatched or missing artifacts", "Effect note on the confidence grade of citing results" ], "preconditions": [ "Manifest declares a digest and named algorithm for each artifact", "Verifier can retrieve the artifact or a custodian attestation over it", "Signer trust references are resolvable" ], "effects": [ "Integrity status and verification moment recorded on the manifest", "Citing results are flagged where integrity could not be established", "No artifact is modified, moved or removed" ], "source_refs": [ "SRC-030", "SRC-031", "SRC-032" ] }, { "id": "tst-gov-fn-produce-redacted-export", "name": "Produce a redacted export package", "description": "Assembles a release package for a stated recipient class by applying a redaction profile, issuing new digests for redacted artifacts with derivation links to their originals, and producing a manifest that discloses the counts and classes of withheld elements. Requires a recorded export approval before a package crosses an organisational or jurisdictional boundary.", "inputs": [ "Record set selected for release and the recipient class", "Redaction profile revision and sensitivity labels in force", "Export approval reference and destination boundary" ], "outputs": [ "Export package with redacted artifacts and their new digests", "Export manifest disclosing withheld element counts and classes", "Signed statement over the manifest, where signing is available" ], "preconditions": [ "Export approval exists and is valid at the generation moment", "Every record in scope carries a resolved sensitivity label", "Records under a hold that forbids release are excluded and reported" ], "effects": [ "Package described as a redacted derivation, never as a complete copy", "Derivation links preserved from each redacted artifact to its original digest", "Original evidence artifacts remain unchanged in the home boundary" ], "source_refs": [ "SRC-026", "SRC-027", "SRC-030" ] }, { "id": "tst-gov-fn-evaluate-retention-disposition", "name": "Evaluate retention and propose disposition", "description": "Evaluates the bound retention rule against the recorded trigger event and hold state to determine whether disposition is due for a record and, separately, for its evidence artifacts, and emits a disposition proposal with its authority reference. Execution of destruction, sanitisation or archival transfer is performed by the records-management model and the adopting Dimension, not here.", "inputs": [ "Retention rule and disposition authority references", "Retention trigger occurrence moments for the record and its artifacts", "Active legal hold references and any jurisdiction or sector profile in force" ], "outputs": [ "Disposition due determination per record and per artifact", "Disposition proposal naming the outcome class and its authority", "Suspension notice where a hold is active" ], "preconditions": [ "A retention rule is bound to the record class", "Trigger occurrence is recorded with an explicit moment", "Applicable sector profile floors have been resolved" ], "effects": [ "Proposal emitted for execution by the owning records system", "No content is destroyed, sanitised or transferred by this function", "Active holds always suppress the proposal and are recorded as the reason" ], "source_refs": [ "SRC-029", "SRC-028", "SRC-027" ] }, { "id": "tst-gov-fn-tombstone-record", "name": "Create a tombstone for a disposed record", "description": "On confirmation from the executing records system that disposition has occurred, replaces the record with a tombstone carrying the stable identifier, disposition outcome, authority reference and confirmation reference, so that inbound references from results, assurance summaries and external gates resolve to an explicit disposed state rather than to a dangling pointer.", "inputs": [ "Stable record identifier and its disposition proposal", "Confirmation reference from the executing records system", "Metadata elements the retention rule permits to survive" ], "outputs": [ "Tombstone record with identifier, outcome, authority and confirmation reference", "Updated referential state for records and summaries that cited the disposed record", "Exception where confirmation is absent or contradicts the proposal" ], "preconditions": [ "Disposition has been executed and confirmed by the owning records system", "No legal hold is active at the moment of confirmation", "The surviving metadata set is authorised by the retention rule" ], "effects": [ "Inbound references resolve to an explicit disposed state", "Disposed content is not recoverable from this model", "Tombstones are themselves subject to a stated retention rule and are not created for records still under hold" ], "source_refs": [ "SRC-029", "SRC-026", "SRC-027" ] } ], "composition": [ { "target": "WM-ACT-038 (registered parent model)", "relation": "CHILD", "purpose": "Positions the test-evidence aggregate beneath its registered parent so generic activity framing is inherited rather than restated; this model contributes only test-specific definition, execution, evidence, assurance and governance semantics.", "required": true, "source_refs": [ "SRC-004", "SRC-001" ] }, { "target": "WM-SFT-008 Build / Release", "relation": "REFERENCE", "purpose": "Release assurance references test case revisions, executions and evidence held here. This model publishes stable, resolvable evidence references and carries no release identity, no release lifecycle, no release-gating decision and no release audit trail.", "required": false, "source_refs": [ "SRC-001", "SRC-009" ] }, { "target": "Requirement / acceptance criterion model", "relation": "REFERENCE", "purpose": "Carries typed traceability links and the prescription level of the normative statement behind an expected outcome, while requirement authoring, approval and change lifecycle remain with the target.", "required": true, "source_refs": [ "SRC-005", "SRC-006" ] }, { "target": "Risk register / risk item model", "relation": "REFERENCE", "purpose": "Carries risk references that justify technique choice and priority for a case; risk identification, assessment and treatment lifecycle remain with the target.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Test suite / test set and test campaign model", "relation": "REFERENCE", "purpose": "Supplies selectable definitions and evidence to suites and campaigns; membership, ordering, scheduling, resourcing and exit criteria remain with the target.", "required": false, "source_refs": [ "SRC-001", "SRC-011" ] }, { "target": "Test environment / configuration model", "relation": "REFERENCE", "purpose": "Execution records cite an environment reference so results stay interpretable; provisioning, configuration baselining and infrastructure state remain with the target.", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "Defect / incident model", "relation": "REFERENCE", "purpose": "A failing result may cite a defect reference; defect triage, assignment, resolution and closure remain with the target and never become result state here.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "Test data management model", "relation": "REFERENCE", "purpose": "Names data-set identifiers, versions and sensitivity classification required by a case; data generation, masking, stewardship and erasure execution remain with the target.", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "target": "ISO/IEC/IEEE 29119-3 test documentation templates", "relation": "ALIGN", "purpose": "Aligns field naming and document boundaries with an international test documentation standard without claiming conformance; recorded as an alignment because clause-level template content was not verified in this research.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "W3C Test Metadata", "relation": "ALIGN", "purpose": "Aligns identity, title, purpose, status, specification reference, preconditions, inputs, expected results, version, contributor, rights and grouping to a published metadata vocabulary for tests.", "required": false, "source_refs": [ "SRC-005" ] }, { "target": "OASIS Test Assertions Model Version 1.0", "relation": "ALIGN", "purpose": "Aligns normative source, prerequisite, predicate, prescription level, variable and tag to the traceability, precondition, oracle and parameter structures here, and adopts its many-to-many relation between normative statements and test cases.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "ISO/IEC/IEEE 29119-5 keyword-driven testing data exchange", "relation": "ALIGN", "purpose": "Aligns keyword decomposition and the interchange of test cases, test data and results with a standardised exchange format so definitions remain portable between frameworks.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "WM-ACT-038", "relation": "CHILD", "purpose": "Registered parent of WM-SFT-015. A test execution is an instance of a performed activity; this model specialises that activity for test execution and result recording and inherits the parent's generic activity identity and time framing rather than restating it.", "required": true, "source_refs": [ "SRC-017" ] }, { "target": "WM-SFT-008 Build / Release", "relation": "REFERENCE", "purpose": "Carries the digest-identified subject under test and an optional back-reference to the consuming build or release. Per the declared relation the build references this evidence for release assurance; release states, promotion, approvals and gate evaluation stay entirely with WM-SFT-008.", "required": false, "source_refs": [ "SRC-019", "SRC-012" ] }, { "target": "Test environment / configuration-item model (registry identifier not yet assigned)", "relation": "REFERENCE", "purpose": "Supplies the environment or configuration item in which an execution ran, so results are interpretable and comparable. Provisioning, drift and decommissioning lifecycles remain in the target; only the reference plus observed runtime facts are carried here.", "required": true, "source_refs": [ "SRC-013", "SRC-017" ] }, { "target": "Defect / issue report model (registry identifier not yet assigned)", "relation": "REFERENCE", "purpose": "Provides defect and issue records that an execution raised, reproduced or verified. This model records the reference, its role and its assertion time; triage, severity, state and closure belong to the target and are never mirrored here.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "Actor, identity and access model (registry identifier not yet assigned)", "relation": "REFERENCE", "purpose": "Resolves the executing agent and the verdict assertor. Principal registration, credential lifecycle and entitlement evaluation stay in the target; this model stores only the reference and the assertion mode.", "required": true, "source_refs": [ "SRC-014", "SRC-013" ] }, { "target": "Audit log / event log model (registry identifier not yet assigned)", "relation": "REFERENCE", "purpose": "Receives actor, timestamp and reason for adjudications, supersessions and dispositions so they are durably recorded. Referencing an audit record grants this model no audit-trail semantics: ordering guarantees, tamper evidence and audit retention are the target's.", "required": false, "source_refs": [ "SRC-017" ] }, { "target": "OASIS SARIF Version 2.1.0 (Errata 01)", "relation": "ALIGN", "purpose": "Alignment for run, invocation, result kind and level, artifact hashes, attachments, baseline state and correlation identifiers. Alignment only: conformance is not claimed, and SARIF's severity levels are mapped rather than adopted as this model's verdict vocabulary.", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "target": "W3C EARL 1.0 Schema and ACT Rules Format 1.1", "relation": "ALIGN", "purpose": "Alignment for the assertion structure (assertor, subject, criterion, mode) and the outcome vocabulary including cantTell, inapplicable and untested, which supply the observation/adjudication separation and the inconclusive semantics used here.", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "target": "in-toto Attestation Framework test-result predicate v0.1", "relation": "ALIGN", "purpose": "Alignment for binding a result to a digest-identified subject with the configuration used, and for expressing evidence integrity. Signing, key custody, trust policy and verification remain outside this model's boundary.", "required": false, "source_refs": [ "SRC-019" ] }, { "target": "TAP 14, Open Test Reporting and JUnit-style XML (Maven Surefire schema)", "relation": "ALIGN", "purpose": "Alignment for ecosystem projections of execution results, including streamed test points with SKIP/TODO directives, started/finished events with SUCCESSFUL/FAILED/ABORTED outcomes, and rerun/flaky elements. These are projections with lossy mappings, not the semantics of this model.", "required": false, "source_refs": [ "SRC-018", "SRC-021", "SRC-022", "SRC-023" ] }, { "target": "OpenTelemetry semantic conventions for test attributes", "relation": "ALIGN", "purpose": "Alignment for the telemetry projection of test execution and for correlating traces to attempts. Its status vocabulary is deliberately narrower than this model's verdict list, so the mapping is recorded as lossy in both directions.", "required": false, "source_refs": [ "SRC-020" ] }, { "target": "WM-ACT-038 (registered parent model)", "relation": "CHILD", "purpose": "WM-SFT-015 is registered as a child of WM-ACT-038 and specialises the generic activity-and-outcome pattern for repeatable test definition and execution. Generic activity identity, agency and scheduling semantics remain in the parent; only test-specific definition, execution, evidence and assurance governance are specialised here.", "required": true, "source_refs": [ "SRC-001", "SRC-025" ] }, { "target": "WM-SFT-008 (build or release)", "relation": "REFERENCE", "purpose": "Carry release and build reference identifiers cited alongside an assurance summary, and expose stable, citable assurance-claim identifiers. Release lifecycle, gate criteria, gate verdicts and deployment approval are owned by WM-SFT-008; this model never records a gate outcome or infers release fitness from its own claims.", "required": false, "source_refs": [ "SRC-032", "SRC-031" ] }, { "target": "Requirement, risk and control models of the adopting Dimension", "relation": "REFERENCE", "purpose": "Resolve trace assertion targets and their pinned revisions. This model holds the assertion, its author, its reconfirmation moment and its staleness state; requirement and risk definition, revision, approval and closure remain in the target models.", "required": false, "source_refs": [ "SRC-024", "SRC-028" ] }, { "target": "Defect and incident model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Cite defect identifiers raised from failing results and blocking defects that prevent execution, aligned with the affectedByChangeRequest and blockedByChangeRequest relationship pattern. Defect triage, severity and resolution lifecycle are not mirrored here.", "required": false, "source_refs": [ "SRC-024" ] }, { "target": "Party, person and organisation registry of the adopting Dimension", "relation": "REFERENCE", "purpose": "Resolve owner, steward, custodian, author, reviewer, approver, executor and export-approver references. Party mastering, identity proofing and organisational structure remain external.", "required": true, "source_refs": [ "SRC-025", "SRC-026" ] }, { "target": "Records management and retention schedule model", "relation": "REFERENCE", "purpose": "Bind each record class to a retention rule and disposition authority, and receive disposition confirmations. Schedule authorship, disposition authority and the execution of destruction, sanitisation and transfer remain in the records model.", "required": true, "source_refs": [ "SRC-029" ] }, { "target": "Access control policy and enforcement model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Supply scopes and sensitivity labels that an external policy decision point consumes. Policy evaluation, enforcement and session authorisation are executed externally; this model records only admissibility determinations for operations on its own records.", "required": true, "source_refs": [ "SRC-026", "SRC-027" ] }, { "target": "Audit and event log model of the adopting Dimension", "relation": "REFERENCE", "purpose": "Carry references to audit entries generated by operations on these records so an investigator can resolve them. Audit capture, sequencing, tamper-evidence and retrieval semantics are owned by the audit model and are not reproduced here.", "required": true, "source_refs": [ "SRC-026" ] }, { "target": "OASIS OSLC Quality Management Version 2.1", "relation": "ALIGN", "purpose": "Map governance-relevant fields onto TestCase, TestExecutionRecord and TestResult resource shapes and their validatesRequirement, executesTestScript, runsOnTestEnvironment and producedByTestExecutionRecord relationships, for cross-tool exchange. Alignment is asserted; conformance is not claimed without assessment evidence.", "required": false, "source_refs": [ "SRC-024" ] }, { "target": "ISO/IEC/IEEE 29119-3:2021 test documentation templates", "relation": "ALIGN", "purpose": "Map this model's lifecycle, approval and completeness elements onto the standard's documentation items so records can be rendered as recognisable test documentation. Clause text is paywalled, so the mapping is held as partial pending clause-level verification.", "required": false, "source_refs": [ "SRC-001" ] }, { "target": "W3C PROV-O provenance ontology", "relation": "ALIGN", "purpose": "Express execution provenance using Entity, Activity and Agent with wasGeneratedBy, wasAssociatedWith, actedOnBehalfOf and qualified Association carrying hadRole and hadPlan, so provenance is portable beyond this model's own projections.", "required": false, "source_refs": [ "SRC-025" ] }, { "target": "in-toto Attestation Framework Statement v1 and SLSA Provenance", "relation": "ALIGN", "purpose": "Bind evidence artifacts by digest-matched subject and express producing-platform facts using the builder, external parameters, resolved dependencies and start and finish metadata pattern. Attestation issuance, key management and verification policy remain with the attestation infrastructure.", "required": false, "source_refs": [ "SRC-030", "SRC-031" ] }, { "target": "Sector and jurisdiction compliance profiles (data protection, AI, life sciences)", "relation": "MIX-IN", "purpose": "Overlay retention floors, log-keeping minima, signature-manifestation requirements and personal-data handling obligations onto the base governance rules. The profile supplies the obligation; the legal interpretation and the obligation's own lifecycle stay with the compliance model.", "required": false, "source_refs": [ "SRC-027", "SRC-028", "SRC-026" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must nominate a single accountable owner for the WM-SFT-015 package and publish the party registry against which owner, steward, custodian, author, reviewer, approver and executor references resolve.", "The Dimension must publish an effective separation-of-duties matrix and lifecycle state model before any record may reach an approved state, and must version both with effective-from moments.", "The Dimension must bind every record class to a retention rule and disposition authority in its records-management model, and must name the system that executes destruction, sanitisation and transfer.", "The Dimension must publish its sensitivity label vocabulary, redaction profiles and the access scopes those profiles serve, including the treatment of production-derived and personal data in test inputs and logs.", "The Dimension must declare any jurisdiction or sector profile in force and the precedence rule applied when a profile is stricter than the organisational default." ], "namespace_guidance": "Local identifiers in this model are lower-kebab-case and stable within the model; they are not global identifiers. The adopting Dimension assigns one namespace root per package and derives governed IRIs beneath it for artifacts, claims and mappings. Namespaces must never encode a date, an environment name, a storage technology or an owning team, since all four change while identifiers must not. External standard identifiers are carried verbatim as alignment targets with their version pinned, never rewritten into the local namespace.", "registry_links": [ "Registry entry vr.wm-sft-015 for model WM-SFT-015 at navigation path NAV.INF.SFT.TST, domain tags INF.SFT.TST.", "Parent registry entry WM-ACT-038, from which the activity-and-outcome pattern is specialised.", "Inbound relation from WM-SFT-008, which references test evidence for release assurance; the relation is recorded as candidate and its reciprocal binding is carried here as a REFERENCE only." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the semantic record set: stable record identifier, revision identifier, states, role assignments, provenance, evidence manifest, claims, classification and retention state. JSON, YAML, Markdown, HTML, Git, MCP and document renditions are projections and never define meaning.", "Property ordering, whitespace and serialisation style carry no meaning; two projections that differ only in these respects denote the same record and must yield the same content digest under the declared canonicalisation.", "All time values are canonicalised to RFC 3339 with explicit seconds and an explicit offset or Z; local-time strings without an offset are rejected at ingestion rather than assumed to be UTC.", "Absent and null are distinguished: absent means not recorded, null means recorded as having no value, and neither is canonicalised into an empty string.", "Coverage figures canonicalise as numerator, denominator, item type and method together; a bare percentage is not a canonical form and is rejected." ], "patch_rules": [ "Records in draft or recorded states accept field-level patches; records in approved, final or superseded states are corrected only by a superseding revision produced by the supersession function.", "Every patch and supersession request carries the expected current revision identifier; a mismatch returns an explicit conflict outcome and applies nothing, so lost updates surface rather than silently overwrite.", "Patch operations are idempotent by request identifier: replaying the same request identifier returns the original outcome without producing a second revision or a second approval record.", "Evidence artifacts and their digests are never patched. Content change produces a new artifact with a new digest and a derivation link; the manifest is revised to cite it.", "Approval records, provenance records and export manifests are append-only. A mistaken entry is withdrawn by a superseding entry that states the reason; it is never edited or removed.", "A patch that would change a record's sensitivity label, retention binding or hold state requires the same admissibility determination as the corresponding governance operation." ], "compatibility_rules": [ "Adding an optional field, a new code value in an open vocabulary, or a new alignment mapping is backward compatible and does not force a revision of existing records.", "Removing a field, narrowing cardinality, making an optional field required, or changing the meaning of an existing code value is breaking and requires a new model revision with a stated migration and a superseding pass over affected records.", "Consumers must ignore unknown fields and must not infer meaning from field order or from a projection's file layout.", "An alignment target's version is pinned per mapping row; an upstream version change invalidates only the affected rows and is recorded as a hold, never silently accepted.", "A conformance claim is never inherited across model revisions; it must be re-evidenced against the revision that claims it." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record that masters the subject, such as the quality or test management master system's test case identifier, the executing platform's execution-run identifier, or the records system's disposition identifier.", "Governed global identifier or IRI from a namespace the adopting Dimension or an external registry controls, used when no master-system identifier exists.", "UUID or ULID minted by the adopting Dimension, used only as a last resort and recorded together with the reason no higher-priority identifier was available.", "A date, a timestamp, a filename, a storage path, a sequence position or a content digest alone is never an identifier. A digest identifies a byte sequence, not a governed record, and a filename is convenience metadata that may change without changing identity." ], "timestamp_rule": "All time values are recorded as RFC 3339 date-time with explicit seconds and an explicit numeric offset or Z; local times without an offset are rejected at ingestion rather than assumed. Event time, observation time and ingestion time are recorded as separate fields whenever they can differ: execution started and finished moments are event time, a measurement or verdict determination moment is observation time, and the moment the record entered this model's custody is ingestion time. No field may be derived from another by defaulting, and ordering of serial artifacts uses event time, never ingestion time. Approval signing moments, integrity verification moments, coverage computation moments and export generation moments are each distinct observation times and are never collapsed into a single updated-at field.", "serial_naming_rule": "Serial artifacts, namely approval records, execution provenance records, coverage claim statements and export package manifests, are numbered within an explicitly declared scope: approvals per record identifier, provenance records per test case revision, coverage claims per measurement scope and revision, export manifests per recipient and boundary. The serial number is a within-scope ordinal and never an identifier on its own; it is always paired with the scope identifier. Serial numbers are assigned monotonically by event time, are never reused after withdrawal or disposition, and never encode a date, a year, an environment or an owning team.", "integrity_rule": "Every evidence artifact carries a content digest with a named algorithm and is matched purely by digest regardless of filename, location or content type. An evidence manifest is the integrity boundary of a result: an artifact absent from the manifest is not evidence for that result. Verification outcomes are recorded as verified, unverifiable, mismatched or missing with the verification moment, and a failed verification degrades the citing result's confidence grade rather than removing the record. Approvals bind to the digest of the exact revision approved and cannot be transferred to a successor. Redaction produces new artifacts with new digests plus a derivation link to the original digest; a redacted package is described as a derivation and never as a complete or accurate copy of the original record." }, "policies": [ "Testing evidence is bounded evidence. A passing result evidences only the conditions, data and environment actually exercised and never establishes the absence of defects; a coverage figure measures exercised items against a declared denominator and never establishes adequacy, correctness or fitness for release. Every assurance summary carries these caveats explicitly and a projection that strips them is non-conformant.", "Alignment is not conformance. Mapping this model's elements onto an external standard is an assertion about correspondence; a conformance claim requires the evidence that standard demands and defaults to false in its absence. Unresolved conflicts between aligned standards are held open as publication holds and are never resolved by silent preference for one source.", "Approved and finalised records are corrected by supersession, never by in-place edit, and evidence artifacts, approval records and provenance records are append-only. History that becomes inconvenient is superseded with a stated reason, not rewritten.", "Personal and production-derived data in test inputs, logs and attachments inherit the obligations of the source data: purpose limitation, minimisation, storage limitation and appropriate pseudonymisation or encryption. Where a synthetic or masked alternative would serve the test objective, use of a production copy requires a recorded justification.", "Records under an active legal hold are never disposed of, tombstoned or excluded from an assurance summary without an explicit, visible exclusion note naming the hold.", "Non-binary outcomes and unverifiable evidence are preserved and reported. Silently dropping inconclusive, blocked, aborted or integrity-failed records to improve an aggregate figure is a governance defect, not a data-quality cleanup." ], "crud": { "read": [ "Read of a record returns its stable identifier, revision identifier, lifecycle state, sensitivity label and retention state together with the content, so a consumer can never receive payload without its governance context.", "Field and artifact level masking is applied according to the sensitivity profile and the reader's access scope; masked elements are disclosed as withheld with their class, never omitted without trace.", "Reads of superseded revisions remain available to authorised readers for the retention period and are returned marked as superseded with their validity window.", "A read that resolves a tombstone returns the disposed state, the disposition authority and the confirmation reference rather than an empty or not-found response.", "Every read of a record labelled above baseline sensitivity generates an audit entry in the adopting Dimension's audit model; this model records only the returned audit reference." ], "create": [ "Creation requires a resolved owner reference, a sensitivity label, a retention rule binding and an ingestion timestamp; a record missing any of these is rejected rather than created in an ungoverned state.", "New records are created in a draft or recorded state and cannot be cited as evidence until the required review and approval transitions have completed.", "Creation is idempotent by request identifier: a replayed creation request returns the original record rather than minting a duplicate identifier.", "Identity is assigned by the priority order in the artifact rules; where a UUID or ULID is minted, the reason no higher-priority identifier was available is recorded with it.", "Result records must carry a resolvable pointer to the definition revision actually executed, and creation fails explicitly when that revision cannot be resolved." ], "update": [ "Updates are admissible only in states the lifecycle model permits and only for the fields that state permits; all other corrections proceed by supersession.", "Every update carries the expected current revision identifier for optimistic concurrency; a mismatch returns a conflict outcome and applies nothing.", "Updates to sensitivity label, retention binding, hold state or role assignment are governance operations that require their own admissibility determination and are recorded with the acting party, the moment and the reason.", "Evidence content, approval records, provenance records and issued export manifests are never updated; the corresponding append-only or supersession path applies.", "Failure semantics are explicit: rejected updates return the failed rule, the record's unchanged revision and whether a retry with a refreshed revision could succeed." ], "delete": [ "This model performs no unconditional physical deletion of its own records. The canonical path is: evaluate the bound retention rule against the recorded trigger and hold state, emit a disposition proposal, receive execution confirmation, then write a tombstone. Deletion requested outside this path is refused with the governing rule cited.", "Execution of destruction, sanitisation, archival transfer and media disposal is owned by the adopting Dimension's records-management model and its executing records system, not by this model; this model owns the retention binding, the hold state, the proposal and the tombstone only.", "Records under an active legal hold are never disposed of; the proposal is suppressed and the suppressing hold reference is recorded as the reason.", "Disposition outcomes are one of full erasure, redacted stub or tombstone. A tombstone retains the stable identifier, the disposition outcome, the disposition authority reference and the executing system's confirmation reference, so inbound references from results, assurance summaries and external release records resolve to an explicit disposed state rather than to a dangling pointer.", "Referential integrity is preserved on disposal: assurance summaries and trace assertions citing a disposed record are flagged as citing disposed evidence and are not silently recomputed to exclude it, so the change in evidentiary basis stays visible.", "Where a data-protection erasure obligation and a sector retention floor conflict, the conflict is escalated to the adopting Dimension's compliance authority and recorded as a hold; this model does not resolve the conflict and does not act on either instruction alone.", "Tombstones are themselves records with a stated retention rule; removal of a tombstone requires its own disposition proposal and confirmation." ] }, "roles": [ { "name": "Model owner", "responsibilities": [ "Hold accountability for the WM-SFT-015 package, its scope boundaries and its published governance artifacts.", "Approve model revisions, breaking changes and the resolution or continued holding of alignment conflicts.", "Nominate stewards and approve delegations of authority." ] }, { "name": "Record steward", "responsibilities": [ "Maintain test case and test result records day to day within a delegated authority.", "Keep sensitivity labels, retention bindings and trace assertions current, and act on reconciliation findings.", "Raise waivers where a separation-of-duties constraint cannot be met and record the compensating control." ] }, { "name": "Test author", "responsibilities": [ "Create and revise test case definitions, coverage item declarations and trace assertions.", "Record the evidential scope note bounding what a definition can evidence.", "Submit revisions for review and respond to review findings." ] }, { "name": "Reviewer", "responsibilities": [ "Examine a revision against the acceptance rules and the applicable integrity level before approval.", "Record review findings and refusal reasons in a form bound to the revision reviewed.", "Confirm that trace assertions and coverage declarations are supportable, not merely present." ] }, { "name": "Approver", "responsibilities": [ "Execute the approval act with printed name, moment of signing and declared meaning, bound to the revision digest.", "Verify that the required role set and independence conditions for the transition are satisfied before signing.", "Refuse and record the refusal where prohibited role pairs apply without a valid waiver." ] }, { "name": "Executor", "responsibilities": [ "Run the test procedure and produce result and provenance records with event, observation and ingestion times separated.", "Record non-binary outcomes truthfully rather than coercing them to pass or fail.", "Declare the tool, harness and environment used and any deviation from the approved procedure." ] }, { "name": "Evidence custodian", "responsibilities": [ "Hold stored evidence artifacts, maintain their digests and respond to integrity verification requests.", "Report unverifiable or missing artifacts rather than substituting equivalents.", "Apply storage-side protection consistent with the artifacts' sensitivity labels." ] }, { "name": "Records and privacy authority", "responsibilities": [ "Own retention schedules, disposition authorities and legal holds, and execute or authorise disposition.", "Determine handling obligations for personal and production-derived data appearing in test records.", "Adjudicate conflicts between erasure obligations and sector retention floors." ] }, { "name": "Release consumer", "responsibilities": [ "Cite assurance summaries and coverage claims by their stable identifiers when applying release gates owned elsewhere.", "Apply their own thresholds and gate verdicts without writing back into this model.", "Report citations that resolve to disposed or stale evidence." ] } ], "access": { "default_rule": "Deny by default. Access is granted per scope to an authenticated party holding a role assignment effective at the request moment, and never exceeds the least sensitive treatment permitted by the record's sensitivity label and its field and artifact overrides. Read of governance metadata does not imply read of payload or evidence content, and no role grants write access to append-only structures.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Records or fields labelled as containing personal or production-derived data require an elevated scope even for a party holding baseline read on the surrounding record; the surrounding record remains readable with those elements masked.", "Evidence artifacts under an active legal hold are readable only by the records and privacy authority and by parties the hold instrument names, regardless of otherwise sufficient scope.", "A break-glass read for incident investigation may bypass field masking, but only with a recorded authorising party, a stated reason, a bounded validity window and mandatory notification to the record owner.", "Cross-boundary access by an external release consumer is served through a redacted export package with a recorded export approval, never by granting direct scope into the home boundary.", "A separation-of-duties waiver may permit a party to hold two otherwise conflicting roles for a bounded period; the waiver is itself readable to the model owner and the reviewer population, so the exception cannot be silently normalised." ], "audit_requirements": [ "Every read of a record or artifact labelled above baseline sensitivity, every break-glass access, and every export generation must produce an audit entry in the adopting Dimension's audit model, whose reference is retained on this model's record.", "Every admissibility determination, approval, supersession, disposition proposal and tombstone creation must be attributable to a party reference with an RFC 3339 moment carrying seconds and an explicit offset or Z.", "Refused operations must be audited with the same rigour as permitted ones, including the rule that caused the refusal, so denial patterns remain analysable.", "Audit capture, ordering, tamper-evidence and retention are owned by the audit model; this model must not reimplement them and must not treat its retained audit references as a substitute audit trail.", "The absence or unresolvability of an expected audit reference is itself recorded as a governance exception rather than ignored." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Owner and steward contact references", "Sensitivity default and access scope summary", "Retention binding and disposition authority reference", "Known relations and their ownership boundaries", "Standards alignment status and any open conformance holds" ], "read_order": [ "AGENTS.md, to establish Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other access.", "The Specification URL, for the model boundary, in-scope and out-of-scope statements and boundary notes, so the agent learns what this model does not own before it acts.", "The Storage type URL, for the concrete projection in use, whether document store, graph, repository or database, remembering that the projection never defines semantics.", "The Interface URL, for the available read, create, update, supersede, approve, export, retention and tombstone operations and their failure semantics.", "The Processes URL, for the lifecycle state model, the separation-of-duties matrix, retention bindings and redaction profiles in force.", "The alignment map and any open conformance holds, before emitting or consuming records in an external standard's vocabulary." ] } }, "coverage": { "claim": "Bounded and explicitly non-universal. The merged Claude passes cover definition/design, execution/result evidence, and governance/assurance for WM-SFT-015 across 9 bundles, 19 layers, 40 findings, 177 questions, 22 artifacts and 23 functions, cited to 33 declared source records (32 distinct once SRC-001 and SRC-017 are recognised as the same 29119-3-2021 standard under two IEEE catalogue URLs). Completeness remains bounded by the package's own gap rows (coverage-adequacy thresholds, non-determinism classification), by clause-level non-retrieval of ISO/IEC/IEEE 29119-3/-4, IEEE 1012-2024 and FDA GPSV, by unverified live source pins, and by the owner-authorized absence of independent second-provider review. No dimension is claimed complete; the checklist's \"covered\" values are read as \"modelled and source-supported at the level actually retrieved\", not as canonical closure.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Authoritative identifier, issuing scheme, master system, alternate identifiers, revision identity, step identity and variant identity are modelled, with identity priority fixed in artifact rules and no date-like component permitted in any identifier." }, { "dimension": "relationships", "status": "covered", "notes": "Traceability to requirements, acceptance criteria, risks and assertions, test item references, keyword and step-definition delegation, inter-case dependencies and twelve typed composition links are declared; every neighbour link is a reference that withholds the target's lifecycle." }, { "dimension": "classification", "status": "covered", "notes": "Test level, test type, quality characteristic, automation status, priority, tags and data sensitivity class are declared against controlled vocabularies named by the owner package." }, { "dimension": "measurement and tolerance", "status": "covered", "notes": "Comparison rule, tolerance value and unit, rounding and precision, normalization and masking, and combinatorial value selection with interaction strength are modelled." }, { "dimension": "evidence and baseline integrity", "status": "covered", "notes": "Definition snapshots, data-set versions and expected baselines carry digest, byte size and media type, and a digest mismatch marks dependent evidence uninterpretable rather than resolving to a newer version." }, { "dimension": "coverage adequacy thresholds", "status": "gap", "notes": "No cited source fixes a normative threshold for when traceability or coverage is sufficient. The model records a coverage claim and uncovered coverage items but leaves the adequacy threshold to the adopting Dimension; this node is marked a gap rather than presented as canonical." }, { "dimension": "spatial and locale applicability", "status": "covered", "notes": "Platform, configuration and locale applicability conditions are modelled as constraints; localized authoring keywords are recorded as a parsing consideration under regional assumptions." }, { "dimension": "temporal", "status": "covered", "notes": "Attempt start/end (event time), observation time and ingestion time are separate required or optional fields under RFC 3339 with seconds and explicit offset or Z, including the -00:00 unknown-offset convention and a backfill flag." }, { "dimension": "evidence integrity", "status": "covered", "notes": "Named digests per artifact and per emitted document, an evidence manifest and an optional signed test-result attestation bound to the subject by digest, following in-toto. Key custody, trust roots and verification policy are outside the boundary." }, { "dimension": "non-determinism and reproducibility", "status": "gap", "notes": "Attempt-set disagreement, flake classification, instability measure and the reproducibility context (seed, digests, environment reference) are structured, but no primary standard normatively defines flaky-test classification or a flake-rate denominator. Maven Surefire's flakyFailure/rerunFailure distinction is a harness convention, not a specification, so this node is marked a gap rather than presented as canonical." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Physical or geographic location of execution is not a property of a result record. Where it matters (device farms, laboratory rigs, regulated sites), it is carried by the referenced environment or configuration-item model as an attribute of that entity." }, { "dimension": "lifecycle", "status": "covered", "notes": "Separate state vocabularies for definitions and results, gated transitions with required role sets, approval bound to a revision digest, correction by supersession, closed validity windows and defined regression conditions." }, { "dimension": "provenance", "status": "covered", "notes": "Agent, plan, activity and producing-platform facts aligned to PROV-O qualified associations and the SLSA build-definition pattern, with resolved dependencies, external parameters and an explicit statement of what provenance does not attest." }, { "dimension": "ownership", "status": "covered", "notes": "Owner, steward and custodian references with effective-from moments and transfer authorisation; nine governance roles with distinct responsibilities; separation-of-duties matrix with prohibited role pairs and recorded waivers." }, { "dimension": "validation", "status": "covered", "notes": "Acceptance rules for mandatory fields and resolvable links; non-binary verdict vocabulary preserved; confidence grading from tool trust, integrity status and independence; known-unreliable flagging without record deletion." }, { "dimension": "access", "status": "covered", "notes": "Deny by default across bundle, layer, finding and artifact scopes; field and artifact level masking; five named exceptions including break-glass with notification; audit references retained without claiming audit-trail ownership." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention rule binding with trigger events, separate clocks for results and evidence, legal hold suppression, disposition proposal, execution confirmation from the owning records system, and tombstones preserving referential integrity; conflicts between erasure obligations and sector floors escalated rather than resolved locally." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignment map with per-row version pinning and status codes including conflict and hold; conformance claim defaults to false; tool-specific report formats bound as import mappings with recorded gaps rather than adopted as semantics." }, { "dimension": "authority and approval", "status": "covered", "notes": "Signature manifestation carries signer name, moment of signing and declared meaning, bound so it cannot be excised, copied or transferred; authority checks precede gated transitions; integrity level grades required independence." }, { "dimension": "assurance claim discipline", "status": "covered", "notes": "Coverage stated as item type, method, numerator, denominator, exclusions and aggregation basis with a mandatory caveat; assurance summaries carry no threshold and no gate verdict, which remain owned by WM-SFT-008." }, { "dimension": "privacy and personal data", "status": "covered", "notes": "Personal data presence, data origin class and minimisation measures declared as facts on the record; purpose limitation, minimisation, storage limitation, by-design and pseudonymisation obligations inherited from the source data." }, { "dimension": "security", "status": "covered", "notes": "Digest and attestation binding, deny-by-default access, masking by scope, export approval before boundary crossing. Cryptographic key management, algorithm agility and transport security are delegated to the attestation infrastructure and the adopting Dimension and are marked out of scope." }, { "dimension": "measurement", "status": "covered", "notes": "Coverage numerator and denominator with declared item type and method; reliability observation windows; explicit treatment of exclusions as either removed from the denominator or counted as uncovered." }, { "dimension": "execution and result payload semantics", "status": "gap", "notes": "Deliberately out of this split pass. Step-level result detail, assertion outcomes, measured values, attachment typing and environment descriptor internals are declared in the combined boundary but are structured by adjacent passes; the merged result must supply them." }, { "dimension": "definition and design semantics", "status": "gap", "notes": "Deliberately out of this split pass. Preconditions, steps, expected results, parameterisation, data bindings and test technique derivation are in the combined boundary but are not modelled here beyond the identity and revision surface governance requires." } ], "known_omissions": [ "Clause-level text of ISO/IEC/IEEE 29119-3 templates and 29119-4 technique definitions was not machine-readable in this research; catalogue scope and abstract text were used and no field-level structure rests on those citations alone.", "The official ISTQB glossary is a client-rendered application that could not be retrieved, so ISTQB terminology is not used as normative evidence anywhere in this result despite being a preferred source class.", "Non-functional test design parameters such as load profiles, performance workload models and security abuse cases are represented only generically through parameters, tolerances and classification.", "Model-based testing artefacts such as behaviour models and generation grammars, and structural constructs of standardised test notations such as components, ports and defaults, are referenced but not modelled.", "Accessibility and localisation-specific expected-outcome rules, and property-based or metamorphic oracle families, are not specialised beyond the generic comparison-rule structure.", "Cost, effort and maintenance-burden attributes of a test case, which some management systems treat as first-class, are omitted for want of primary support.", "Test-case definition and design: preconditions, procedure steps, expected-result authoring, oracle design, test-data design and requirement traceability are left to the sibling definition pass and are only bound to here.", "Assurance aggregation: suite and campaign roll-ups, coverage claims, exit criteria and test completion reporting are left to the sibling assurance pass; only per-container derivation of an outcome from members is modelled here.", "Canonical governance service layers: the merger takes these from the governance pass, so the service_layers block supplied here is deliberately concise and execution-scoped.", "Performance, load and reliability result semantics: percentile aggregation, warm-up exclusion and statistical significance of a regression are not modelled; they would need a dedicated measurement model.", "Hardware-in-the-loop and real-time testing: sub-millisecond timing, clock domains, sampling jitter and physical instrumentation traceability are out of reach of RFC 3339 alone and are not addressed.", "Manual exploratory session semantics: session charters, time-boxing and note-taking conventions are referenced only through the manual assertion mode.", "Clause-level field lists from ISO/IEC/IEEE 29119-3:2021 could not be read directly (the ISO page returned HTTP 403 and the IEEE abstract does not enumerate template fields), so that standard supports process separation rather than specific field names here.", "Clause-level text of ISO/IEC/IEEE 29119-3:2021, ISO/IEC/IEEE 29119-4:2021 and IEEE Std 1012-2024 was not machine-extracted; only publisher metadata, scope and abstract were verified live. Field-level mappings to those standards' templates are therefore held as partial rather than asserted.", "NIST SP 800-218 task-level text for PS.3, PW.7, PW.8 and the RV practices sits in a PDF that did not convert; only the project page's practice-group statements and the note that version 1.1 added a provenance-data task were verified. Task-level citations are avoided.", "FDA General Principles of Software Validation is cited from its landing-page metadata only; specific statements about testing limitations, tester independence and record retention were not extracted and are not attributed to it.", "No test management tool schema is modelled. Common execution report formats are treated as import mappings with recorded gaps, not as semantics, so format-specific fields with no model counterpart are currently undocumented.", "Cryptographic algorithm agility, key rotation and long-term signature validity for evidence retained across decade-scale retention periods are delegated rather than modelled; long-horizon verifiability is a real unaddressed risk.", "Manual and exploratory testing evidence, where the executing agent is a person and the tool trust concept applies weakly, is accommodated but not specialised; the provenance structure fits automated execution more naturally.", "Cost, effort and scheduling attributes of test execution are absent; they belong to a work-management model that was not identified in the relation ledger.", "Multi-party and supplier-supplied test evidence, where the evidence originates outside the adopting Dimension's trust boundary, is handled only through tool trust level and integrity status; no supplier attestation acceptance policy is modelled." ], "conflicts": [ "Common ecosystem usage treats a test script as the automated implementation while some standards usage treats it as a synonym for a test procedure; the model avoids the term entirely and uses ordered actions plus automation binding.", "W3C Test Metadata makes Identifier, Purpose, SpecRef, ExpectedResults, Version, Contributor and Rights required, whereas ISO/IEC/IEEE 29119-3 documentation templates are explicitly tailorable; no universal mandatory field set can be claimed, so the required set is delegated to a validation profile.", "The OASIS Test Assertions Model states that one assertion may require several test cases and that coverage is often imperfect, which contradicts any naive one-to-one requirement-to-test-case traceability assumption.", "Parameterized constructs are treated as one case with many invocations by automation frameworks but frequently as distinct cases by test management systems; the model therefore requires variant identity to be declared rather than inferred.", "Keyword-driven decomposition places ordered actions in a shared keyword library, so step content may be partly owned outside the case; the model records the delegation reference instead of copying keyword bodies.", "Regulated validation guidance expects durable, requirement-traceable test records while fast-moving ecosystems routinely delete or rewrite tests; the immutability policy resolves this in favour of new revisions plus tombstones.", "JUnit-style XML has no single normative schema. The Apache Maven Surefire schema declares no target namespace and, by the project's own issue record, has lagged the elements the plugin actually emits (rerunError, flakyError, flakyFailure). Ant, Surefire and consumer implementations disagree on skipped and rerun handling, so this format is treated strictly as a projection.", "Status vocabularies conflict across sources and cannot be losslessly unified: SARIF separates kind (pass, fail, notApplicable, review, open, informational) from level (none, note, warning, error); EARL uses passed, failed, cantTell, inapplicable, untested; ACT Rules Format 1.1 uses the same five with untested meaning not evaluated; JUnit-style XML distinguishes failure from error and has only skipped; Open Test Reporting uses SUCCESSFUL, FAILED, ABORTED; OpenTelemetry test.case.result.status admits only pass and fail while test.suite.run.status adds skipped, aborted, timed_out and in_progress. Every mapping is flagged lossy.", "TAP 14 states that harnesses must not treat a failing TODO or SKIP test point as a failure, so a raw not-ok token does not map to a failed verdict. Any importer that maps not-ok directly to failure contradicts the specification.", "Retry semantics conflict with result immutability in common practice: Maven Surefire reports a flaky test's time as that of the last successful run and an all-failing test's time as that of the first failing run, collapsing an attempt series into one testcase element. This model rejects that collapse and retains each attempt, so round-tripping through that projection is asymmetric.", "SARIF baselineState (new, unchanged, updated, absent) expresses change relative to a baseline run, which overlaps but does not coincide with this model's supersession semantics; an absent result is not a withdrawn record.", "in-toto's test-result predicate admits only PASSED, WARNED and FAILED and carries test names as free strings whose semantics are agreed bilaterally, so it cannot express blocked, inconclusive or untested and cannot by itself preserve record identity.", "The cited SLSA Provenance page is marked retired with v1.2 current, while the in-toto Statement layer v1 remains current. The version skew between the two aligned specifications is recorded as a publication hold on the attestation mapping rows rather than resolved by adopting one version silently.", "Data-protection erasure and minimisation obligations can require removal of personal data from test evidence, while sector rules can require the same technical documentation to be retained for a decade and logs for a minimum period. This model records the conflict and escalates it; it does not resolve it, and no default precedence is encoded.", "Electronic-records rules requiring accurate and complete copies in human-readable and electronic form sit uneasily with redaction-based export. This is held open by requiring the export manifest to state that the package is a redacted derivation and not a complete copy, but the tension is not eliminated.", "ISO/IEC/IEEE 29119-3 documentation items and OASIS OSLC Quality Management resource shapes partition the same domain differently: the former is document-and-process oriented, the latter resource-and-link oriented. Both mappings are carried; neither is declared canonical, and rows where they disagree are marked conflict.", "Immutability of approved evidence conflicts with correction of a factually wrong record. Resolved in favour of append-only plus supersession, which preserves the wrong record with a stated correction; organisations expecting in-place correction will find this restrictive, and that expectation is a genuine competing practice, not an error.", "IEEE 1012 grades independence by integrity level while much industry practice treats author-executes-own-test as normal for unit-level testing. The model records independence as a graded claim rather than a binary requirement, which weakens comparability across organisations." ], "regional_assumptions": [ "FDA General Principles of Software Validation is United States medical-device guidance; comparable duties elsewhere, including EU medical device regulation with IEC 62304, aerospace DO-178C, automotive ISO 26262 and rail EN 50128, impose analogous but differently worded documentation and retention obligations.", "Retention periods for test evidence are jurisdiction- and sector-specific and are declared by the adopting Dimension rather than by this model.", "Constraints on production-derived personal data used as test data assume a GDPR-like regime where one applies; other regimes permit or forbid different practices, and the privacy model reference absorbs the difference.", "Authoring language and locale are assumed to be declared by the adopting Dimension; localized keywords in executable scenario formats affect parsing and must be recorded with the specification document.", "Retention and access rules assume a data-protection regime of the EU GDPR type, where captured screenshots and logs may constitute personal data. Jurisdictions with different regimes will alter the retention schedule and redaction obligations without changing the model structure.", "No sector-specific evidence regime is assumed. Regulated domains such as medical device software (IEC 62304), airborne software (DO-178C), automotive functional safety (ISO 26262) and clinical or laboratory settings impose additional mandatory evidence, independence-of-reviewer and record-retention requirements that the adopting Dimension must add as constraints.", "Timestamps assume a network-synchronised clock. Air-gapped, embedded or offline execution environments may produce unsynchronised or unknown-offset times, which the model represents with -00:00 and a confidence note rather than by silently normalising.", "English-language governed code lists are assumed; localisation of verdict and role labels is a presentation concern and must not create parallel code values.", "Retention floors, log-keeping minima and technical documentation retention periods drawn from European Union regulation apply only where those regulations bind; other jurisdictions are assumed to supply their own profile through the jurisdiction profile mix-in.", "Electronic signature and audit-trail expectations drawn from United States electronic-records regulation are treated as a sector profile for regulated life sciences, not as a universal default; organisations outside that scope may use a lighter approval manifestation.", "Personal-data obligations assume a controller or processor model with purpose limitation and storage limitation. Jurisdictions with materially different data-protection architectures will require a different profile, and the model does not attempt to generalise across them.", "United States national archives records requirements are used as a structural template separating retention binding, disposition authority and destruction execution. This separation is treated as good practice rather than as a legal requirement outside its jurisdiction.", "Aviation, medical device, automotive and rail assurance regimes impose structural coverage and independence requirements that are only accommodated through the integrity level and coverage item type; no sector-specific coverage vocabulary is supplied, and one would be needed before use in those sectors.", "Language, calendar and time-zone assumptions default to RFC 3339 with an explicit offset; organisations operating a non-Gregorian business calendar must map their retention triggers onto that representation themselves." ], "adversarial_checks": [ "The aggregate-root assumption was challenged directly. Exploratory and session-based testing produces results and evidence with no pre-existing reusable definition, and property-based or combinatorial generation produces runs whose definition is a generator plus a seed. Both are genuine counterexamples to a strict definition-root aggregate and are recorded for boundary adjudication rather than suppressed; the model accommodates them only by allowing a generator reference and generation parameters as derivation provenance.", "Independent-lifecycle counterexamples were sought and found. A definition may be retired while its past executions remain under a legal retention duty, one execution may satisfy several test cases at scenario or session level, and one case may be realised by several independent implementations. The binding is therefore modelled as a citation of a frozen, digest-bound revision, which supports many-to-many relations without either side owning the other.", "Every bundle, layer, finding and function was compared against the WM-SFT-008 reference rationale and against each outgoing reference and alignment. No local structure carries release-gating decisions, release lifecycle, suite membership or ordering, campaign scheduling, defect triage, environment provisioning, pipeline dispatch, runtime policy enforcement or organisation-wide audit-trail semantics; the selection function explicitly returns candidates and leaves sequencing and dispatch to the referenced models, and the access audit requirements store only a reference to the audit record.", "Attractive but unsupported structure was rejected: a locally owned traceability matrix, a local coverage-adequacy threshold, a local flakiness-scoring algorithm, a local defect-linking workflow and a local copy of executable scripts were each considered and rejected for want of primary support or because they would fork a neighbour's lifecycle. Coverage adequacy is recorded as an explicit gap instead of being invented.", "An evidence-tier check was applied to every citation. ISO/IEC/IEEE 29119 references are catalogue records carrying scope and abstract text rather than clause text and are labelled as such; every field-level structure is additionally supported by a clause-level source or a first-party ecosystem reference, and the two preferred source classes that could not be retrieved are listed as known omissions rather than paraphrased from secondary summaries.", "A terminology counterexample search was run against a mature automation ecosystem that collapses case, procedure and script into a single annotated method, which would justify merging those concepts. The separation was retained because the cited standards distinguish them and because the reuse requirement of one definition, many executions and several possible bindings cannot be expressed once they are merged.", "Can a verdict be recorded without an assertor or mode? No: verdict code and assertor reference are both required, and the adjudication function names the mode even for automated assertions. This is the EARL separation and is what prevents an unattributable pass.", "Can a rerun erase a failure? No: retry creates a new attempt with the next ordinal and a predecessor link, observations are sealed when an attempt finishes, and patch rules reject in-place mutation. The Surefire convention of collapsing an attempt series into one element is explicitly recorded as a lossy projection rather than adopted.", "Can a pass be inferred from an absent defect, an empty failure list or a zero exit code? No: an explicit policy and a validation rule require a recorded, evaluated expectation for a pass, and the outbound-links finding carries the inference prohibition and its error code. A zero exit code is stored as an observed invocation fact, never as a verdict.", "Does any node claim ownership of a target model's semantics? Checked node by node against the WM-SFT-008 relation rationale and each composition link: retry policies, quarantine decisions, integrity verification, release gating, defect state, environment provisioning, principal entitlement and audit-trail durability are all expressed as references or as outcomes reported back, and appear in out_of_scope or boundary_notes. The integrity finding deliberately asks only what a verifier reported, not what this model verified; the audit requirement states the audit-log model writes and retains the trail.", "Can a record be identified by a date, a status or a test-case identifier? No: identity_priority item four names each of these as never acceptable, no local ID contains a date-like component, and the model requires a subject-under-test digest plus an execution identifier rather than a name-and-time pair.", "Is deletion silently possible? No: crud.delete forbids in-place deletion, mandates a tombstone retaining identifier, binding, ordinal, verdict state and removed-evidence digests, and names the adopting Dimension's retention policy and the artifact store as the owners of disposition execution, explicitly excluding WM-SFT-008 from that ownership.", "Does the structure survive a format with no identifiers? Tested against JUnit-style XML and TAP 14, both of which identify tests by name or ordinal only. The interchange finding requires an identifier carriage mechanism and collision handling, and declares the internal record authoritative, so a lossy projection cannot silently redefine identity.", "Does any bundle, layer, finding or function claim ownership of release-gate criteria, gate verdicts, release states or deployment approval, which the WM-SFT-008 relation rationale leaves in that model? Checked: the coverage-claim finding and the assurance-summary function both state that thresholds and verdicts belong to the referencing release model, the release link is a REFERENCE carrying identifiers only, and gate ownership appears in out_of_scope and boundary_notes.", "Does the authorization function or the access layer smuggle in ownership of runtime policy evaluation, enforcement or audit-trail semantics? Checked: the admissibility function explicitly excludes authentication, external policy evaluation and enforcement, and the access layer states that audit capture, ordering, tamper-evidence and retention belong to the audit model, with only references retained. The absence of an expected audit reference is recorded as an exception rather than treated as this model's failure to audit.", "Does any finding reproduce requirement, risk, defect or party lifecycle that a referenced model owns? Checked: trace assertions carry only the assertion, its author, its reconfirmation moment and its staleness flag, with an inline rationale explaining why no local traceability matrix artifact is emitted; ownership and role holders are party-registry references with no local party attributes.", "Is any coverage or assurance figure presented in a way that could be read as proving adequacy or the absence of defects? Checked: a mandatory caveat data element, an evidential scope note, an explicit question on what a passing result establishes, and a standing policy all forbid that inference, and a bare percentage is declared non-canonical and rejected.", "Is any standards alignment presented as conformance? Checked: the conformance claim indicator defaults to false, conformance requires named evidence, mapping status codes include conflict and hold, and the four sources whose full text was not extracted are labelled as such in their relevance notes and in known_omissions.", "Does the delete rule leave any path to unconditional physical deletion inside this model? Checked: deletion outside the retention-proposal-confirmation-tombstone path is refused with the governing rule cited, execution is assigned to the records-management model and the executing records system, holds suppress proposals, and tombstones themselves carry a retention rule.", "Does any local identifier contain a date-like component, and is every identifier unique? Checked: all bundle, layer, finding, question, data element, artifact and function identifiers use the tst-gov- prefix with word-only segments, no numeric or date fragments, and no repeated identifier across the document.", "Does every finding satisfy the exclusive artifact rule? Checked: seven findings declare artifacts with a null rationale; six declare an empty artifact array with a substantive rationale explaining why the context is reference or attribute data whose materialisation would create a divergent second source of truth. No finding populates both." ] }, "researchAdjudication": { "providerMode": "single-provider-waiver", "activeProviders": [ "claude" ], "waivedProviders": [ "grok" ], "providerPolicy": { "contract_version": "1.0.0", "mode": "single-provider-waiver", "effective_at": "2026-08-29T09:06:27Z", "scope": "Queued subject-model research from WM-XCT-013 onward", "active_providers": [ "claude" ], "waived_providers": [ { "provider": "grok", "authorized_by": "repository owner", "authorized_at": "2026-08-29T09:06:27Z", "reason": "The repository owner explicitly instructed the research queue to continue without Grok after repeated structured-output failures." } ], "review_rule": "Claude-only results require a separate no-tools adversarial audit and remain reviewable drafts with a visible single-provider hold." }, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Two distinct axes must not be collapsed. Record plane: registry entry vr.wm-sft-015 sits at NAV.INF.SFT.TST with domain tags INF.SFT.TST, specialising parent WM-ACT-038; a frozen registry value such as standalone-mm classifies how the record occupies the registry plane and is not a member of the subject-model kind enum, so it can never be emitted as entry_kind. Subject-model plane: the modelled subject is a composite with one root (the frozen, digest-bound test case definition revision) plus governed members (executions of that revision, observed outcomes, adjudicated verdicts, captured evidence, derived assurance signals, and the ownership/approval/access/retention record binding them) under a single integrity and disposition boundary. 'aggregate' is the only schema kind carrying root-plus-members; 'entity' would strand the execution and evidence members, 'event' would privilege the execution and orphan the reusable definition, and relationship, mixin, pattern, registry and classifier do not describe a governed member set at all. Accepted with one binding constraint the synthesizer must publish rather than imply: the root is a citation anchor, not a lifecycle owner. The package's own adversarial checks concede that results outlive retired definitions under legal retention, that one execution may satisfy several cases, that one case may bind several implementations, and that exploratory and generator-plus-seed runs may have no pre-existing definition. The aggregate therefore holds by frozen-revision citation and many-to-many binding, not by DDD-style lifecycle containment, and the published scope statement must say so explicitly." }, "decisions": [ { "concept": "Aggregate root as frozen test case definition revision", "disposition": "accepted with a published weakened-root invariant", "rationale": "The root governs members by digest-bound citation, not by lifecycle containment. Results survive definition retirement under retention duty, executions can satisfy several cases, and exploratory or generator-seeded runs have no prior definition. Accepting the root without publishing this qualification would assert a containment guarantee the evidence does not support." }, { "concept": "Entry kind axis separation (schema kind versus registry record plane)", "disposition": "accepted: emit 'aggregate' as entry_kind, carry the registry plane value only as a registry attribute", "rationale": "The registry classification describes the record's position in the registry, while entry_kind describes the modelled subject. Emitting a record-plane value as entry_kind would make the subject unclassifiable against the schema enum and would break downstream kind-driven validation." }, { "concept": "Service-layer provenance across three split passes", "disposition": "accepted from the governance pass, conditional on lifting execution-scoped canon rules before publication", "rationale": "The execution pass declares its own service_layers deliberately concise and delegates to the governance pass, so the governance block is canonical. But the -00:00 unknown-offset and backfill-flag convention, and the attempt-immutability rule, currently live only in checklist notes and finding text; they must appear in canonicalization_rules and patch_rules or the merged canon under-specifies what the structure already relies on." }, { "concept": "Two artifacts both named 'Evidence manifest' with different identity strategies", "disposition": "rejected as-is; must be reconciled to one artifact identity or explicitly scoped as two distinct objects", "rationale": "tst-exec-artifact-evidence-manifest keys on owning execution identifier plus manifest content digest, while tst-gov-art-evidence-manifest keys on the result record identifier plus a manifest revision identifier. Two same-named integrity boundaries with divergent keys is exactly the competing-source-of-truth failure the model's own inline-only rationales forbid elsewhere." }, { "concept": "Serial artifact scope declarations", "disposition": "rejected as-is; a within-scope ordinal must be declared for every serial artifact", "rationale": "Thirteen of twenty-two artifacts carry serial: true, but serial_naming_rule enumerates scopes for only four classes (approval records, provenance records, coverage claims, export manifests). Nine serial artifacts — definition snapshot, test data set, expected baseline, comparison record, actual output capture, execution log, visual capture, telemetry trace, result report and format projection among them — have no declared numbering scope, so their ordinals are unverifiable." }, { "concept": "Capture timestamp inside the visual-capture identity strategy", "disposition": "rejected; replace with digest plus owning attempt identifier and capture role ordinal", "rationale": "identity_priority states a date or timestamp is never an identifier and serial_naming_rule forbids date encoding in ordinals. Admitting capture timestamp into a fallback identity contradicts both rules and makes two byte-identical captures separately identified purely by clock reading." }, { "concept": "SRC-017 as a source distinct from SRC-001", "disposition": "rejected; dedupe to a single record and rewrite affected source_refs", "rationale": "Both entries are IEEE/ISO/IEC 29119-3-2021 under two IEEE catalogue URLs (7499 and 7498). Carrying them as two tier-1 primary sources inflates the apparent independent-evidence base for findings that cite one or the other, which is a material overstatement in a package whose discipline rests on citation counts." }, { "concept": "FDA General Principles of Software Validation (SRC-009) citations", "disposition": "rejected pending extraction; either drop the refs or re-extract the document text", "rationale": "known_omissions states that specific FDA statements about testing limitations, tester independence and record retention were not extracted and are not attributed to it, yet SRC-009 appears in source_refs for the duty-separation, readiness and validation-confidence findings — precisely those three subjects. The citation ledger contradicts the declared omission and must be reconciled before publication." }, { "concept": "Coverage checklist rows marked 'gap' for definition/design and execution/result payload semantics", "disposition": "reclassified to covered-by-merge with a provenance note", "rationale": "Both rows say the dimension is deliberately out of a split pass and that the merged result must supply it. The merged record does supply both through the tst-design-* and tst-exec-* bundles, so leaving them as gaps understates the package and misleads reviewers about what remains open." }, { "concept": "Duplicate and contradictory checklist dimensions", "disposition": "accepted after merge with an explicit reconciliation note", "rationale": "'measurement and tolerance' duplicates 'measurement', 'evidence and baseline integrity' duplicates 'evidence integrity', and 'spatial' (not-applicable) sits beside 'spatial and locale applicability' (covered). The last pair is reconcilable — locale applicability is a definition attribute, geographic execution site belongs to the referenced environment model — but published as two rows it reads as self-contradiction." }, { "concept": "'Full erasure' as a permitted disposition outcome", "disposition": "reclassified: content erasure with a mandatory tombstone, preserving the erasure-versus-retention escalation path", "rationale": "crud.delete promises that inbound references resolve to an explicit disposed state rather than a dangling pointer, and tst-gov-fn-tombstone-record replaces the record with a tombstone on confirmation. Full erasure without a tombstone breaks that guarantee. Where an erasure obligation reaches the identifier itself, the existing escalation-to-compliance-authority path must remain the only route, not a silent third outcome." }, { "concept": "Access default rule wording on append-only structures", "disposition": "reclassified; distinguish append from mutate in the default_rule text", "rationale": "The rule states no role grants write access to append-only structures, yet executors must append provenance records and approvers must append approval records. As written the access layer forbids the writes its own roles and functions require; the fix is to deny update and delete while permitting governed append." }, { "concept": "Overlap between tst-gov-fn-supersede-revision and tst-exec-fn-supersede-result", "disposition": "accepted with explicit scoping rather than merger", "rationale": "Two functions can currently both claim authority over correcting an adjudicated result record. Scope the governance function to approved-and-finalised definition and governance records and the execution function to adjudication corrections, with each naming the other as the out-of-scope path, so a caller never has two admissible routes for one correction." }, { "concept": "Absence of an ingestion or import function for externally produced result documents", "disposition": "deferred; recorded as a research item, not added in single-provider mode", "rationale": "canonicalization_rules reject local-time strings 'at ingestion', crud.create requires an ingestion timestamp, and known_omissions treat common report formats as import mappings, yet no function models ingestion. Adding one is out of bounds here because no second provider exists and the waiver forbids new functions, so it must be carried into the next pass." }, { "concept": "Self-reported exclusive-artifact-rule count in adversarial_checks", "disposition": "rejected as stale; recompute over the merged record before publication", "rationale": "The check claims seven artifact-bearing and six inline-only findings for the governance-prefixed set, but the merged record shows eight artifact-bearing and five inline-only. The rule itself holds — no finding populates both — but a published self-attestation whose arithmetic does not match the record it attests to undermines the audit trail it is meant to supply." } ], "publicationHolds": [ "Single-provider hold: independent second-provider review is absent by explicit repository-owner waiver of Grok, authorized 2026-08-29T09:06:27Z after repeated structured-output failures. No cross-provider corroboration exists for any bundle, layer, finding, question, artifact or function; entry_kind agreement is 'waived' with no counterpart value. Every publication artifact must display the waiver, the authorizing party, the authorization moment and the fact that the substitute control is a single no-tools adversarial audit. The result stays a reviewable draft and must not be promoted to canonical on the strength of one provider.", "Live source and version verification hold: all 33 source records must be re-resolved live with their version pins re-read before publication. Named at-risk pins: SRC-031 SLSA Provenance v1.0 is self-marked retired with v1.2 current; SRC-019 in-toto test-result predicate is v0.1.0 and pre-stable; SRC-020 OpenTelemetry test attribute registry is at development stability and may change without notice; SRC-022 and SRC-023 pin a master-branch XSD and a 3.6.0-M1 milestone documentation page; SRC-011 pins JUnit User Guide 6.1.3; SRC-015 asserts ACT Rules Format 1.1 as a W3C Recommendation of 2026-02-05; SRC-026 cites 21 CFR Part 11 from the CFR edition revised 2024-04-01 while later annual editions exist as of the audit date.", "Source-authority hold on the design pass: SRC-005, a 2005 W3C Working Group Note, carries the largest share of field-level weight across the design bundles (identity, objective, traceability, preconditions, parameters, oracle, postconditions, applicability, readiness) while the tier-1 ISO/IEC/IEEE 29119 citations are admittedly catalogue and abstract level only. The Note's current status must be re-verified and design-pass field-level claims re-anchored or explicitly downgraded before publication.", "Citation-integrity hold: known_omissions declares that FDA General Principles of Software Validation (SRC-009) was read from landing-page metadata only and that statements on testing limitations, tester independence and record retention are not attributed to it, yet SRC-009 is cited by tst-design-finding-ownership-readiness, tst-gov-f-duty-separation and tst-gov-f-validation-confidence. Resolve by removing the refs or by extracting the document, and do not publish the contradiction.", "Duplicate source hold: SRC-001 and SRC-017 are the same standard, IEEE/ISO/IEC 29119-3-2021, under two IEEE catalogue URLs. Publish only after dedupe and source_ref rewrite, or with an explicit statement of why two records for one standard are retained, so the independent-evidence count is not overstated.", "Artifact-identity hold: thirteen artifacts are marked serial while serial_naming_rule declares within-scope ordinals for only four classes, and the visual-capture fallback identity admits a capture timestamp that identity_priority and serial_naming_rule both forbid. Both defects must be closed before any artifact identity is treated as governed.", "Coverage-statement hold: the checklist still carries two split-pass 'gap' rows that the merged structure now supplies, plus duplicate rows for measurement and evidence integrity and an apparent spatial contradiction. Republish the checklist against the merged record so that remaining gaps read as genuinely open (coverage adequacy thresholds and non-determinism classification) rather than as merge residue.", "Independent second-provider review was explicitly waived by the repository owner; this Claude-only result remains a reviewable draft." ], "deferredResearch": [ "Acquire clause-level text of ISO/IEC/IEEE 29119-3:2021 and 29119-4:2021 and IEEE Std 1012-2024 through licensed access, then re-map documentation-template field lists and V&V independence gradings; until then those citations support process separation only and no field-level mapping may be asserted from them.", "Retrieve the ISTQB glossary through a non-client-rendered route (printable export or archived snapshot) so that a preferred terminology source can be used as normative evidence rather than excluded, and re-check the test case, test procedure, test script and test item definitions against the model's terminology choices.", "Locate a normative basis for coverage adequacy thresholds — DO-178C objective tables, ISO 26262 structural coverage tables, IEC 62304 class-dependent requirements — before the coverage-adequacy gap row can be closed; the model currently and correctly delegates the threshold to the adopting Dimension.", "Establish whether any specification-grade source defines flaky-test classification and a flake-rate denominator; the current structure rests on Maven Surefire's flakyFailure and rerunFailure harness convention, which the package itself declares is not a specification.", "Design and source an ingestion function for externally produced result documents, covering identifier carriage, schema validation failure recording and lossy-mapping capture, since ingestion is referenced by canonicalization rules, crud.create and known_omissions but is modelled by no function.", "Research long-horizon evidence verifiability for decade-scale retention: cryptographic algorithm agility, key rotation, trusted timestamping and long-term signature validation, which the package currently delegates and names as a real unaddressed risk.", "Define a supplier and multi-party test-evidence acceptance policy for evidence originating outside the adopting Dimension's trust boundary, which is presently handled only through tool trust level and integrity status.", "Investigate performance, load and reliability result semantics — percentile aggregation, warm-up exclusion, statistical significance of a regression — and decide whether they belong in a dedicated measurement model rather than as parameters and tolerances here." ] }, "statistics": { "sources": 33, "bundles": 9, "layers": 19, "findings": 40, "questions": 177, "artifacts": 22, "functions": 23 } }