The Doctrine of Intelligence Engines

A First-Principles Engineering Reference for Building General AI Systems

This handbook is written for engineers who already understand the basic idea of modern AI systems: models produce outputs, tools extend capabilities, and applications wrap those capabilities into user experiences. The purpose here is to explain the architecture underneath that surface. An Intelligence Engine is not a prompt, a model, an agent loop, or a workflow. It is the governed runtime that turns intent into useful, observable, and controllable action.

The handbook is organized as a connected map. Each part introduces a subsystem or architectural discipline, and each chapter defines one concept in that subsystem: what it is, why it exists, how it connects to the neighboring ideas, how it should influence implementation, and how it fails when ignored.

Core Architecture

flowchart LR
  U[User or Upstream System] --> I[Intent Understanding]
  I --> G[Goals and Constraints]
  G --> P[Planning]
  P --> C[Context Engineering]
  C --> K[Knowledge and Retrieval]
  C --> M[Memory]
  P --> MG[Model Gateway]
  MG --> R[Reasoning and Decision]
  R --> POL[Policy and Safety]
  POL --> T[Tools and Workflows]
  T --> E[Evaluation]
  E --> O[Observability]
  E --> M
  O --> P

PART I - FOUNDATIONS OF INTELLIGENCE

This part establishes the language of the handbook. It moves from the meaning of intelligence to the system shape required to engineer it.

Read these chapters as the conceptual base: they explain why a model is not an engine, why agents and workflows are partial patterns, and why infrastructure around intelligence becomes unavoidable.

1. What is Intelligence?

Intelligence is the use of information to select actions that advance goals under uncertainty. In engineering terms, it is a control loop: observe, represent, decide, act, evaluate, and update.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Information vs Knowledge vs Reasoning vs Intelligence vs Wisdom”. The point is conceptual clarity before system design.

For What is Intelligence?, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for What is Intelligence?: conceptual blur causes the team to solve the wrong architectural problem.

2. Information vs Knowledge vs Reasoning vs Intelligence vs Wisdom

Information is raw signal; knowledge is information organized for use; reasoning transforms knowledge into conclusions; intelligence connects conclusions to action; wisdom governs which goals deserve pursuit.

It connects to the surrounding material by taking the output of “What is Intelligence?” and preparing the ground for “What is an AI Engine?”. The point is conceptual clarity before system design.

For Information vs Knowledge vs Reasoning vs Intelligence vs Wisdom, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for Information vs Knowledge vs Reasoning vs Intelligence vs Wisdom: conceptual blur causes the team to solve the wrong architectural problem.

3. What is an AI Engine?

An AI Engine is the runtime that turns intent into governed action by coordinating models, memory, context, retrieval, planning, tools, policy, evaluation, observability, and learning.

It connects to the surrounding material by taking the output of “Information vs Knowledge vs Reasoning vs Intelligence vs Wisdom” and preparing the ground for “AI Engine vs LLM vs Agent vs Workflow vs Application”. The point is conceptual clarity before system design.

For What is an AI Engine?, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for What is an AI Engine?: conceptual blur causes the team to solve the wrong architectural problem.

4. AI Engine vs LLM vs Agent vs Workflow vs Application

An LLM is a capability provider, an agent is an adaptive control pattern, a workflow is a known process, an application is a product surface, and an AI Engine is the substrate that governs them.

It connects to the surrounding material by taking the output of “What is an AI Engine?” and preparing the ground for “History of Intelligence Systems”. The point is conceptual clarity before system design.

For AI Engine vs LLM vs Agent vs Workflow vs Application, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for AI Engine vs LLM vs Agent vs Workflow vs Application: conceptual blur causes the team to solve the wrong architectural problem.

5. History of Intelligence Systems

The history of intelligence systems is a movement across rules, search, planning, statistics, learned representations, workflows, and organizational process. Each stage kept useful ideas and exposed new limits.

It connects to the surrounding material by taking the output of “AI Engine vs LLM vs Agent vs Workflow vs Application” and preparing the ground for “Evolution of AI Architectures”. The point is conceptual clarity before system design.

For History of Intelligence Systems, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for History of Intelligence Systems: conceptual blur causes the team to solve the wrong architectural problem.

6. Evolution of AI Architectures

AI architecture evolved from rule systems to learned models, retrieval augmentation, tool use, agents, orchestration, and finally engine-level platforms around replaceable capabilities.

