Add systems engineering and IEEE 1012 process value sets

[cmungall]

Summary

• Add the 30 ISO/IEC/IEEE 15288 system life cycle processes.
• Add IEEE 1012 system, software, and hardware verification and validation processes.
• Import both value sets into the main schema.

Validation

• just site completed for the 15288 addition.
• A subsequent just site run was started after the IEEE 1012 addition but interrupted during lengthy project generation; generated artifacts were cleaned up.
• just validate was attempted but interrupted during large ontology database downloads.

[claude]

Claude finished @cmungall's task in 3m 7s —— View job

---

Review: Add systems engineering and IEEE 1012 process value sets

• Gather context (read changed files, compare to repo conventions)
• Review schema quality, metaclass contract, prefixes, content accuracy
• Check just site / just validate viability
• Post review feedback

The content is well-chosen and the 15288 list is accurate — I verified all 30 processes against the four clause-6 groups (2 agreement + 6 organizational project-enabling + 8 technical management + 14 technical = 30). Nothing is missing or invented. The issues below are about metadata completeness and the IEEE 1012 value set.

---

1. Declared metaclass contract is unmet — contributors is required (blocking-ish)

Both enums declare instantiates: valuesets_meta:ReferenceEnumDefinition (systems_engineering.yaml:17-18, verification_validation_ieee_1012.yaml:17-18). That metaclass is is_a: ValueSetEnumDefinition, which declares contributors as required: true (src/valuesets/metamodel/valuesets_meta.yaml:68-73, 84-87). Neither new enum has a contributors field.

All 9 pre-existing files in src/valuesets/schema/computing/ supply contributors:; these two are the only ones that don't. It won't fail CI today (the metamodel itself notes instantiates enforcement is currently limited), but it's a contract you're explicitly opting into and it will fail once enforcement lands.

Related: since both enums do supply source and conforms_to, ValueSetEnumDefinitionWithConformance is the more accurate metaclass — it requires exactly those two (valuesets_meta.yaml:118-133). ReferenceEnumDefinition requires neither, so the declaration under-specifies what these enums actually assert.

Fix this →

2. Zero permissible values have a description: (39/39)

Every PV carries only a title, and each title just restates the key: ACQUISITION → "Acquisition Process", SUPPLY → "Supply Process". The value sets therefore carry no semantic content beyond the labels themselves.

For comparison in the same directory: quantum.yaml has 16 PV descriptions, microelectronics.yaml 17, data_centers.yaml 12 — these two have 0. The ReferenceEnumDefinition docstring calls for "complete documentation" (valuesets_meta.yaml:181).

15288 gives a one-line purpose statement for each process that would drop in directly — e.g. DECISION_MANAGEMENT: "Provide a structured, analytical framework for identifying, characterizing and evaluating a set of alternatives for a decision at any point in the life cycle." That's what makes this value set useful to a downstream consumer rather than a list of strings.

Fix this →

3. IEEE 1012 values don't trace cleanly to the standard

conforms_to: IEEE 1012-2016 is a formal conformance claim, but the 9 values look like a paraphrase of the 1012-2004 development-phase activities rather than the 2016 edition, which was restructured around the ISO/IEC/IEEE 15288/12207 process framework. Concretely:

• Missing 1012 processes: Management of V&V, Acquisition support V&V, and Supply V&V are all V&V processes in the standard and are absent here.
• QUALIFICATION_TESTING (line 30) is the odd one out — the only value whose key and title both break the *_V_AND_V / "… Verification and Validation" pattern. 1012 uses "Test V&V"; "qualification testing" is more of a 12207/MIL term.
• INSTALLATION_AND_CHECKOUT (line 32) has title "Installation and Checkout Verification and Validation" but its key omits the _V_AND_V suffix that all 8 siblings carry. Straight key/title inconsistency.

Given CLAUDE.md's "ALWAYS check IDs, NEVER guess them" principle, it'd be worth grounding each value in a numbered clause of 1012-2016 before merging, the same way the 15288 list is grounded.

4. source: URL for IEEE 1012 is likely stale

verification_validation_ieee_1012.yaml:19 uses https://standards.ieee.org/standard/1012-2016.html. IEEE retired that URL scheme; the current form is https://standards.ieee.org/ieee/1012/5609/. I couldn't confirm — network fetches aren't permitted in this job — so please verify it resolves.

5. KNOWLEDGE_MANAGEMENT is out of clause order

systems_engineering.yaml otherwise follows the standard's clause order (6.1 agreement → 6.2 organizational → 6.3 technical management → 6.4 technical), but KNOWLEDGE_MANAGEMENT (clause 6.2.6) sits at line 52, after QUALITY_ASSURANCE (6.3.8), instead of after QUALITY_MANAGEMENT (6.2.5, line 34). Cosmetic, but the ordering is otherwise meaningful and readers will rely on it.

6. The description promises grouping that isn't encoded

Line 15 says "The 30 system life cycle processes grouped by ISO/IEC/IEEE 15288:2015", but the four process groups — the standard's primary organizing structure — aren't represented anywhere. Either encode them (a companion SystemLifeCycleProcessGroup15288 enum plus an annotation on each PV) or reword the description so it doesn't claim something the artifact doesn't deliver. Encoding them is the more valuable option: "which group does this process belong to" is a common query.

7. Minor

• Missing linkml: prefix declaration. Both files imports: linkml:types but don't declare linkml: https://w3id.org/linkml/ in prefixes:. All 9 existing computing/ files declare it. It probably resolves via LinkML's built-in defaults, but relying on that is an unnecessary implicit dependency.
• No meaning: mappings. CLAUDE.md asks for ontology mappings. There likely is no OBO coverage for 15288 process terms, so this may be legitimately unmappable — but worth a pass with the repo's pv-mapping skill to confirm rather than assume.
• Inconsistent standard-suffix naming between the two enums: SystemLifeCycleProcess15288 (bare number) vs VerificationValidationProcessIEEE1012 (org-prefixed).
• V_AND_V is awkward as a key fragment; VV or spelling it out reads better.

8. Validation gap

The PR body notes just site and just validate were both interrupted. I was unable to run them here either — the sandbox in this job blocked the shell invocations. Since valuesets.yaml now imports both files, _test-schema (gen-project over the full schema) will exercise them, so please confirm a clean run before merging. No test coverage was added, though that's consistent with how other value sets in this repo are handled.

---

Summary: the 15288 value set is accurate and useful; item 1 (missing required contributors) and item 2 (no PV descriptions) should be addressed before merge, and item 3 (IEEE 1012 provenance) deserves a check against the actual 2016 clauses. No security or performance concerns — these are declarative schema additions.

I reviewed only; no changes were pushed.
• branch process-terminology