# Build your engineering tool

Turn a programme workflow into types, relationships and views on the shared platform.

Source: https://docs.openeng.io/get-started/build-your-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

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

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](https://docs.openeng.io/concepts/connected-model.md).

## 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](https://docs.openeng.io/concepts/views.md) to connect your model to the interface.

## 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](https://docs.openeng.io/developers/overview.md). It discovers and changes the same platform objects.

## 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.