It connects to the surrounding material by taking the output of “History of Intelligence Systems” and preparing the ground for “First Principles of AI Engineering”. The point is conceptual clarity before system design.

For Evolution of AI Architectures, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for Evolution of AI Architectures: conceptual blur causes the team to solve the wrong architectural problem.

7. First Principles of AI Engineering

AI engineering begins with uncertainty: ambiguous intent, incomplete context, probabilistic outputs, unreliable tools, changing knowledge, and consequential action.

It connects to the surrounding material by taking the output of “Evolution of AI Architectures” and preparing the ground for “The Philosophy of Intelligence Engines”. The point is conceptual clarity before system design.

For First Principles of AI Engineering, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for First Principles of AI Engineering: conceptual blur causes the team to solve the wrong architectural problem.

8. The Philosophy of Intelligence Engines

The philosophy is bounded agency: enough capability to pursue goals, enough structure to remain accountable, observable, interruptible, and safe.

It connects to the surrounding material by taking the output of “First Principles of AI Engineering” and preparing the ground for “Architectural Laws of AI Systems”. The point is conceptual clarity before system design.

For The Philosophy of Intelligence Engines, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for The Philosophy of Intelligence Engines: conceptual blur causes the team to solve the wrong architectural problem.

9. Architectural Laws of AI Systems

Architectural laws are invariants: explicit goals, selected context, governed memory, sourced knowledge, permissioned tools, observable execution, evaluated outcomes, and replaceable models.

It connects to the surrounding material by taking the output of “The Philosophy of Intelligence Engines” and preparing the ground for “The Future of Intelligence Infrastructure”. The point is conceptual clarity before system design.

For Architectural Laws of AI Systems, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for Architectural Laws of AI Systems: conceptual blur causes the team to solve the wrong architectural problem.

10. The Future of Intelligence Infrastructure

The future is intelligence infrastructure: model gateways, context services, memory systems, retrieval planes, tool runtimes, policy engines, evaluators, trace stores, and human approval layers.

It connects to the surrounding material by taking the output of “Architectural Laws of AI Systems” and preparing the ground for the next design decision. The point is conceptual clarity before system design.

For The Future of Intelligence Infrastructure, implementation should turn the concept into vocabulary used in diagrams, contracts, reviews, and telemetry.

Failure mode for The Future of Intelligence Infrastructure: conceptual blur causes the team to solve the wrong architectural problem.

PART II - DESIGN PRINCIPLES

This part turns the foundation into design discipline. Principles here are not slogans; they are rules that should change interfaces, tests, and reviews.

The sequence moves from separation and composition to observability, failure design, extensibility, evolution, and invariants. Together they prevent the engine from collapsing into a pile of prompts.

11. Separation of Concerns

Separation of Concerns assigns each major responsibility to a clear owner and interface so changes do not ripple through the whole engine.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Composition over Complexity”. The point is to turn taste into enforceable engineering discipline.

Implementation for Separation of Concerns: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Separation of Concerns: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

12. Composition over Complexity

Composition over Complexity builds intelligent behavior from smaller capabilities with clear contracts instead of one opaque mega-component.

It connects to the surrounding material by taking the output of “Separation of Concerns” and preparing the ground for “Deterministic Orchestration”. The point is to turn taste into enforceable engineering discipline.

Implementation for Composition over Complexity: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Composition over Complexity: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

13. Deterministic Orchestration

Deterministic Orchestration keeps control flow in software while allowing models to operate inside bounded decision points.

It connects to the surrounding material by taking the output of “Composition over Complexity” and preparing the ground for “Model Independence”. The point is to turn taste into enforceable engineering discipline.

Implementation for Deterministic Orchestration: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Deterministic Orchestration: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

14. Model Independence

Model Independence means the engine depends on capability contracts rather than one model, vendor, or response style.

It connects to the surrounding material by taking the output of “Deterministic Orchestration” and preparing the ground for “Capability Independence”. The point is to turn taste into enforceable engineering discipline.

Implementation for Model Independence: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Model Independence: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

15. Capability Independence

Capability Independence separates what the engine needs from the provider that happens to supply it today.

It connects to the surrounding material by taking the output of “Model Independence” and preparing the ground for “Observable Systems”. The point is to turn taste into enforceable engineering discipline.

Implementation for Capability Independence: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Capability Independence: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

16. Observable Systems

Observable Systems expose enough internal state and trace data to reconstruct why the engine behaved as it did.

It connects to the surrounding material by taking the output of “Capability Independence” and preparing the ground for “Failure-Oriented Design”. The point is to turn taste into enforceable engineering discipline.

