Engines

Engines are the strategy layer in WyrdOS. They hold the reasons behind the work: what the organisation believes, what it is focusing on, what value it wants to create, and which outcomes prove progress. Operators use engines to make daily work easier to prioritise. Buyers should read engines as the part of WyrdOS that turns a planning tool into an auditable operating system.

An engine entry is not meant to be a slogan. It should help a person decide what to do, what to ignore, and how to explain that decision later.

The Engine Model

WyrdOS uses four engine primitives:

The normal direction is:

Principles -> Pillars -> Value goals -> Goal outcomes -> Containers

That does not mean every workspace needs a perfect hierarchy on day one. It means the best WyrdOS work eventually has a visible explanation. If a container exists, a team should be able to say which pillar or goal outcome it supports. If a goal outcome exists, a team should be able to say which principle or value goal gives it weight.

Principles

Principles are the slowest-moving part of WyrdOS. They describe how the organisation wants to make decisions even when the work changes. A principle should be specific enough to reject work, not only approve it.

For example, Decisions should leave a trail is useful because it tells a team how to behave. It encourages linked pages, evidence, and reviewable context. It also warns against private side channels where important reasoning disappears.

Use principles when:

• A team repeatedly debates the same tradeoff.
• Buyers or leaders need to understand how decisions are made.
• Operators need a rule that survives changing projects.
• You want AI agents or scripts to retrieve decision context without guessing values.

Do not create a principle for every preference. Too many principles become decorative. A good set is small enough that people remember it and strong enough that it changes behaviour.

Pillars

Pillars are the main strategic themes. They sit between high-level belief and concrete execution. A pillar such as Product clarity gives shape to a set of goals, containers, and zones without becoming a task list.

Pillars are most useful when they are few, active, and connected. If every container links to every pillar, the pillar stops clarifying anything. If no containers link to a pillar, it may be a dormant idea rather than an active strategic theme.

Use pillars to:

• Group related goals under a strategic theme.
• Compare investment across themes.
• Give containers a strategic owner or reason.
• Explain why unrelated-looking work belongs together.

For a beta launch, Product clarity might connect to a principle like Decisions should leave a trail, a goal outcome like Beta users understand onboarding, and a container like Product. That chain lets a reviewer inspect a zone and understand why the team spent time on onboarding cleanup instead of a different feature.

Value Goals

Value goals describe the kind of value the organisation wants to create. They are broader than goal outcomes and less date-driven. A value goal can connect multiple pillars, containers, and outcomes when the same value shows up across the workspace.

Use value goals when you need to track a persistent direction, such as customer self-service, operational reliability, or faster partner onboarding. They are useful for buyers because they show that WyrdOS does not only store tasks. It stores a working theory of what the organisation values.

Good value goals are outcome-shaped but not too narrow. Customers can self-serve onboarding is stronger than Write onboarding copy because many containers and actions can support it: product changes, documentation, support scripts, and evidence collection.

Goal Outcomes

Goal outcomes make strategy measurable. They carry term, target date, status, priority, and relationships to the rest of the graph. They are where a strategy becomes something a team can review.

Use goal outcomes when:

• A team needs a clear review point.
• A pillar needs measurable progress.
• A container should be evaluated against an intended result.
• You want to ask whether current work is still justified.

Goal outcomes should be concrete enough that a future reviewer can decide whether progress happened. Beta users understand onboarding by the July review is stronger than Improve onboarding because it has a target audience, subject, and review moment.

What You Can Do In WyrdOS

The Engines area gives each primitive its own index page. You can search, filter, sort, group, and change display configuration. Detail pages let you edit the main content, status, priority, relationships, and linked entities.

The Engines dashboard also supports layout modes:

The important action is relationship maintenance. A pillar should not live alone. A goal outcome should not be a disconnected note. When an operator creates or updates engine entries, they should ask which upstream and downstream links explain the entry.

Example Workflow

A team preparing a beta launch might create:

After that, the Product container can hold zones and actions. The engine entries remain above the work as context, not as extra tasks.

What Good Usage Looks Like

Good engine setup is calm and sparse. It has enough structure to explain work, but not so much structure that people spend all day maintaining the model.

Strong signs:

• Active containers link to at least one meaningful pillar or goal outcome.
• Pillars are few enough to guide tradeoffs.
• Goal outcomes have reviewable dates or terms.
• Principles are written as decision rules, not brand adjectives.
• The team can explain why a zone exists by walking upward through the graph.

Weak signs:

• Every pillar sounds important, so none of them help prioritise.
• Goals duplicate task names.
• Containers are created before anyone knows what strategic outcome they support.
• Relationships are added after the fact only to make the graph look complete.

Trust Notes For Buyers

Engines build trust because they make strategy inspectable. A buyer can look at a workspace and ask whether work is tied to stated goals, whether active themes match leadership priorities, and whether the team can defend its allocation of attention.

The trust claim is not that WyrdOS automatically makes better strategy. The claim is that WyrdOS makes strategy and execution visible in one structure. That visibility supports review, onboarding, agent context, and governance.

Automate This

Use the API and CLI when you need to inspect or export strategy context:

• Engines API
• Ontology API
• CLI engines commands
• Create a traceable workflow