Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

A nested lifecycle

Authors
Affiliations
Dynamical Systems Group
Humane Intelligence

The two cycles are one model. The contracting lifecycle is the outer process; its fulfil step is typed by the evaluation process, a black box from outside and the whole of the previous chapter from inside. This chapter shows why the nesting is the standards’ own, how the model states it, and how the measles record splits along it.

1What the standards say

ISO/IEC/IEEE 15288 keeps its process groups coordinate; nothing nests. What nests here is the work: the acquirer’s agreement opens and closes it, and the supplier performs the ISO/IEC/IEEE 29119-2 test processes under it. So an evaluation is what a provider does between the test item provider’s grant of access and its own delivery to the customer, and the six steps of the inner cycle sit between C4 and C5 of the outer one. ogc steps prints both cycles with the canon step each matches; the previous two chapters quote them.

2The specification

One view, read from the model graph, shows the nesting and nothing else: the outer chain with fulfil as a black box, the inner chain it opens into, and the only wires that cross the boundary. The contract hands in the agreement, the statement of work and the access; the evaluation hands back the report, its approval and the recommendation; the two chapters before this one draw the inside of each chain.

View nesting: the nested lifecycle. In focus: the two cycles as chains of steps, the fulfil step as a black box in the outer chain and opened as the inner chain, and the only wires that cross the boundary: what the contract hands in and what the evaluation hands back, bundled by item kind. Left out: the flows inside each chain, the parties, the parts and ports, the DSO as a parameter, and who performs which step (the two chapters before this one have them).

The same view as the tool prints it, perspective first, figure beneath:

view-nesting.md
$ uv run -q ogc view nesting
# ogc view nesting @ <sha>
## nesting: The nested lifecycle
  in focus: the two cycles as chains of steps, the fulfil step as a black box in the outer chain
  and opened as the inner chain, and the only wires that cross the boundary: what the contract
  hands in and what the evaluation hands back, bundled by item kind.
  leaves out: the flows inside each chain, the parties, the parts and ports, the DSO as a
  parameter, and who performs which step (the two chapters before this one have them).
(20 lines after this omitted; run the command for all)
(exit 0)

In SysML v2, the systems modelling language the model is written in, the outer cycle is an action def, a process as steps in fixed succession, of seven steps, and the inner cycle another of six. The step fulfil is declared action fulfil : EvaluationProcess; its inputs, the agreement, the statement of work and the access, are bound by flow, SysML’s binding of one step’s output to another’s input, from the agree and access steps, and its outputs, the report, its approval and the recommendation, flow to the deliver step. The inner process is the drill-down, the black box opened one level down, and conforms to the layer above by typing: shape M4-Nesting, one of the machine-checked rules over the model graph, checks that every input of the evaluation process is fed by a contracting step and every output feeds one. The assembly performs one action, the contracting lifecycle. The report step is opened the same way one level down: the checker’s verdict on the record first, then the assembly of the report that rests on it, two nested actions bound to the step’s parameters.

The record and the report rest on both lifecycles at once: the mission, the agreement and the access come from the contracting lifecycle; the requirement set, the plan, the evidence and the attestations from the evaluation. The traceback from a recommendation reaches both sides in one query, and the report leaves the inner cycle to become the delivery’s content in the outer. A record that held only the evaluation could say what was found, not under what contract or for whom; one that held only the contract could say what was agreed, not what was shown. Shape S0-Layers on the record and shape M4-Nesting on the model guarantee that both are present.

SysML holds structure only: the source file is the authoring view, and its rendering as RDF by the pinned OpenSysML converter is the canonical structure every shape and figure reads, pruned to the terms in the term map (model/sysml_term_map.csv, each term with a rationale) and committed with a manifest and a triple budget (the cap on the graph’s size, raised only with a reason).

3The walkthrough

The measles record splits along the same seam. What the contract pinned was recorded between 28 and 31 July and again between 12 and 14 August: the contract’s items from the mission to the acceptance. What the evaluation pinned was recorded between 1 and 12 August, inside that window, by Annie, Theo, Dana Okafor and the machines. The table counts what each layer contributed to the one record.

LayerItem kindsItemsFirstLastWho
contractAcceptance, Delivery, EngagementDecision, IndependenceDeclaration, Mission, Need, Population, Proposal, ServiceAgreement, StatementOfWork, TestItemAccess, UserInterestDeclaration122026-07-282026-08-14Dana Okafor, Mala, Meridian Health Software, the chatbot’s vendor, county public-health office
evaluationAcceptanceCriterion, ConformanceVerdict, DsoRelease, Evidence, Probe, Recommendation, Report, ReportApproval, Requirement, RequirementSet, RequirementSetApproval, Response, StakeholderInput, StakeholderRepresentation, TestPlan, Trajectory552026-08-012026-08-12Annie, Dana Okafor, Theo, commuters through the county, public-health chatbot, pySHACL

The shape that holds the layers apart, as the tool prints it:

shape-s0-layers.md
$ uv run -q ogc shape S0-Layers
# ogc shape S0-Layers @ <sha>
## S0-Layers  (shapes/epo.shapes.ttl)
target: epo:ServiceAgreement
counterexamples (executor mutations): requirements-before-agreement

property constraints (0):
(none)

sparql constraints (1):
  - S0 two layers (R-32): every item of the record pinned at the contract is generated no later
    than the requirement set, and every item pinned within the evaluation no earlier than the
    agreement.
      PREFIX epo: <https://w3id.org/og-caie/epo#>
      PREFIX ogc: <https://w3id.org/og-caie/>
      PREFIX prov: <http://www.w3.org/ns/prov#>
      SELECT $this ?value WHERE {
          $this prov:generatedAtTime ?ta ; ogc:inRecord ?rec . ?rs a epo:RequirementSet ;
              ogc:inRecord ?rec ; prov:generatedAtTime ?tr .
          ?value a ?cls ; ogc:inRecord ?rec ; prov:generatedAtTime ?t . ?cls ogc:pinnedAt ?layer
              .
          FILTER( (?layer = epo:contract && ?t > ?tr && NOT EXISTS { ?value a epo:Delivery } &&
              NOT EXISTS { ?value a epo:Acceptance })
               || (?layer = epo:evaluation && ?t < ?ta) )
      }
(exit 0)

4Checked

The authoring view validates strictly under the pinned converter; the canonical graph regenerates byte for byte within its budget; M4-Steps, M4-Nesting, M4-ProcessDag and M4-EveryItemProduced hold over it, the third checking that the steps form a DAG (a directed acyclic graph, no loop); S0-Layers holds over the record, and the counterexample of a requirement set declared before the agreement must fail it.

5Receipts

5.1Strict validation of the authoring view

$ sysml model/og-caie.sysml -validate -strict
✓ package OGCAIE
✓ model/og-caie.sysml: no errors
(exit 0)

5.2The canonical model graph

sysml -convert ttl renders 18976 triples; the term map keeps 5712 (385 of them resolved ends computed by scripts/prune_model.py), within a budget of 6600. Conformance of the graph to the 12 wiring shapes M1 to M5: conforms.

6There is more in the model

7Sources cited

References
  1. International Organization for Standardization. (2026). ISO 9000:2026 Quality management — Fundamentals and vocabulary. International Organization for Standardization. https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-5:v1:en