Implementation for Observable Systems: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Observable Systems: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

17. Failure-Oriented Design

Failure-Oriented Design assumes ambiguity, dependency failure, invalid outputs, unsafe requests, and partial completion from the beginning.

It connects to the surrounding material by taking the output of “Observable Systems” and preparing the ground for “Progressive Intelligence”. The point is to turn taste into enforceable engineering discipline.

Implementation for Failure-Oriented Design: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Failure-Oriented Design: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

18. Progressive Intelligence

Progressive Intelligence spends reasoning effort in stages, escalating only when ambiguity, risk, or complexity demands it.

It connects to the surrounding material by taking the output of “Failure-Oriented Design” and preparing the ground for “Event-Driven Architectures”. The point is to turn taste into enforceable engineering discipline.

Implementation for Progressive Intelligence: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Progressive Intelligence: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

19. Event-Driven Architectures

Event-Driven Architectures represent important changes as events so long-running intelligent work can continue asynchronously.

It connects to the surrounding material by taking the output of “Progressive Intelligence” and preparing the ground for “Extensibility”. The point is to turn taste into enforceable engineering discipline.

Implementation for Event-Driven Architectures: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Event-Driven Architectures: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

20. Extensibility

Extensibility allows new models, tools, policies, workflows, and evaluators to enter through governed contracts.

It connects to the surrounding material by taking the output of “Event-Driven Architectures” and preparing the ground for “Evolutionary Architecture”. The point is to turn taste into enforceable engineering discipline.

Implementation for Extensibility: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Extensibility: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

21. Evolutionary Architecture

Evolutionary Architecture makes future change cheap through versioning, compatibility, migration, and deprecation paths.

It connects to the surrounding material by taking the output of “Extensibility” and preparing the ground for “Architectural Invariants”. The point is to turn taste into enforceable engineering discipline.

Implementation for Evolutionary Architecture: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Evolutionary Architecture: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

22. Architectural Invariants

Architectural Invariants are rules that remain true across implementations, such as untrusted content never becoming authority.

It connects to the surrounding material by taking the output of “Evolutionary Architecture” and preparing the ground for “Engineering Principles”. The point is to turn taste into enforceable engineering discipline.

Implementation for Architectural Invariants: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Architectural Invariants: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

23. Engineering Principles

Engineering Principles convert hard-won failure lessons into repeatable design constraints.

It connects to the surrounding material by taking the output of “Architectural Invariants” and preparing the ground for the next design decision. The point is to turn taste into enforceable engineering discipline.

Implementation for Engineering Principles: turn the principle into a concrete review question, interface, test, or guardrail so it changes engineering behavior rather than remaining advice.

Failure mode for Engineering Principles: the principle becomes a slogan and does not affect interfaces, tests, or reviews.

PART III - SYSTEM ARCHITECTURE

This part defines the major boundaries of an Intelligence Engine. Architecture here means ownership of state, data, authority, execution, services, capabilities, and deployment.

The chapters should be read as a boundary map. Each boundary exists because something must not leak freely across the system.

24. Macro Architecture

Macro Architecture describes the whole engine shape and how major subsystems relate.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Micro Architecture”. The point is to prevent hidden coupling across system boundaries.

For Macro Architecture, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Macro Architecture: boundaries erode until data, state, authority, and execution leak across components.

25. Micro Architecture

Micro Architecture describes the inside of a component: interfaces, state, algorithms, errors, tests, and extension points.

It connects to the surrounding material by taking the output of “Macro Architecture” and preparing the ground for “Layered Architecture”. The point is to prevent hidden coupling across system boundaries.

For Micro Architecture, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Micro Architecture: boundaries erode until data, state, authority, and execution leak across components.

26. Layered Architecture

Layered Architecture orders responsibilities so interface, domain logic, orchestration, and infrastructure do not collapse.

It connects to the surrounding material by taking the output of “Micro Architecture” and preparing the ground for “Hexagonal Architecture”. The point is to prevent hidden coupling across system boundaries.

For Layered Architecture, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Layered Architecture: boundaries erode until data, state, authority, and execution leak across components.

27. Hexagonal Architecture

Hexagonal Architecture places engine logic at the center and connects external systems through ports and adapters.

It connects to the surrounding material by taking the output of “Layered Architecture” and preparing the ground for “Service Boundaries”. The point is to prevent hidden coupling across system boundaries.

