EvoOntology in Practice

What this book helps you do

A data agent can execute a valid query and still answer the wrong business question when a metric or entity has the wrong meaning. This book makes definitions, provenance, retrieval, proposed updates, and release tests inspectable. It follows a bounded evolution loop: gather evidence from work, propose a semantic change, evaluate its impact on real questions, and admit only the revision that earns its release.

Problems this book helps you solve

• Two dashboards report different values for the same named metric.
• An agent retrieves a plausible definition with no source or valid-time context.
• A failed task is used to justify an automatic ontology rewrite.
• A semantic change fixes one query but breaks a neighboring business question.
• Lineage records data movement while the decision rule remains implicit.
• An accepted change has no rollback or historical interpretation path.

Start with a practical question

Use a focused guide for the immediate problem, then return here when you need the complete operating method.

• How do I define a metric before a data agent queries it?
• What provenance should a semantic-layer claim retain?
• How do I build an ontology from workflow evidence?
• How should a data agent retrieve definitions while working?
• When should an agent trajectory propose a semantic change?
• How do I evaluate a semantic-layer change before release?
• How do I detect drift in an evolving semantic layer?

Decisions you will be able to make

• Identify the business question and metric contract before authoring a query.
• Record semantic assertions with source, owner, scope, and valid time.
• Retrieve the relevant definition within the agent’s task boundary.
• Distinguish observed task failure from a justified semantic update.
• Evaluate candidates against paired old and new cases.
• Release, monitor, and reverse definition changes without erasing prior meaning.

Reading path

1. Chapters 1–2: Name and represent meaningStart from divergent business answers and record the definition as inspectable state.
2. Chapters 3–4: Construct and retrieveBuild from workflow evidence and supply only relevant definitions during an agent task.
3. Chapter 5: Propose bounded changesTurn trajectories into candidate edits while keeping failure evidence distinct from authority.
4. Chapter 6: Earn a releaseTest semantic regression, task quality, and transfer before admitting a revision.
5. Chapters 7–9: Operate and evaluateConnect BI workflows, detect drift, and run a companion experiment with explicit limits.

A correct query can still be the wrong answer

Revenue, active customer, and resolved case are not self-defining labels. Each may depend on a population, event time, exclusion rule, and source revision. The book starts where apparently successful data-agent runs disagree on those terms.

Change meaning with evidence

The semantic layer is treated as a versioned product. Task traces can reveal a candidate gap, but they do not authorize a new definition. The reader checks source support, evaluates old and new questions, records ownership, and keeps a path to interpret historical answers after a release.

Evidence and method

The book combines standards and documented data-engineering mechanisms with a fictional business-analysis case and a local companion experiment. It separates support for an assertion, task success, and transfer to new cases. Example definitions and evaluation results require replacement with the reader’s governed data and decision context.

Read a sample

Signal Studio does not reproduce manuscript chapters on this site. Open the Amazon listing to use Read Sample or Kindle Instant Preview

Resources

Errata

Report or review an erratum.