Ontologies for Agentic Trust and Commerce | Agentic Primitives

Rich Canvas designs the shared ontologies that let AI agents act with authority but stay within the guardrails laid out by the ontology: agentic trust, commerce, faith, family office and more — built on Agentic Primitives and compiled into agent skill artifacts.

One vocabulary for what an agent may do, and proof of what it did

Rich Canvas builds ontologies for the agentic era: the shared, machine-checked vocabulary that tells an AI agent how a domain is shaped — who the parties are, what counts as an act, what an approval is, what a receipt proves. We author them for agentic trust, commerce, faith communities, family offices, and the everyday domains people actually live in, and we build them on the open substrate at https://agenticprimitives.dev — rails, not throttles: authority for agents that the agent cannot exceed.

The rule behind everything on this site: domain relationships live in the ontology — never in a prompt, never in an app table. A planner prompt says how an agent should behave; the ontology says how the world is shaped. When those are confused, an agent guesses, and a guessing agent is a liability. When they are separated, the same model generates the user interface, the agent's tool set, the published skill card, and the audit trail — from one definition.

---

Why an ontology, and not another prompt

Every agent framework can call tools. Almost none can say, in a form a verifier reads, why this agent is allowed to call this tool for this person right now. That answer is not a sentence in a system prompt. It is a modelled relationship: a treasury belongs to the organization that chartered it; a steward holds a grant the organization signed; a payment is an act on an asset under a mandate bound to an intent.