For Hexagonal Architecture, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Hexagonal Architecture: boundaries erode until data, state, authority, and execution leak across components.

28. Service Boundaries

Service Boundaries decide which responsibilities become separately deployable services.

It connects to the surrounding material by taking the output of “Hexagonal Architecture” and preparing the ground for “Execution Boundaries”. The point is to prevent hidden coupling across system boundaries.

For Service Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Service Boundaries: boundaries erode until data, state, authority, and execution leak across components.

29. Execution Boundaries

Execution Boundaries define where code, models, tools, and workflows are allowed to run.

It connects to the surrounding material by taking the output of “Service Boundaries” and preparing the ground for “Data Boundaries”. The point is to prevent hidden coupling across system boundaries.

For Execution Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Execution Boundaries: boundaries erode until data, state, authority, and execution leak across components.

30. Data Boundaries

Data Boundaries define where information may move between users, tenants, prompts, tools, logs, memories, and outputs.

It connects to the surrounding material by taking the output of “Execution Boundaries” and preparing the ground for “Security Boundaries”. The point is to prevent hidden coupling across system boundaries.

For Data Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Data Boundaries: boundaries erode until data, state, authority, and execution leak across components.

31. Security Boundaries

Security Boundaries separate trust zones for identity, secrets, untrusted content, and privileged tools.

It connects to the surrounding material by taking the output of “Data Boundaries” and preparing the ground for “State Boundaries”. The point is to prevent hidden coupling across system boundaries.

For Security Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Security Boundaries: boundaries erode until data, state, authority, and execution leak across components.

32. State Boundaries

State Boundaries distinguish request state, session state, workflow state, user memory, organizational memory, and audit state.

It connects to the surrounding material by taking the output of “Security Boundaries” and preparing the ground for “Capability Boundaries”. The point is to prevent hidden coupling across system boundaries.

For State Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for State Boundaries: boundaries erode until data, state, authority, and execution leak across components.

33. Capability Boundaries

Capability Boundaries define what the engine can do and through which governed interface.

It connects to the surrounding material by taking the output of “State Boundaries” and preparing the ground for “Deployment Architecture”. The point is to prevent hidden coupling across system boundaries.

For Capability Boundaries, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Capability Boundaries: boundaries erode until data, state, authority, and execution leak across components.

34. Deployment Architecture

Deployment Architecture maps responsibilities to services, regions, stores, queues, processes, and trust zones.

It connects to the surrounding material by taking the output of “Capability Boundaries” and preparing the ground for the next design decision. The point is to prevent hidden coupling across system boundaries.

For Deployment Architecture, implementation should define inputs, outputs, invariants, data ownership, permission rules, dependencies, and trace events.

Failure mode for Deployment Architecture: boundaries erode until data, state, authority, and execution leak across components.

PART IV - RUNTIME

This part explains how intelligent work actually runs. A plan is not production behavior until a runtime can schedule it, pause it, recover it, and observe it.

The runtime chapters form the operational spine: graphs, states, concurrency, distribution, resources, checkpoints, cancellation, recovery, and degradation.

35. Execution Runtime

Execution Runtime is the machinery that runs tasks, tracks state, invokes capabilities, and turns plans into behavior.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Lifecycle Management”. The point is to make execution durable instead of conversationally fragile.

For Execution Runtime, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Execution Runtime: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

36. Lifecycle Management

Lifecycle Management defines how a task is created, initialized, executed, paused, resumed, completed, failed, archived, or deleted.

It connects to the surrounding material by taking the output of “Execution Runtime” and preparing the ground for “Execution Graphs”. The point is to make execution durable instead of conversationally fragile.

For Lifecycle Management, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Lifecycle Management: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

37. Execution Graphs

Execution Graphs represent work as nodes and edges so dependencies and parallelism can be reasoned about.

It connects to the surrounding material by taking the output of “Lifecycle Management” and preparing the ground for “State Machines”. The point is to make execution durable instead of conversationally fragile.

For Execution Graphs, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Execution Graphs: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

38. State Machines

State Machines represent execution as states, events, guards, and transitions.

It connects to the surrounding material by taking the output of “Execution Graphs” and preparing the ground for “Scheduling”. The point is to make execution durable instead of conversationally fragile.

For State Machines, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for State Machines: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

39. Scheduling

For 39. Scheduling: scheduling chooses what work runs next under priorities, dependencies, deadlines, fairness, and resource limits.

It connects to the surrounding material by taking the output of “State Machines” and preparing the ground for “Concurrency”. The point is to make execution durable instead of conversationally fragile.

