Reqvire Semantic Model

The semantic model is Reqvire's typed representation of engineering knowledge. It defines the element types, relations, ownership rules, semantic references, verification links, and implementation evidence that make traceability queryable and validation possible.

High-Level Structure

Reqvire is not organized as one large parent-child tree. The model is built from independent layers and subgraphs that are connected through explicit relations where the modeling rules allow them.

Ontology layer — reusable structural semantic definitions, relations, rules, and model vocabulary.
Conceptual layer — native concept-scheme and concept elements that generate SKOS thesaurus resources for terminology, taxonomy, and search.
Capability and requirement subgraphs — one or more independent product or system intent structures with requirements and contracts.
Verification layer — tests, proofs, analysis, inspection, and demonstration evidence linked to the requirements they verify.
Implementation evidence — code, tests, reports, documents, and other artifacts that satisfy requirements or provide verification evidence.

Concept references bind prose to SKOS concepts. Reused Contract Context brings reusable requirement-owned contracts into scope without forcing unrelated concerns into the same hierarchy.

Ownership Rules

Capability roots

A capability with no capability parent is a capability-rooted submodel boundary. Child capabilities use derive or derivedFrom within the capability family.

Requirement ownership

A requirement resolves to exactly one owning capability. Top-level requirements use specify; child requirements inherit ownership through requirement hierarchy.

Contract ownership

A non-semantic-contract is owned by exactly one compatible requirement through define or definedBy. Semantic contracts constrain requirements through constrain and constrainedBy.

Cross-boundary reuse

Cross-capability semantic dependencies stay explicit through concept references and semantic-contract use relations so context, review impact, and AI collection remain auditable.

Submodels and Semantic References

Capability-rooted submodels are intentionally independent. A capability can own its operational meaning, the requirements that specify it, and the contracts and verifications that prove it without becoming part of one universal hierarchy.

Concept references

Capabilities, requirements, contracts, verification objectives, and concrete verifications use concept references to bind readable labels to SKOS concepts.

Reused contract context

Requirements reuse requirement-owned contracts such as specifications, constraints, behaviors, states, and input/output definitions. The consuming requirement declares that its subgraph must fulfill the bound contract across that requirement, its child requirements, and the contracts that detail those obligations. Semantic contracts are linked through constrainedBy.

Fulfillment evidence

The contract binding creates the contract dependency; fulfillment is shown by satisfied requirements, child requirement coverage, and verifications linked to evidence. Trace and change-impact views keep that dependency visible so affected contracts, requirements, contracts, verifications, and implementation artifacts can be reviewed and hardened after changes.

One-way dependency flow

Reused contract context flow between capability-rooted subgraphs is one-directional. If two submodels reuse contracts from each other in both directions, the boundary becomes ambiguous, so validation rejects that pattern and forces the dependency direction to be explicit.

Element Types

Ontology

Defines structural domain semantics, relations, rules, and ontology vocabulary as first-class OWL/Turtle content.

Concept Scheme and Concept

Defines curated SKOS thesaurus terminology as native Markdown elements. Concept schemes and concepts generate skos:ConceptScheme, skos:Concept, labels, definitions, taxonomy, and mappings.

Capability

Describes coherent operational, product, business, regulatory, or system abilities. Stable, decomposable, and verifiable.

Requirement

Defines implementable obligations, constraints, guarantees, and behavioral expectations that specify capabilities.

Contract

Defines source, specification, constraint, behavior, state, and input/output detail for obligations.

Verification

Evidence that requirements are verified by tests, proofs, analysis, inspection, or demonstration.

Ontology Contracts

Ontology and semantic contracts are separate layers of meaning. Ontology defines reusable structural vocabulary. Native concept elements define curated SKOS terminology. Semantic contracts explicitly use ontology and constrain requirements to make obligations precise and machine-checkable.

For ontology authoring rules, examples, validation, and export commands, see Ontologies.

Ontology

Use ontology elements for reusable structural meaning: classes, properties, ranges, restrictions, labels, comments, and stable domain vocabulary. Ontology elements require one Ontology Turtle block.

Concept References

Use concept references when readable capability, requirement, contract, or verification prose should bind labels to SKOS concept IRIs without crowding the text.

Semantic Contract

Use semantic-contract for a reusable SHACL profile that constrains requirements and explicitly uses ontology. It requires Shapes and must not contain Ontology.

Relations

Relations connect elements in the model, creating traceability chains from domain meaning to obligations, verification, implementation, and evidence:

Relation	Meaning
`derivedFrom / derive`	Hierarchy inside compatible families: capability, requirement, ontology, concept-scheme/concept context, or verification-family.
`specify / specifiedBy`	Requirement specifies a capability.
`define / definedBy`	Requirement owns a compatible contract element.
`constrain / constrainedBy`	Semantic contract constrains one or more requirements.
`use / usedBy`	Semantic contract uses ontology vocabulary.
`broader / narrower`	SKOS taxonomy between native concept elements.
`related`	Associative SKOS relation between native concept elements.
`exactMatch / closeMatch`	SKOS mapping relation from a native concept to another concept or external concept IRI.
`verify / verifiedBy`	Concrete verification records evidence scope for a requirement; capability coverage is computed from verified requirements.
`satisfiedBy / satisfy`	Requirement or evidence-backed verification links to implementation or proof/test evidence.
`reuse`	Requirement imports a one-way non-semantic requirement-owned contract dependency.
`trace`	Soft traceability without ownership semantics.