Build your engineering tool
Start with a workflow your team wants to improve. For example: track a hardware change from the affected part to its requirements, verification evidence and delivery work.
1. Describe the workflow
Section titled “1. Describe the workflow”Write down the questions people need to answer and the changes they need to make:
- Which requirements does this part satisfy?
- What evidence verifies them?
- Which risks remain open?
- What work must finish before the part is ready?
This gives the model a purpose before you choose its fields.
2. Define the vocabulary
Section titled “2. Define the vocabulary”Describe object types such as Part, Requirement, Verification, Risk and Work Item. Give each type the properties it needs.
Define relationships for the connections: a part satisfies a requirement; a verification checks it; a work item addresses a risk. Relationships make those connections traversable.
Understand objects, relationships and types.
3. Shape the views
Section titled “3. Shape the views”Choose how people inspect and edit the model. A requirements table, a product tree and a part’s detail view can all show connected objects.
The type’s view configuration controls its presentation. Use views and configuration to connect your model to the interface.
4. Iterate with an agent
Section titled “4. Iterate with an agent”Ask the ontology agent to help draft your type definitions and configuration. Inspect and validate the proposed change set before accepting it.
For workflows that need code, a coding agent can use the CLI and SDK. It discovers and changes the same platform objects.
5. Try a real engineering change
Section titled “5. Try a real engineering change”Create representative data, then branch it and try one change through the whole workflow. Compare what changed and merge what your team accepts.
Engineering data branches. Published type definitions and workspace administration have their own lifecycle; changing a data branch does not create a separate ontology.