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 semantic definitions, relations, rules, and model vocabulary.
Capability and requirement subgraphs — one or more independent product or system intent structures with requirements and refinements.
Verification layer — tests, proofs, analysis, inspection, and demonstration evidence linked to the capabilities or requirements they verify.
Implementation evidence — code, tests, reports, documents, and other artifacts that satisfy requirements or provide verification evidence.

Concept references bind prose to ontology terms. Attachments bring 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.

Refinement ownership

A non-semantic-contract refinement is owned by exactly one compatible requirement through refine or refinedBy. 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 refinements and verifications that prove it without becoming part of one universal hierarchy.

Concept references

Capabilities, requirements, refinements, verification objectives, and concrete verifications use concept references to bind readable labels to ontology terms.

Requirement attachments

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

Fulfillment evidence

The attachment 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, refinements, verifications, and implementation artifacts can be reviewed and hardened after changes.

One-way dependency flow

Attachment flow between capability-rooted subgraphs is one-directional. If two submodels attach contracts to 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 domain semantics, relations, rules, reusable concepts, and ontology vocabulary as first-class OWL/Turtle content.

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.

Refinement

Adds source, specification, constraint, behavior, state, and input/output detail to obligations.

Verification

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

Ontology Contracts

Ontology and semantic contracts are separate layers of meaning. Ontology defines reusable vocabulary. 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 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, refinement, or verification prose should bind labels to ontology CURIEs or 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 the same family: capability, requirement, ontology, or verification-family.
`specify / specifiedBy`	Requirement specifies a capability.
`refine / refinedBy`	Requirement owns a compatible refinement contract.
`constrain / constrainedBy`	Semantic contract constrains one or more requirements.
`use / usedBy`	Semantic contract uses ontology vocabulary.
`verify / verifiedBy`	Concrete verification records evidence scope for a capability or requirement; verification-objective is excluded.
`satisfiedBy / satisfy`	Requirement or evidence-backed verification links to implementation or proof/test evidence.
`attach`	Requirement imports a one-way non-semantic requirement-owned contract dependency.
`trace`	Soft traceability without ownership semantics.