For Scheduling, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Scheduling: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

40. Concurrency

Concurrency lets multiple operations make progress at overlapping times while preserving correctness.

It connects to the surrounding material by taking the output of “Scheduling” and preparing the ground for “Parallel Execution”. The point is to make execution durable instead of conversationally fragile.

For Concurrency, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Concurrency: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

41. Parallel Execution

Parallel Execution runs independent operations simultaneously when dependencies allow it.

It connects to the surrounding material by taking the output of “Concurrency” and preparing the ground for “Distributed Execution”. The point is to make execution durable instead of conversationally fragile.

For Parallel Execution, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Parallel Execution: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

42. Distributed Execution

Distributed Execution spreads work across services or machines for scale, isolation, and resilience.

It connects to the surrounding material by taking the output of “Parallel Execution” and preparing the ground for “Resource Allocation”. The point is to make execution durable instead of conversationally fragile.

For Distributed Execution, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Distributed Execution: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

43. Resource Allocation

Resource Allocation decides how compute, model budget, context, memory, tools, and human attention are spent.

It connects to the surrounding material by taking the output of “Distributed Execution” and preparing the ground for “Checkpointing”. The point is to make execution durable instead of conversationally fragile.

For Resource Allocation, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Resource Allocation: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

44. Checkpointing

Checkpointing records enough state to resume or reconcile work after interruption.

It connects to the surrounding material by taking the output of “Resource Allocation” and preparing the ground for “Cancellation”. The point is to make execution durable instead of conversationally fragile.

Implementation should store goal, plan, current state, completed steps, side effects, tool outputs, open risks, and trace ID.

Failure mode for Checkpointing: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

45. Cancellation

Cancellation intentionally stops work and leaves the system in a known state.

It connects to the surrounding material by taking the output of “Checkpointing” and preparing the ground for “Recovery”. The point is to make execution durable instead of conversationally fragile.

For Cancellation, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Cancellation: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

46. Recovery

For 46. Recovery: recovery restores useful progress after failure using checkpoints, idempotency, reconciliation, and safe fallbacks.

It connects to the surrounding material by taking the output of “Cancellation” and preparing the ground for “Graceful Degradation”. The point is to make execution durable instead of conversationally fragile.

For Recovery, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Recovery: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

47. Graceful Degradation

Graceful Degradation returns a reduced but safe behavior when ideal execution is unavailable.

It connects to the surrounding material by taking the output of “Recovery” and preparing the ground for the next design decision. The point is to make execution durable instead of conversationally fragile.

For Graceful Degradation, implementation should use durable task records, events, timeouts, retries, leases, terminal states, and recovery paths.

Failure mode for Graceful Degradation: work is lost, duplicated, or left ambiguous after interruption, timeout, or restart.

PART V - INTENT UNDERSTANDING

This part translates requests into work. A user gives compressed intent; the engine must expand it into goals, constraints, ambiguity, objectives, and success criteria.

The chapters are ordered to prevent confident wrong execution: understand first, plan second, act third.

48. Intent Recognition

Intent Recognition identifies what kind of work the request is asking the engine to perform.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Goal Extraction”. The point is to prevent the engine from solving the wrong problem.

For Intent Recognition, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Intent Recognition: the engine follows the literal words while missing the real objective.

49. Goal Extraction

Goal Extraction turns a request into the outcome the user or upstream system wants.

It connects to the surrounding material by taking the output of “Intent Recognition” and preparing the ground for “Constraint Extraction”. The point is to prevent the engine from solving the wrong problem.

For Goal Extraction, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Goal Extraction: the engine follows the literal words while missing the real objective.

50. Constraint Extraction

Constraint Extraction identifies limits such as budget, deadline, format, policy, permission, and forbidden action.

It connects to the surrounding material by taking the output of “Goal Extraction” and preparing the ground for “Requirement Analysis”. The point is to prevent the engine from solving the wrong problem.

For Constraint Extraction, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Constraint Extraction: the engine follows the literal words while missing the real objective.

51. Requirement Analysis

Requirement Analysis makes implicit expectations explicit enough to plan and verify.

It connects to the surrounding material by taking the output of “Constraint Extraction” and preparing the ground for “Ambiguity Detection”. The point is to prevent the engine from solving the wrong problem.

For Requirement Analysis, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Requirement Analysis: the engine follows the literal words while missing the real objective.

52. Ambiguity Detection

