Objects, relationships and types
The engineering model is a graph of objects and relationships. A type defines what each kind of record means and what it can contain.
Objects
Section titled “Objects”An object represents something your programme cares about: a part, requirement, verification, supplier, risk or work item.
Each object has an identity and belongs to a project. Its type defines its properties. The same object can appear in several views without becoming several records.
Relationships
Section titled “Relationships”A relationship connects two objects. It can express structure, traceability or provenance: a subsystem contains a component; a part satisfies a requirement; a verification checks it.
Model connections as relationships so the platform can follow them, validate their endpoints and apply their access rules.
A navigation tree is one interpretation of the relationships declared by a type. The graph can contain connections that do not appear in that tree.
Demo World in Explore: relationship arrows connect different object types. Verifications verify requirements, specifications satisfy them, and Systems hold them. Open full-size screenshot.
Types and ontology
Section titled “Types and ontology”An object type defines its properties, required values and presentation. A relationship type defines what it connects and how that connection is labelled. Typed actions describe operations over the model.
For example, a typed action might record a verification result from a method, outcome and evidence reference. Its definition controls the accepted input; the platform checks the caller and the action’s effects. This is a model author’s example, rather than a bundled Demo World action.
Together, these definitions form your ontology: the vocabulary and rules your engineering tools share.
The published catalogue is versioned. Type changes are drafted and validated before publication. Published versions remain available so older engineering data can resolve its definitions. Publishing a new definition does not bulk-rewrite every existing record. Reads retain the object’s stored type-version identity; operations that carry a type version must use the current published version and meet its validation rules. Plan changes to fields alongside the data updates your workflow needs.
Projects and organisations
Section titled “Projects and organisations”An organisation shares a type catalogue. Projects hold engineering objects and access grants. A session works in one active organisation.
Objects can connect across projects where the relationship and permissions allow it. A connection does not grant access to the far object’s properties. Access and permissions explains who can edit data, publish types and grant access.
Many views of the same data
Section titled “Many views of the same data”A Product Lifecycle Management view can focus on parts and structure. A requirements view can focus on traceability. A project view can focus on work and delivery. Their relationships let people follow a question across those boundaries.