We write those relationships in RDF/OWL with SHACL shapes, bind them by IRI into code, and refuse the build when code invents vocabulary the ontology never declared. The result is behaviour that is generated, never hand-taught — and authority that is verified, never inferred. Read the doctrine behind it: Rails, not throttles (https://agenticprimitives.dev/writing/rails-not-throttles).

---

The ontology family

Each ontology below is a published module with a stable namespace, a T-box (the classes and relations), shapes that constrain structure but never permission, and an A-box discipline that keeps private facts private. They compose downward — nothing above depends on anything below.

Agentic Trust Ontology — the core

The foundation every other module rests on. It models the three things an agent can be — a person, an organization, or a service (PROV-O's trichotomy, nothing else) — and the one identifier they all share: a smart-account address. Names, profiles, registry entries and handles are facets pointing at that identity, never replacements for it.

- Core, identity, naming, profile — who exists and how they are addressed. ns/core (https://agenticprimitives.dev/ns/core) · ns/organization (https://agenticprimitives.dev/ns/organization)

- Delegation, mandates, attestation, verification receipts — authority as a signed, revocable, on-chain-checkable delegation; a mandate as a delegation with a reason (an intent digest); a receipt as evidence a stranger can recompute. ns/execution (https://agenticprimitives.dev/ns/execution)

- Discovery and resolution — finding an agent is a different question from being allowed to use it, and both are different from knowing where it lives right now. ns/discovery (https://agenticprimitives.dev/ns/discovery) · ns/resolution (https://agenticprimitives.dev/ns/resolution)

- Capability — what an agent advertises, in one canonical form, projected to A2A cards, MCP tools and SKILL.md without a second source of truth. ns/capability (https://agenticprimitives.dev/ns/capability)

- Guidance and situations — how a person's standing instructions and an agent's playbook shape behavior without ever becoming authority. ns/guidance (https://agenticprimitives.dev/ns/guidance)

Browse the full namespace index at https://agenticprimitives.dev/ns and the ontology overview at https://agenticprimitives.dev/ontology.

Interaction, Engagement and Coordination

Between "a message arrived" and "a workflow ran" there is a governed situation. These modules name it.

- Interaction — the root aggregate: exchanges, acts, content, commitments, receipts. An exchange without an interaction is just a message. Shapes constrain structure, never permission: an unauthorized command must still be recordable, because refusing to record overreach deletes the evidence. ns/interaction (https://agenticprimitives.dev/ns/interaction) · ns/messaging (https://agenticprimitives.dev/ns/messaging)

- Engagement — projections, probes, offers, mandates and receipts between a discovery match and fulfilment. Nine of the ten steps grant nothing; only the mandate authorizes. ns/engagement (https://agenticprimitives.dev/ns/engagement)

- Coordination — endeavors, work items, requests, decisions and the rules that govern them: coordination between agents, distinct from orchestration within one. ns/coordination (https://agenticprimitives.dev/ns/coordination)

CommerceCore Ontology

Listings, carts, offers, auctions, payments and settlement — modelled as the same offer algebra the engagement ontology uses. Our "two-flip" principle: who moves first and which way the resource flows are data, never architecture, and no flip flips authority. A buyer's mandate is bound to the offer it accepted; a settlement receipt says the money moved and never what it was for.

The commerce module is crosswalked to the standards vendors are converging on — AP2, UCP, ACP, Seaport, TMF921 — so a Rich Canvas commerce model can face any of them without a second data model. Explore the vocabulary on the skills site (https://skills.faithnet.io) (domain: commerce) and see the substrate's payment rails at https://agenticprimitives.dev/substrate.

Faith Ontology — congregations, formation, global mission

Faith communities were the first domain we modelled end to end, because they exercise every hard case at once: households and circles, stewards and members, gifts that move value, invitations that create belonging, and records people expect to keep for a lifetime and carry with them.

- Faith (upper) — the shared layer: congregation, circle, household, formation, commission.

- Congregation operations — the week: gatherings, care, giving, follow-up.

- Formation — discipleship paths and the milestones along them.

- Global mission and mission operations — people groups, engagement cycles, field circles, identity claims with their sources.

- Field Circles and Commission — the domains our own Field and Engage applications run on.

These live on the skills site as first-class domains — https://skills.faithnet.io — where each is compiled into skills an agent can be assigned.

---

From ontology to running agent: the skills pipeline

An ontology on its own is a document. What makes ours operational is the pipeline that compiles it into behaviour:

1. Author the contract. A capability's execution contract lives in SKILL.md — risk, requirement type, which argument names the resource and which names the authority, approvals, evidence, effects. One file, versioned, digest-pinned.

2. Compile. The skills compiler at https://skills.faithnet.io joins the ontology, the capability id and the SKILL.md contract into an AgentHarnessDefinition. From that one definition come the agent's tool set, its published vocabulary, its A2A card, each act's mandate requirement, what follows the act, and the affordance in the person's Home.

3. Assign. An agent is set to an archetype; the archetype's playbook is what it does. A playbook is never authority — a verifier consults it for nothing.

4. Run under a mandate. Every step that exercises a capability is checked, per step, against a signed, chain-live, intent-bound delegation before it runs. Unattended runs park. Payments are single-use. Resume re-verifies. Replay never re-runs a tool.

5. Leave evidence. Every run leaves a PROV-O bundle in the acting agent's own vault, anchored by digest on chain, that a counterparty can recompute without trusting the runtime.

Explore the library of compiled domains at https://skills.faithnet.io/library, and the developer path — create-app, the doctor, the read-only Developer MCP — at https://agenticprimitives.dev/developers and https://agenticprimitives.dev/build.

---

What makes this different from a framework

Most agent platforms keep authority in policy code: an allowlist here, a role check there, a human-in-the-loop flag that a prompt can talk its way around. Ours keeps five properties in contracts:

- identity survives the runtime (the agent is its smart account, not its host);

- attenuation is a delegation chain, not a function call;

- revocation is on-chain and checked per step;

- a mandate binds an intent digest, so authority is for a reason;

- a redemption is single-use, derived from the intent.

See how that compares with LangGraph, Microsoft Agent Framework, ADK, Dapr and the rest at https://agenticprimitives.dev/compare, and the platform picture at https://agenticprimitives.dev/platform.

---

Standards we build on, not around

- PROV-O for who did what on whose behalf; RDF, OWL and SHACL for the T-box and shapes; JSON-LD for every bundle that leaves a vault.

- W3C Trace Context and OpenTelemetry as the cross-agent spine — a trace id is correlation, never trust.

- ERC-4337 smart accounts, ERC-7579 modules, ERC-7710 delegations for authority that a verifier reads from the chain.

- A2A 1.0, MCP, RFC 9396 (rich authorization requests) as projections of the one capability model.

---

Work with Rich Canvas

We take on three kinds of engagement:

- A domain ontology for your vertical — modelled, shaped, crosswalked to the standards your partners use, and compiled into skills your agents can run.

- An agentic trust review — where your agents' authority actually lives today, and what it would take to make it something a verifier can read.

- A running pilot on the Agentic Primitives substrate — a Home for your people, agents for your organizations, receipts for your auditors.agenticprimitives.dev/

Start with our services (/services), read about us (/about-us), or contact us (/contact-us). If you are a developer, go straight to https://agenticprimitives.dev and the skills library at https://skills.faithnet.io.

---

Frequently asked

What is an agentic trust ontology? A shared vocabulary for identity, delegation, capability and evidence that lets one agent verify another's authority without trusting its runtime. Ours is published at https://agenticprimitives.dev/ns.

How is a commerce ontology different from a product catalogue? A catalogue describes goods. A commerce ontology describes offers, acceptances, mandates and settlements — the acts — so an agent can buy under authority it cannot exceed.

Do I need blockchain to use these ontologies? No. The ontologies are standard RDF/OWL. The substrate anchors authority and receipts on a chain because that is where revocation and single-use are enforced; the vocabulary stands on its own.

What is SKILL.md? A capability's execution contract — the file the skills compiler turns into tools, cards, mandates and screens. See the library at https://skills.faithnet.io.

Where do private records live? In the person's or organization's own vault, under per-record delegation scope — never in a platform store, never in a public knowledge base. The public knowledge base holds only what the chain already reveals.

---