Ambiguity Detection finds missing or multi-meaning details that affect correctness, safety, or cost.

It connects to the surrounding material by taking the output of “Requirement Analysis” and preparing the ground for “Objective Modeling”. The point is to prevent the engine from solving the wrong problem.

For Ambiguity Detection, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Ambiguity Detection: the engine follows the literal words while missing the real objective.

53. Objective Modeling

Objective Modeling represents goals in a form that can be planned, optimized, monitored, and evaluated.

It connects to the surrounding material by taking the output of “Ambiguity Detection” and preparing the ground for “Goal Hierarchies”. The point is to prevent the engine from solving the wrong problem.

For Objective Modeling, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Objective Modeling: the engine follows the literal words while missing the real objective.

54. Goal Hierarchies

Goal Hierarchies decompose objectives into subgoals while preserving the top-level purpose.

It connects to the surrounding material by taking the output of “Objective Modeling” and preparing the ground for “Success Criteria”. The point is to prevent the engine from solving the wrong problem.

For Goal Hierarchies, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Goal Hierarchies: the engine follows the literal words while missing the real objective.

55. Success Criteria

Success Criteria define how the engine knows the task is complete and acceptable.

It connects to the surrounding material by taking the output of “Goal Hierarchies” and preparing the ground for the next design decision. The point is to prevent the engine from solving the wrong problem.

For Success Criteria, implementation should emit structured intent: goal, constraints, assumptions, ambiguity, required context, and success criteria.

Failure mode for Success Criteria: the engine follows the literal words while missing the real objective.

PART VI - PLANNING

This part treats planning as search control. The engine must choose a path through possible actions while managing tools, knowledge, budget, and risk.

The arc moves from theory to decomposition, adaptation, execution planning, and replanning. A plan is a living hypothesis.

56. Planning Theory

Planning Theory treats work as search through possible action sequences under uncertainty and constraints.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Task Decomposition”. The point is to control search before action consumes resources.

For Planning Theory, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Planning Theory: the engine either thrashes without a plan or follows a stale plan after reality changes.

57. Task Decomposition

Task Decomposition breaks a goal into smaller units that can be scheduled, delegated, verified, and retried.

It connects to the surrounding material by taking the output of “Planning Theory” and preparing the ground for “Hierarchical Planning”. The point is to control search before action consumes resources.

For Task Decomposition, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Task Decomposition: the engine either thrashes without a plan or follows a stale plan after reality changes.

58. Hierarchical Planning

Hierarchical Planning organizes work into strategy, milestones, tasks, and actions.

It connects to the surrounding material by taking the output of “Task Decomposition” and preparing the ground for “Dynamic Planning”. The point is to control search before action consumes resources.

For Hierarchical Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Hierarchical Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

59. Dynamic Planning

Dynamic Planning updates the plan when new information changes the path.

It connects to the surrounding material by taking the output of “Hierarchical Planning” and preparing the ground for “Reactive Planning”. The point is to control search before action consumes resources.

For Dynamic Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Dynamic Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

60. Reactive Planning

Reactive Planning lets the engine respond quickly to events without recomputing the whole strategy.

It connects to the surrounding material by taking the output of “Dynamic Planning” and preparing the ground for “Adaptive Planning”. The point is to control search before action consumes resources.

For Reactive Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Reactive Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

61. Adaptive Planning

Adaptive Planning changes strategy when evidence shows the current approach is weak.

It connects to the surrounding material by taking the output of “Reactive Planning” and preparing the ground for “Execution Planning”. The point is to control search before action consumes resources.

For Adaptive Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Adaptive Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

62. Execution Planning

Execution Planning turns an abstract plan into concrete steps, dependencies, tools, budgets, and checkpoints.

It connects to the surrounding material by taking the output of “Adaptive Planning” and preparing the ground for “Tool Planning”. The point is to control search before action consumes resources.

For Execution Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Execution Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

63. Tool Planning

Tool Planning decides which external capabilities are needed and under what authority.

It connects to the surrounding material by taking the output of “Execution Planning” and preparing the ground for “Knowledge Planning”. The point is to control search before action consumes resources.

For Tool Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Tool Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

64. Knowledge Planning

Knowledge Planning decides what must be known before action is safe or useful.

It connects to the surrounding material by taking the output of “Tool Planning” and preparing the ground for “Budget Planning”. The point is to control search before action consumes resources.

For Knowledge Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Knowledge Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

65. Budget Planning

Budget Planning allocates cost, latency, tokens, tool calls, verification, and human review.

