Skip to content
ThinkWork ThinkWork

Business Ontology

Business ontology is the governed vocabulary that sits between raw memory and the shared compiled-memory layer. It answers a different question from Hindsight and compiled pages:

  • Hindsight is memory. It keeps retained observations, preferences, events, and source facts.
  • Ontology is meaning. It defines the tenant’s business types, relationship language, facet templates, and optional standards mappings.
  • Brain pages are the materialized view. They are rebuilt from memory using the approved ontology, with provenance back to the facts that supported each section.

The ontology layer exists because “compile memory into a wiki” is too loose by itself. Without a governed vocabulary, the same corpus can produce pages called Account, Customer, Client, Prospect, and Company with overlapping sections and unclear relationships. Ontology Studio gives operators a review loop before those concepts become durable structure.

What the ontology owns

Section titled “What the ontology owns”

The first version is intentionally a business/domain ontology, not an agent-work ontology. Agent workflows, task events, and Symphony ETL can reuse the same change-set pattern later, but this layer is scoped to customer, opportunity, commitment, risk, product, person, and similar business concepts in the Memory.

It owns four definition families:

FamilyPurpose
Entity typesCanonical business objects such as customer, opportunity, person, or product.
Relationship typesNamed links between entity types such as owns, champions, blocks, or committed_to.
Facet templatesSection templates that tell Brain materialization what an entity page should contain and which sources have priority.
External mappingsOptional mappings from ThinkWork-native concepts to outside vocabularies.

Entity and relationship definitions have lifecycle state: PROPOSED, APPROVED, DEPRECATED, or REJECTED. Only approved definitions drive Brain materialization and Context Engine retrieval.

Suggestion loop

Section titled “Suggestion loop”

Ontology suggestions are evidence-backed change sets. A scan looks across existing Brain signals and available source references, groups recurring patterns, and proposes one or more change sets.

Each change set records:

  • a title, summary, confidence, observed frequency, and expected impact;
  • line items for entity types, relationship types, facet templates, and mappings;
  • evidence examples with source labels, quotes, metadata, and observation timestamps;
  • item-level status so weak items can be removed or held while stronger items move forward.

Operators review the proposal in Admin under Manage → Ontology. They can edit names, guidance, JSON payloads, mappings, and templates before approval. Approval is the governance point: it creates or updates the approved ontology definitions and queues one asynchronous reprocess job.

Change-set lifecycle

Section titled “Change-set lifecycle”

Change sets move through a small state machine:

StatusMeaning
DRAFTThe suggestion engine or an operator created the proposal, but it is not ready for review.
PENDING_REVIEWThe proposal is ready for an admin decision.
APPROVEDAn admin approved the proposal and an ontology version/reprocess job has been queued.
APPLIEDReprocessing applied the approved definitions to the tenant Brain.
REJECTEDAn admin rejected the proposal; it no longer participates in materialization.

Approval and application are separate on purpose. The ontology version can be approved while the reprocess job is still pending, running, or failed. That separation makes partial rollout visible instead of hiding it behind a single “save” action.

Reprocess behavior

Section titled “Reprocess behavior”

When a change set is approved, ThinkWork queues an ontology reprocess job. The job:

  1. applies the approved definition changes into the tenant ontology tables;
  2. resolves approved facet templates for each affected entity type;
  3. materializes tenant-shared Brain pages and sections from cited source material;
  4. preserves higher-trust existing sections when source evidence is not strong enough to replace them;
  5. records impact, metrics, errors, and final status on the job row.

This is how approved ontology changes affect both future and past Brain materialization. Future compiles use the approved templates. Reprocess also revisits existing materialized business pages so operators do not have to wait for new memory to drift the corpus into the new shape.

The current owner-scoped compiled wiki remains compatible with existing page/link behavior. The business ontology adds a tenant-shared Brain substrate on top of those memories; it does not turn every wiki link into an RDF triple or force every agent page to share a global slug.

Standards mapping stance

Section titled “Standards mapping stance”

ThinkWork stores standards mappings as metadata, not as the canonical product model.

Good mappings help interoperability:

  • customer can have a broad mapping to Schema.org Organization;
  • a relationship can carry an external URI without renaming the ThinkWork predicate;
  • mapping kinds use SKOS-style semantics: EXACT, CLOSE, BROAD, NARROW, and RELATED;
  • provenance metadata follows the spirit of PROV-O: source kind, source reference, source label, observed time, and evidence quote;
  • definition metadata can carry Dublin Core-style labels, descriptions, and lifecycle timestamps.

The product rule is: conform where it helps, never contort the tenant vocabulary to satisfy a generic ontology. Operators should see ThinkWork-native business language first, with standards mappings available for integration and export.

Where agents consume it

Section titled “Where agents consume it”

Agents do not call ontology admin APIs directly. They consume the approved ontology through Memory:

  • the Brain Context provider returns tenant-shared, ontology-shaped entity pages and facets;
  • the split query_brain_context tool searches business/domain context such as customers, commitments, risks, relationships, and cited provenance;
  • normal memory lookup still goes through Hindsight-backed memory tools or the memory Context Engine provider;
  • compiled wiki pages remain available as the wiki provider for owner-scoped page lookup.

This keeps ontology governance in Admin while letting agents benefit from the approved vocabulary at retrieval time.

Section titled “Related pages”