Concepts
A concise map of the WyrdOS product model and where to learn each feature in depth
WyrdOS connects strategy, execution, source material, and workspace controls into one operating graph. This page is a short map. For deeper operator and buyer guidance, use the Product Guide.
The Core Chain
The simplest WyrdOS chain is:
Principle -> Pillar -> Goal outcome -> Container -> Zone -> Action
That chain answers:
- Why does this work matter? Principles, pillars, value goals, and goal outcomes.
- Where does this work live? Containers and zones.
- What needs to happen next? Actions.
- What supports the claim? Pages, documents, and evidence.
- Can the structure be reviewed? Ontology, warnings, proposals, API keys, and exports.
The graph does not need to be perfect before a team starts. It does need to become explainable. A person should be able to open an active zone and trace it upward to the strategic reason it exists.
Product Areas
| Area | What it does | Read next |
|---|---|---|
| Engines | Holds the strategy layer: principles, pillars, value goals, and goal outcomes. | Engines |
| Pipelines | Organises execution through containers, zones, actions, dates, status, and priority. | Pipelines |
| Ontology & Evidence | Shows the operating graph, warnings, evidence, proposals, and review context. | Ontology & Evidence |
| Pages & Documents | Preserves decisions, notes, container-linked pages, master documents, and templates. | Pages & Documents |
| Directory & Workspace Admin | Tracks tools, contacts, funding, settings, categories, API keys, imports, and exports. | Directory & Workspace Admin |
How The Pieces Fit Together
Engines should stay small enough to guide tradeoffs. Pipelines should stay concrete enough to drive work. Pages and documents should explain decisions that fields cannot capture. Ontology should reveal whether the structure is coherent. Admin controls should make access, automation, and data movement reviewable.
For beta onboarding, the model might look like this:
| Layer | Example | Purpose |
|---|---|---|
| Principle | Decisions should leave a trail | Sets a decision rule. |
| Pillar | Product clarity | Names the strategic theme. |
| Goal outcome | Beta users understand onboarding | Makes the theme reviewable. |
| Container | Product | Owns the work area. |
| Zone | Onboarding cleanup | Focuses the current effort. |
| Action | Document onboarding blockers | Makes the next step executable. |
| Page | Beta onboarding review | Preserves decision context. |
| Evidence proposal | Launch plan source | Lets a human approve source-backed context. |
What Good Setup Looks Like
Good WyrdOS setup is not measured by how many entries exist. It is measured by whether the entries help people explain and operate the work.
Healthy signals:
- Active containers link to meaningful strategic context.
- Active zones have containers, dates, and reviewable purpose.
- Actions are small enough to complete and review.
- Important decisions live in linked pages or documents.
- Evidence is sourced, reviewed, and not silently accepted by agents.
- Categories, templates, and API keys are managed intentionally.
Warning signals:
- Pillars are too vague to guide decisions.
- Containers are used for tiny tasks.
- Zones have no owner, date, or strategic link.
- Pages become an unlinked archive.
- Evidence lacks source metadata.
- API keys are broader than the workflow requires.
Where To Go Next
- Start with the Start Guide if you have not created a traceable path yet.
- Read Engines if the strategy model is unclear.
- Read Pipelines if containers, zones, or actions are unclear.
- Read Ontology & Evidence if you are evaluating trust, reviewability, or agent workflows.
All rights reserved.