It connects to the surrounding material by taking the output of “Knowledge Planning” and preparing the ground for “Risk Planning”. The point is to control search before action consumes resources.

For Budget Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Budget Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

66. Risk Planning

Risk Planning maps possible harm to mitigation, approval, reversibility, and monitoring.

It connects to the surrounding material by taking the output of “Budget Planning” and preparing the ground for “Replanning”. The point is to control search before action consumes resources.

For Risk Planning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Risk Planning: the engine either thrashes without a plan or follows a stale plan after reality changes.

67. Replanning

Replanning revises the path when assumptions break or the user redirects the goal.

It connects to the surrounding material by taking the output of “Risk Planning” and preparing the ground for the next design decision. The point is to control search before action consumes resources.

For Replanning, implementation should produce inspectable plans with steps, dependencies, expected outputs, evidence needs, tool needs, budgets, and replan triggers.

Failure mode for Replanning: the engine either thrashes without a plan or follows a stale plan after reality changes.

PART VII - CONTEXT ENGINEERING

This part governs attention. Context is the selected information a reasoning step can use, and selection quality often determines output quality.

The chapters move from theory to assembly, ranking, compression, filtering, windows, token use, lifecycle, and evolution.

68. Context Theory

Context Theory treats context as selected attention, not all available information.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Context Assembly”. The point is to govern attention before reasoning begins.

For Context Theory, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Theory: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

69. Context Assembly

Context Assembly builds the package of information used for a reasoning step.

It connects to the surrounding material by taking the output of “Context Theory” and preparing the ground for “Context Ranking”. The point is to govern attention before reasoning begins.

For Context Assembly, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Assembly: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

70. Context Ranking

Context Ranking orders candidate information by usefulness to the current goal.

It connects to the surrounding material by taking the output of “Context Assembly” and preparing the ground for “Context Compression”. The point is to govern attention before reasoning begins.

For Context Ranking, implementation should score relevance together with trust, freshness, coverage, diversity, cost, and risk; similarity alone is not production grounding.

Failure mode for Context Ranking: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

71. Context Compression

Context Compression reduces information while preserving decision-relevant distinctions.

It connects to the surrounding material by taking the output of “Context Ranking” and preparing the ground for “Context Filtering”. The point is to govern attention before reasoning begins.

For Context Compression, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Compression: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

72. Context Filtering

Context Filtering removes irrelevant, stale, unsafe, duplicate, or untrusted material.

It connects to the surrounding material by taking the output of “Context Compression” and preparing the ground for “Context Prioritization”. The point is to govern attention before reasoning begins.

For Context Filtering, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Filtering: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

73. Context Prioritization

Context Prioritization decides what deserves attention first under limited context.

It connects to the surrounding material by taking the output of “Context Filtering” and preparing the ground for “Context Windows”. The point is to govern attention before reasoning begins.

For Context Prioritization, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Prioritization: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

74. Context Windows

Context Windows are the finite working area available to the reasoning substrate.

It connects to the surrounding material by taking the output of “Context Prioritization” and preparing the ground for “Token Optimization”. The point is to govern attention before reasoning begins.

For Context Windows, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Windows: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

75. Token Optimization

Token Optimization maximizes useful signal per unit of context cost.

It connects to the surrounding material by taking the output of “Context Windows” and preparing the ground for “Context Lifecycles”. The point is to govern attention before reasoning begins.

For Token Optimization, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Token Optimization: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

76. Context Lifecycles

Context Lifecycles describe how information enters, is used, becomes stale, and leaves active reasoning.

It connects to the surrounding material by taking the output of “Token Optimization” and preparing the ground for “Context Evolution”. The point is to govern attention before reasoning begins.

For Context Lifecycles, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Lifecycles: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

77. Context Evolution

Context Evolution describes how the active information set changes as the task progresses.

It connects to the surrounding material by taking the output of “Context Lifecycles” and preparing the ground for the next design decision. The point is to govern attention before reasoning begins.

For Context Evolution, implementation should build context packages with ranked evidence, provenance, task state, user constraints, and separation between instruction and data.

Failure mode for Context Evolution: context starvation causes shallow work, while context explosion causes distraction, cost, and security risk.

PART VIII - MEMORY

This part separates the many meanings of memory. Memory is not one store; it is retained state at different time scales for different purposes.

The sequence moves from working memory to collective memory, then into indexing, retrieval, consolidation, compression, forgetting, and evolution.

78. Memory Theory

Memory Theory treats retained state as a controlled influence on future behavior.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Working Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Theory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Theory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

