Ontology & Evidence

Ontology is the connected map of WyrdOS. It shows how strategy, execution, documents, and evidence relate to each other. If engines and pipelines are the objects in the system, ontology is the graph that lets a person inspect whether those objects make sense together.

Operators use ontology to answer questions like:

• Why does this zone exist?
• Which goal does this container support?
• What evidence backs this claim?
• Which parts of the workspace look stale or disconnected?

Buyers should read ontology as a trust feature. It gives a visible structure for review, not only a hidden database of tasks.

The Graph Model

Ontology graphs contain nodes and edges.

The graph is intentionally operational. It is not a decorative mind map. It should help a reviewer decide whether the workspace is coherent.

Graph Modes

WyrdOS exposes ontology in several scopes:

A broad graph is useful for orientation. A focused graph is usually better for action. If the company graph feels noisy, move to a container or zone graph and inspect one operating chain at a time.

What You Can Do In The Ontology View

The ontology view lets you inspect connected context visually. The graph groups entities by type, highlights related nodes when you select or hover, and links many nodes back to their detail pages.

Useful operator actions:

• Select a node to inspect its direct neighbours.
• Open the linked entity when you need to edit the source record.
• Use warnings to find missing, stale, or weak context.
• Compare the graph against the actual operating story the team believes.
• Review evidence proposals before accepting them as trusted context.

The strongest use of ontology is review. A team can open a zone like Onboarding cleanup, see the Product container, see the related goal outcome, see the pillar, and inspect whether any evidence supports the current state.

Evidence

Evidence connects claims in WyrdOS to source material. Evidence can represent artifacts, URLs, notes, documents, or structured source payloads. It is most useful when it answers a trust question:

• Why do we believe this goal is on track?
• Which source says this customer problem is real?
• What document explains this product decision?
• When was this context last observed?

Accepted evidence should be treated as part of the operating record. It should have a clear title, summary, source metadata, confidence, and observed date where possible.

Evidence Proposals

External agents and integrations should usually create evidence proposals instead of directly creating accepted evidence. A proposal says: "This may be useful evidence, please review it." A WyrdOS user or field engineer can then approve or reject it.

That workflow matters for trust. It prevents automation from silently rewriting the operating record. It also preserves review history: rejected proposals remain visible as part of the review trail, while approved proposals create accepted evidence.

Use proposals when:

• An agent finds source material that may support a node.
• A script imports candidate context from another system.
• The confidence level is useful but not final.
• A human needs to decide whether the source belongs in the workspace.

Do not bypass proposals when the source is uncertain, duplicated, stale, or strategically sensitive.

Review Context

Review context is the machine-readable version of ontology review. It includes entities, links, warnings, current evidence, stale evidence, pending proposals, and counts. It gives agents and scripts enough context to make careful suggestions without guessing IDs or inventing relationships.

For operators, review context is useful because it mirrors the product's trust model. The API should expose the same operating graph that users can inspect in the UI. If the API says a container has missing evidence, a user should be able to find that concern in the workspace and decide what to do.

Example Workflow

For beta onboarding:

1. Open the Product container ontology graph.
2. Select Beta users understand onboarding.
3. Inspect connected pillars, containers, zones, pages, and evidence.
4. Notice a warning that the Product container lacks recent supporting evidence.
5. Have an agent propose evidence from the latest beta launch plan.
6. Review the proposal, confirm the source is correct, and approve it.
7. Revisit the graph to confirm the evidence is now part of the record.

This workflow is stronger than a task comment because it keeps the source material connected to the entity it supports.

What Good Usage Looks Like

Strong ontology usage:

• The graph tells the same story operators tell verbally.
• Important containers and goal outcomes have current source-backed evidence.
• Warnings lead to real review, not cosmetic cleanup.
• Agents propose evidence instead of silently accepting it.
• Rejected proposals are treated as useful review history.

Weak ontology usage:

• Nodes are connected only to make the graph look dense.
• Warnings are ignored until trust erodes.
• Evidence lacks source names or summaries.
• Agents create accepted evidence without human review.
• Users rely on API output that cannot be reconciled with the UI.

Trust Notes For Buyers

Ontology and evidence are the strongest buyer-facing trust story in WyrdOS. They show that work can be traced, reviewed, sourced, and challenged. They also show where the system is honest about uncertainty: warnings, stale evidence, confidence, and proposals all make the operating record more inspectable.

WyrdOS should not claim that every record is automatically true. The more defensible claim is that WyrdOS provides a structured way to connect work to strategy and evidence, then review that structure over time.

Automate This

Use these references when building evidence or graph workflows:

• Ontology API
• Evidence API
• Evidence proposals API
• Evidence workflow