How typed entity schemas, permission-aware relationship graphs, and kinetic MCP writes transform AI agents from JSON-blob processors into typed, auditable business intelligence — with ClawQL’s .cqe format, fixture-backed reads, LOW/MEDIUM kinetic tools, and an honest map of what is shipped vs roadmap.
This pairs with twelve layers of LLM cost, model escalation and agent coordination, AP2 and the payment rails, and immutable releases. Architecture notes live in-repo: Enterprise Ontology (GitHub). Token-efficiency layers: docs.clawql.com/architecture/token-efficiency.
Shipped path today: .cqe (YAML still dual-accepted) + fixture MCP reads (CLAWQL_ENABLE_ONTOLOGY=1) + legal pack + LOW/MEDIUM MCP kinetic writes (CLAWQL_ENABLE_ONTOLOGY_WRITES=1). Command Deck builder, VS Code real-time validation, Arweave schema permanence, auto-Onyx bind from generate, and the full LOW→CRITICAL GraphQL @kinetic stack are roadmap — called out as such below.
The Problem Nobody Names Correctly
When enterprise AI projects fail — and most of them do, eventually — the post-mortem usually blames the model. Wrong model choice. Insufficient context. Hallucinations. Prompt engineering failures.
These diagnoses are almost always wrong. The real problem is earlier in the stack.
Consider what happens when you give an AI agent access to a company’s CRM, ERP, and document management system. The agent receives tool call responses that look like this:
{
"id": "acc-8821",
"cust_id": "C-4421",
"status": 2,
"type": "ENT",
"owner": "jsmith",
"created": 1720000000,
"val": 48500.0,
"currency": "USD"
}What is status: 2? What does type: "ENT" mean? Is owner: "jsmith" a user ID, an email, a display name? What does val represent — annual contract value, monthly, one-time? Is cust_id the same as id in the customer system or a different identifier?
The agent doesn’t know. Neither does the developer who wrote the integration. The answers are tribal knowledge, scattered across wiki pages, Slack threads, and the institutional memory of the person who built the CRM integration in 2019.
When the agent calls update_account with status: 3, it doesn’t know what status 3 means. When it queries accounts with type: "SMB", it doesn’t know if "SMB" is a valid value. When it joins account data with customer data using cust_id, it doesn’t know if that foreign key is always populated or frequently null.
This is the enterprise data problem that has existed since the first integration between two enterprise systems. Semantic fragmentation — the same real-world concept represented differently in every system, with no shared vocabulary to resolve the differences.
Traditional enterprise systems were built to store and retrieve records efficiently. They were not designed to preserve meaning across system boundaries. When an organization adds more applications, data pipelines, and AI systems, the cost of reconstructing meaning at every integration point compounds. Analysts reconcile terminology manually. Pipelines fail when field names change. AI models trained on one system’s data fail to generalize across others because the underlying concepts were never aligned.
AI makes this problem worse in two ways. First, AI agents operate at scale — one agent making thousands of tool calls compounds the semantic ambiguity at machine speed. Second, AI agents make decisions based on their interpretation of the data — and wrong interpretations at machine speed cause real-world damage.
The Enterprise Ontology is the solution to this problem. Not a new idea — semantic web researchers were working on this in 2001. But the implementation approach has changed fundamentally now that we have AI agents that can reason about typed schemas, generate typed queries, and respect typed constraints without constant human oversight.
Lesson: if your agent is hallucinating business meaning, don’t start with a bigger model. Start with whether the bytes it sees encode meaning at all.
What an Enterprise Ontology Actually Is
An Ontology, in the sense we’re using it, is a formally defined vocabulary of concepts in a domain — their types, their properties, their relationships, and the constraints that govern them. It is not a database schema. It is not an API contract. It is the semantic layer that sits above both, giving names and meaning to concepts that the database stores as integers and the API serializes as JSON.
The clearest mental model: OOP taken to its logical extreme.
Object-Oriented Programming gave us the insight that modeling the world as typed objects with properties, methods, and relationships produces more maintainable and comprehensible systems than modeling it as raw data and procedures. The Enterprise Ontology takes that insight and applies it to the entire enterprise information space — not just the software, but the real-world entities the software represents.
OOP: class Contract { parties: Party[], status: ContractStatus, sign(): void }
Database: CREATE TABLE contracts (id, status, effective_date, value...)
Ontology: Contract is a typed object with:
- Properties sourced from the database
- Relationships traversable to Organization and Individual
- Read methods generated as typed MCP tools
- Write methods generated as kinetic actions requiring authorization
- PII fields declared for automatic redaction before LLM exposure
- Audit level specified for every property changeThree properties make the Enterprise Ontology different from standard OOP in ways that matter for enterprise AI:
Provenance. In OOP, a Contract object is constructed at runtime from whatever data you hand to the constructor. In an Enterprise Ontology, a Contract object has a verifiable chain from the raw data source through the indexing pipeline to the typed object the agent sees. Every property value traces back to the specific database row or document page it came from. That chain is in the WORM audit log.
Permission-awareness. In OOP, method access control is typically application-level — you check permissions in the method body. In an Enterprise Ontology, permission-awareness is structural. The agent cannot see entities it doesn’t have authorization for. The graph traversal stops at authorization boundaries. The object doesn’t exist in the agent’s world if the agent isn’t authorized to see it — not an access denied error, structural invisibility.
Kinetic designation. In OOP, a method that writes to an external system looks the same at the call site as a method that reads. In an Enterprise Ontology, write methods are structurally different from read methods — they carry kinetic metadata (risk level, mandate requirements, blast radius), they require authorization before executing, and they generate audit entry types distinct from reads. The type system encodes the safety boundary. Today that ships as MCP write tools with kinetic metadata; GraphQL @kinetic is the target transport for the same semantics.
Why Now: Microsoft Fabric Just Validated the Entire Approach
Before diving into implementation, it’s worth noting that in mid-2026, Microsoft Fabric shipped their Ontology feature as part of Fabric IQ. The Fabric Ontology defines enterprise concepts as entity types (like Customer), properties (like a Customer’s name and email), and relationships (like Customer places Order), while clarifying the constraints of these terms. After defining the ontology, organizations bind the entity type definitions to real data so downstream tools can share the same language. Both humans and AI agents can use this language for cross-domain reasoning and decision-ready actions.
This is exactly the architecture described in this post — shipped by Microsoft as a first-class product feature. The validation matters not because Microsoft’s implementation is the right one (it isn’t — it has the same proprietary lock-in problem as Palantir’s Ontology), but because the largest enterprise software company in the world just confirmed that typed entity schemas for AI agents is the right architectural approach, not an academic exercise.
The difference between ClawQL’s Ontology and Microsoft Fabric’s: ClawQL’s is open format, version-controlled in Git, manifest-governed, independently auditable, and not tied to any cloud vendor’s data platform. Your Ontology schema is a .cqe file in your Git repository. If you want to move it, you git clone it.
The Three-Layer Architecture
The Enterprise Ontology has three distinct layers that build on each other. Each is independently valuable. Each feeds the next.
Layer 1: The Entity Schema
The Entity Schema defines what things are — their types, properties, data sources, PII declarations, and audit requirements. This is the .cqe file format.
# ontology/entities/Contract.cqe
---
type: ontology_entity
title: Contract
description: 'Legal agreement between two or more parties, establishing rights and obligations'
version: '1.2.0'
domain: legal
pii_classification: CONFIDENTIAL
worm_ref: sha256:a1b2c3d4... # links to WORM entry recording this schema version
---
properties:
contract_id:
type: string
required: true
indexed: true
immutable: true # cannot be changed after creation
description: 'Unique contract identifier'
title:
type: string
required: true
description: 'Human-readable contract name'
status:
type: enum
values: [draft, active, suspended, expired, terminated]
required: true
default: draft
description: 'Current lifecycle status'
audit_on_change: true # every status change generates WORM entry
effective_date:
type: date
required: true
expiry_date:
type: date
required: false
validation: 'expiry_date > effective_date'
value:
type: money
required: false
pii: false
kinetic_change_limit: '100000.00' # changes above this require AP2 mandate
parties:
type: array
items: { $ref: '#/entities/Organization' }
immutable: true # no mutation generated — party changes = new contract
primary_contact:
type: { $ref: '#/entities/Individual' }
pii: true # redacted before LLM exposure
required: false
document_refs:
type: array
items: { type: string } # Onyx document IDs
description: 'Linked documents in IDP pipeline'
sources:
- type: sql
connection: ${VAULT:contracts_db_ro}
table: contracts
id_column: contract_id
column_map:
cust_id: parties
status: status # int → enum mapping
val: value
- type: nextcloud
path: /company/legal/contracts/
classifier: classify_document
link_by: contract_id # links documents to entities by ID
audit:
level: STANDARD
pii_fields: [primary_contact, parties.contact_email]
change_log: trueSeveral things in this schema are doing real work beyond documentation:
The pii: true declarations drive Presidio redaction automatically — any LLM call that includes primary_contact data has those fields stripped before the prompt is assembled. The agent never sees raw PII unless its ATRClaims explicitly authorize it.
The immutable: true on parties means no mutation is generated for that field. An agent that tries to modify the parties on an existing Contract doesn’t get an access denied error — it gets a schema validation error explaining that party changes require a new Contract entity. The business rule is in the schema, not scattered across application code.
The sources block is the binding contract for where entity data comes from. Today the demo path is a fixture store behind CLAWQL_ENABLE_ONTOLOGY=1 — enough to prove typed reads (status: "active", not 2) without requiring a live CRM. Automatic Onyx indexing and live SQL bind from generate are the next bind steps; do not assume generate rewires your search cluster yet.
The worm_ref field is how schema versions join the audit story. Schema lives in Git with a release-manifest pin; clawql doctor warns when the pin drifts. Arweave permanence for ontology schema publishes is roadmap (the Layer 0 release story already exists for artifacts — ontology schema pinning to Arweave follows the same pattern when that path lands).
Layer 2: The Relationship Graph
Relationships between entities form a traversable graph. This is where the Enterprise Ontology becomes more powerful than a collection of database schemas — relationships create a navigable knowledge graph that agents can traverse with typed, permission-aware queries.
# ontology/relationships/contract_parties.cqe
---
type: ontology_relationship
title: ContractParties
description: 'Links a Contract to the Organizations that are party to it'
version: '1.0.0'
worm_ref: sha256:b2c3d4e5...
---
from: Contract
to: Organization
cardinality: many_to_many
via_table: contract_parties
via_columns:
from: contract_id
to: organization_id
traversal:
forward:
name: parties
description: 'Organizations that are party to this contract'
permission: READ_CONTRACT
reverse:
name: contracts
description: 'Contracts this organization is party to'
permission: READ_ORGANIZATION
constraints:
minimum: 2 # a contract requires at least 2 parties
parties_must_be_active: true # party Organizations must have status: activeThe permission fields on forward and reverse traversal mean graph queries respect authorization boundaries automatically. An agent traversing from Contract → parties → Organization will only see Organizations that the agent’s ATRClaims authorize it to read. The graph is permission-aware at the traversal level, not just at the entity level.
clawql ontology generate reads relationship definitions and generates typed graph traversal MCP tools:
// Generated MCP tools from relationship definitions
search_contracts(query: string, status?: ContractStatus): Contract[]
get_contract(contract_id: string): Contract
get_contract_parties(contract_id: string): Organization[]
get_organization_contracts(organization_id: string, status?: ContractStatus): Contract[]
list_contracts_expiring(days: number, party_id?: string): Contract[]The agent calls these typed tools instead of constructing raw SQL or API calls. The semantic ambiguity from the opening example — what does status: 2 mean? — is gone. The agent calls get_contract("acc-8821") and receives:
{
contract_id: "acc-8821",
title: "Enterprise Software License Agreement — Acme Corp",
status: "active", // typed enum, not integer 2
effective_date: "2026-01-15",
expiry_date: "2027-01-14",
value: { amount: 48500.00, currency: "USD" },
parties: [
{ organization_id: "org-4421", name: "Acme Corporation", type: "customer" }
]
// primary_contact: REDACTED — PII field, agent lacks PII_READ ATRClaim
}Typed. Semantic. Clean. The agent knows what every field means because the schema defines it. The agent can’t accidentally use the wrong status value because the enum is enforced at the tool layer.
Layer 3: The Action Schema — Reads and Writes at the Right Level
This is where the Ontology closes the loop from knowledge representation to safe autonomous execution.
Read tools generate from entity and relationship definitions — get_contract, search_contracts, get_contract_parties. Enable the fixture-backed demo with CLAWQL_ENABLE_ONTOLOGY=1. Schema-driven PII redaction applies on ontology results: fields marked pii: true are stripped before LLM exposure unless ATRClaims authorize them.
Write tools require explicit kinetic metadata. What ships today is MCP-first, not GraphQL-first.
Shipped: MCP kinetic writes (LOW + MEDIUM)
Behind CLAWQL_ENABLE_ONTOLOGY_WRITES=1:
export CLAWQL_ENABLE_ONTOLOGY=1
export CLAWQL_ENABLE_ONTOLOGY_WRITES=1
# LOW — status update, no mandate
# MCP tool: update_contract_status
# kinetic: { riskLevel: LOW, requiresMandate: false, blastRadius: SINGLE_RECORD }
# MEDIUM — value adjust, AP2 mandate required
# MCP tool: adjust_contract_value
# kinetic: { riskLevel: MEDIUM, requiresMandate: true, mandateType: AP2_FINANCIAL }LOW path: PEP validates ATRClaims → field snapshot for rollback → execute → WORM (STANDARD).
MEDIUM path: PEP validates ATRClaims → AP2 mandate verified → field snapshot → execute (or stage if over change limit) → WORM (DETAILED).
That is the demo you can run after clone: typed reads that say status: "active" instead of 2, plus a LOW status flip and a MEDIUM value change that refuses without a mandate.
Target transport: GraphQL @kinetic (not the shipped API)
GraphQL’s query/mutation split is still the right transport instinct — mutations are expected to have side effects; agents can introspect which operations write. Binary mutations alone are not enough: updateContractStatus and initiatePayment are both mutations but not the same risk class.
GraphQL @kinetic samples in the architecture docs are the target encoding of the same metadata MCP tools already carry — graded risk, mandate binding, blast radius, rollback protocol. Do not read them as a production GraphQL kinetic API today.
# Target transport shape (roadmap) — same semantics as MCP kinetic metadata
type Mutation {
updateContractStatus(contractId: ID!, status: ContractStatus!): Contract
@kinetic(riskLevel: LOW, requiresMandate: false, blastRadius: SINGLE_RECORD)
adjustContractValue(contractId: ID!, newValue: MoneyInput!): Contract
@kinetic(
riskLevel: MEDIUM
requiresMandate: true
mandateType: AP2_FINANCIAL
changeLimit: "100000.00"
)
}Next layers (not present tense)
HIGH / CRITICAL kinetic paths — bulk canary, forensic HITL, payment reversal windows — plus Argo Workflows / Rollouts and Pulumi executors for multi-step and infrastructure writes, are the next layers of the Transaction Sandbox. The IDP pipeline is already Workflow-shaped (Tika → … → Onyx); kinetic wrapping around those executors is how HIGH/CRITICAL will land, not how LOW/MEDIUM demos run today.
Lesson: side-effect bits are boolean. Kinetic metadata is a risk ladder. Ship the ladder on MCP tools first; promote the same ladder onto GraphQL when the transport is ready.
Kinetic Executors: The Roadmap Parallel
Progressive delivery (Argo Rollouts) and plan/state/rollback (Pulumi) solve the same problem kinetic HIGH/CRITICAL writes will: stateful change with real-world consequences, atomic, recoverable, observable.
ClawQL’s architecture routes by executor on kinetic metadata — native sandbox for app writes, Argo Workflows for DAGs, Pulumi for infra — under one PEP + WORM layer. Treat that triad as the design target. Today’s honest demo stays on native MCP LOW/MEDIUM.
The File Format: .cqe, .cqm, .cqw, .cqk
ClawQL defines four open file formats for the Ontology layer (ADR 0010). Specs live in-repo under docs/specs/cq-extensions/. Lint dual-accepts .cqe and YAML/JSON entity files.
.cqe — ClawQL Entity (primary). Lead with Contract.cqe. OKF-compatible Markdown + YAML frontmatter (type: ontology_entity) plus ClawQL fields (sources, pii_fields, audit, worm_ref). YAML entity files remain dual-accepted during the transition. clawql ontology generate emits typed MCP read tools (and catalogs deferred writes).
.cqm — ClawQL Manifest. Governance / release / policy manifests. Validated by clawql-release lint; schema version pins show up in doctor warnings when drift appears.
.cqw — ClawQL Workflow. Argo-shaped workflow templates with kinetic annotations — primarily for the HIGH/CRITICAL executor path ahead.
.cqk — ClawQL Knowledge. Optional OKF knowledge entries with worm_ref. Useful for recall boost and decision notes; not required for the Day-1 demo.
Authoring path today: Git + CLI + PR — not a visual builder. A VS Code extension with real-time .cqe validation is roadmap; until then, clawql ontology lint is the gate.
The OKF Integration: Memory and Ontology as One Vault
The memory vault and the Ontology schema are not separate systems. They are the same OKF-compatible directory structure with different type values in the frontmatter.
~/.ClawQL/
ontology/
index.md # OKF catalog of all entity types
log.md # changelog of schema changes
entities/
Contract.cqe
Patient.cqe
Organization.cqe
relationships/
contract_parties.cqe
actions/
initiate_payment.cqw
memory/
decisions/
arch-001.cqk # type: decision
context/
project-abc.cqk # type: context
task_results/
weekly-summary-2026-07-14.cqk # type: task_result
entities/ # populated entity instances
contracts/
contract-abc123.cqk # type: entity_instance, entity_type: Contractclawql ontology generate reads ontology/entities/*.cqe (and dual-accepted YAML) and generates:
- Typed MCP read tools registered for the gateway demo path
ontology/index.mdOKF catalog for survey-before-load recall- Deferred write/kinetic actions listed in the catalog (LOW/MEDIUM demo tools wire when
CLAWQL_ENABLE_ONTOLOGY_WRITES=1)
Live Onyx source configuration from sources: blocks is still a bind step — generate does not silently rewire your knowledge cluster.
memory_ingest writes to memory/**/*.cqk (optional) or OKF Markdown with worm_ref. memory_recall can read ontology/index.md first for a structured catalog before loading full .cqe / .cqk bodies — a meaningful token-efficiency gain over paste-the-vault.
Schema (.cqe, .cqm, .cqw) lives in Git — diffable, PR-reviewable, pinned in the release manifest, warned on by doctor. Instance data (memory, optional entity instances, indexes) belongs in object storage (R2/S3), not GitHub. Hot/cold sync is the scaling model; putting the whole vault in Git is not.
Token Efficiency: How the Ontology Closes the Loop
The Ontology is not a separate concern from token efficiency. It is the architecture that makes the deeper token efficiency layers possible.
Layer 1 (Context bloat) works because of the Ontology. The search + execute two-tool pattern assumes there’s a meaningful search space — a catalog of typed operations with semantic descriptions that the agent can search against. The Ontology provides that catalog. Without typed entity definitions, search() returns raw API endpoints. With typed entity definitions, search() returns semantically meaningful operations like “renew a contract” and “flag a contract for legal review” that the agent can reason about — so the model sees hundreds of tokens instead of the full spec.
Layer 2 (Verbose responses) is smarter with Ontology. Projecting responses to only the fields the agent depends on is more precise when those fields are typed entity properties rather than arbitrary JSON paths. The agent asks for Contract.status and Contract.expiry_date explicitly — GraphQL projection is one transport that can enforce that; MCP tools can do the same by returning declared properties only.
Layer 3 (Redundant static context) benefits from schema stability. The system prefix that Anthropic caches includes the tool definitions — the MCP tools generated from the Ontology schema. Because the Ontology schema is versioned in Git and pinned in the release manifest (rather than mutated implicitly at runtime), the tool definitions stay stable across sessions. The cache hit rate is higher because the stable prefix is longer.
Layer 5 (Semantic cache) is more effective with typed queries. “Show me contracts expiring in 90 days” and “list contracts that expire within three months” are semantically identical queries over the Contract entity. The semantic cache recognizes this because both queries are typed — they query the same entity type with the same relationship traversal. The embedding similarity is higher for typed entity queries than for arbitrary natural language queries over JSON blobs.
Layer 8 (Wrong model / model escalation) escalates on schema violations. When the model escalation router sees the agent attempting to access an unauthorized entity type, or trying to invoke a kinetic action without the required mandate, it treats this as a failure signal — the current tier didn’t have sufficient context to operate within the schema constraints. It escalates to a more capable tier that can reason more carefully about the authorization requirements.
Layer 12 (Flywheel) produces better training data with Ontology. Fine-tuning examples that involve typed entity queries — get_contract("acc-8821") returning a structured Contract object — are more generalizable than examples involving arbitrary JSON manipulation. The fine-tuned Frugal tier learns the entity schema and the query patterns, not just the surface-level string manipulation. Each Flywheel cycle makes the Frugal tier more accurate specifically on the organization’s entity types.
The compound effect: a typed entity query that goes through the stack — search over a typed entity catalog (Layer 1), response trimmed to declared properties (Layer 2), system prefix cached because schema is stable (Layer 3), semantically cached because query type is recognized (Layer 5), model-escalation-routed to Frugal (Layer 8), fine-tuned model used because domain is recognized (Layer 12) — costs a small fraction of the naive equivalent and produces higher-quality output because the model is operating on typed, semantically clean data rather than ambiguous JSON blobs.
The Vertical Schema Packs
Not every organization can construct their Ontology from scratch. Palantir-style Ontology builds often require significant professional services. ClawQL’s answer is vertical schema packs — pre-built .cqe bundles teams adopt and customize.
Available to import today: Legal.
clawql ontology import --pack legal
# Contract, Matter, Party, Clause, …Additional packs (Healthcare, Financial Services, Real Estate) are designed as Apache 2.0 OKF bundles with the same shape — industry entities, relationships, kinetic action stubs, PII defaults — but treat them as roadmap until each pack ships for import. The customization loop that is live: import legal → edit .cqe in Git → clawql ontology lint → clawql ontology generate → PR review.
The Palantir Comparison: Why Open Format Wins
Palantir’s Ontology is the most mature implementation of the typed enterprise entity concept in production today. It is genuinely powerful. Ontology provides a scaled, secure, and governed shared business model used across teams, agents, and workflows — Palantir’s version of this works and has worked for 20 years in some of the most demanding enterprise environments on earth.
The problem is structural. Palantir’s Ontology format is proprietary. It lives in Palantir’s systems. It requires Palantir’s tooling to read, write, or inspect. It cannot be versioned in Git alongside your code. It cannot be audited independently by a regulator who doesn’t have Palantir access. It cannot be exported to a different system without losing the semantic layer entirely.
Every organization that builds its Ontology on Palantir is building its organizational intelligence on a foundation it doesn’t own.
ClawQL’s approach: the Ontology schema is a directory of .cqe (and dual-accepted YAML) files in your Git repository. It is versioned with your code. It is reviewed in pull requests by your engineers. It is pinned in the release manifest; clawql doctor warns when the pin drifts. Arweave permanence for schema publishes is the same Layer 0 pattern described in immutable releases — apply it to ontology when that pin path lands; do not claim Arweave schema permanence as today’s publish button.
Both humans and AI agents can use this language for cross-domain reasoning and decision-ready actions — this is the right outcome. ClawQL’s implementation aims there without the lock-in. Your schema, in your Git repository, in an open format, independently auditable.
The Ontology Builder (Roadmap)
The schema format and CLI tooling come first. That is the authoring path that is real today: Git + CLI + PR.
The visual schema builder — Command Deck UI with entity / relationship / action panels — is sequenced after the format stabilizes. When it lands, it should emit .cqe files, open a PR, and make kinetic risk levels non-accidental. Until then, do not claim a three-panel builder that ships schemas to production. Security review is still a PR review of generated tools — just authored by hand or CLI templates rather than a canvas.
Getting Started in One Sprint
The path from “no Ontology” to “typed reads + LOW/MEDIUM kinetic demo” is a single sprint for a fixture-backed Contract:
# Day 1: Initialize + first entity
clawql ontology init
clawql ontology create-entity Contract
# Prefer Contract.cqe; YAML still dual-accepted by lint/generate
# Optional: start from the legal pack
clawql ontology import --pack legal
# Day 2–3: Validate and generate
clawql ontology lint
clawql ontology generate --dry-run
clawql ontology generate
# Day 4: Typed reads (fixture demo)
export CLAWQL_ENABLE_ONTOLOGY=1
clawql inference serve --port 8080
# MCP: search_contracts / get_contract → status: "active", not 2
# PII fields redacted unless ATRClaims allow
# Day 5: Kinetic writes (LOW + MEDIUM)
export CLAWQL_ENABLE_ONTOLOGY_WRITES=1
# update_contract_status (LOW) · adjust_contract_value (MEDIUM + mandate)
# Publish schema with the release (Git + manifest pin; doctor warns on drift)
clawql-release lint
clawql-release publish --tag v1.0.0By the end of the sprint: typed entity queries in Cursor/Claude via MCP, legal pack customized in Git, LOW/MEDIUM kinetic writes gated by env flags, schema version pinned in the release manifest. Relationship graph depth, live SQL/Onyx bind, Command Deck builder, VS Code validation, Arweave schema permanence, and HIGH/CRITICAL executors are the foundation you build next — not claims for Day 5.
Conclusion: The Semantic Layer Your Agents Have Been Missing
The enterprise data problem is 30 years old. The same real-world entity is a “customer” in the CRM, a “counterparty” in the fraud system, and a “subject” in the compliance system. Every integration reconstructs meaning manually. Every AI agent ingests JSON blobs and infers semantics from context.
The Enterprise Ontology is the solution the semantic web community proposed in 2001, that Palantir implemented in proprietary form, that Microsoft shipped in Fabric IQ, and that ClawQL implements as an open, Git-versioned schema agents can actually call.
The key insight — OOP taken to its logical extreme — still holds: typed objects with provenance, permission-aware traversal, and kinetic writes beat raw JSON. What has to stay honest is the delivery curve:
Open and portable (now). Your Ontology schema is .cqe (YAML dual-accepted) in Git. git clone takes it with you.
Versioned and reviewable (now). Schema changes are PRs. Release-manifest pins + doctor warnings catch drift. Arweave permanence for ontology publishes follows the Layer 0 path when wired.
Kinetically graded (partially now). MCP LOW/MEDIUM writes with kinetic metadata and AP2 mandates on value changes are the shipped demo. HIGH/CRITICAL, GraphQL @kinetic as live API, Argo/Pulumi executors, Command Deck builder, VS Code validation, and auto-Onyx bind are next — not present-tense product claims.
Architecture notes: Enterprise Ontology on GitHub. Token efficiency the Ontology enables: docs.clawql.com/architecture/token-efficiency.
Your agents have been operating on JSON blobs. Give them types — and say clearly which layers already run.
Shipped path = .cqe + fixture MCP reads + legal pack + LOW/MEDIUM MCP kinetic; builder, VS Code, Arweave schema permanence, auto-Onyx, and the full kinetic stack are roadmap. ClawQL platform context: docs.clawql.com · clawql.com.