79. Working Memory

Working Memory is task-local state needed right now: goals, constraints, assumptions, intermediate results, and open questions.

It connects to the surrounding material by taking the output of “Memory Theory” and preparing the ground for “Conversation Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Working Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Working Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

80. Conversation Memory

Conversation Memory preserves continuity across turns in an interaction.

It connects to the surrounding material by taking the output of “Working Memory” and preparing the ground for “Session Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Conversation Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Conversation Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

81. Session Memory

Session Memory persists across a bounded work session.

It connects to the surrounding material by taking the output of “Conversation Memory” and preparing the ground for “Semantic Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Session Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Session Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

82. Semantic Memory

Semantic Memory stores reusable facts, concepts, preferences, and relationships.

It connects to the surrounding material by taking the output of “Session Memory” and preparing the ground for “Episodic Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Semantic Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Semantic Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

83. Episodic Memory

Episodic Memory records events: what happened, when, who was involved, and what outcome followed.

It connects to the surrounding material by taking the output of “Semantic Memory” and preparing the ground for “Procedural Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Episodic Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Episodic Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

84. Procedural Memory

Procedural Memory stores how work is done: workflows, strategies, recipes, and checklists.

It connects to the surrounding material by taking the output of “Episodic Memory” and preparing the ground for “Long-Term Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Procedural Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Procedural Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

85. Long-Term Memory

Long-Term Memory persists beyond a task or session and shapes future behavior.

It connects to the surrounding material by taking the output of “Procedural Memory” and preparing the ground for “Organizational Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Long-Term Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Long-Term Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

86. Organizational Memory

Organizational Memory preserves institutional knowledge, practices, and decisions.

It connects to the surrounding material by taking the output of “Long-Term Memory” and preparing the ground for “Collective Memory”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Organizational Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Organizational Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

87. Collective Memory

Collective Memory aggregates learning across people, teams, agents, and workflows.

It connects to the surrounding material by taking the output of “Organizational Memory” and preparing the ground for “Memory Indexing”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Collective Memory: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Collective Memory: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

88. Memory Indexing

Memory Indexing makes retained state findable.

It connects to the surrounding material by taking the output of “Collective Memory” and preparing the ground for “Memory Retrieval”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Indexing: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Indexing: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

89. Memory Retrieval

Memory Retrieval selects prior state relevant and safe for the current task.

It connects to the surrounding material by taking the output of “Memory Indexing” and preparing the ground for “Memory Consolidation”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Retrieval: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Retrieval: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

90. Memory Consolidation

Memory Consolidation turns noisy history into durable lessons.

It connects to the surrounding material by taking the output of “Memory Retrieval” and preparing the ground for “Memory Compression”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Consolidation: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Consolidation: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

91. Memory Compression

Memory Compression reduces retained state while preserving future utility.

It connects to the surrounding material by taking the output of “Memory Consolidation” and preparing the ground for “Memory Forgetting”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Compression: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Compression: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

92. Memory Forgetting

Memory Forgetting deliberately removes or decays state for privacy, freshness, and relevance.

It connects to the surrounding material by taking the output of “Memory Compression” and preparing the ground for “Memory Evolution”. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Forgetting: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Forgetting: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

93. Memory Evolution

Memory Evolution changes memory schemas, retention rules, and retrieval behavior over time.

It connects to the surrounding material by taking the output of “Memory Forgetting” and preparing the ground for the next design decision. The point is to retain useful state without letting old state corrupt new work.

Implementation for Memory Evolution: store scope, source, confidence, retention, permission, and deletion metadata so the engine knows when this memory should and should not influence future work.

Failure mode for Memory Evolution: retained state becomes too trusted, too old, too broad, or too private for the situation where it is later reused.

PART IX - KNOWLEDGE

This part turns information into usable knowledge. Knowledge requires representation, provenance, relationships, versioning, validation, and governance.

The chapters move from documents and entities to graphs, ontologies, metadata, temporal truth, provenance, validation, and governance.

94. Knowledge Theory

Knowledge Theory is a named concern in knowledge design. It exists because this responsibility affects correctness, safety, cost, state, trust, or long-term maintainability enough that it should not remain hidden inside a prompt or incidental code.

It connects to the surrounding material by taking the output of the previous architectural question and preparing the ground for “Knowledge Representation”. The point is to make information trustworthy enough to use.

Implementation for Knowledge Theory: preserve source, owner, timestamp, version, entity links, validation status, and permissions so the knowledge object can be trusted and governed.