@agenticprimitives/ontology 1.0.0-alpha.22 → 1.0.0-alpha.24

package/tbox/core.ttl

@@ -10,10 +10,12 @@
 @prefix owl:  <http://www.w3.org/2002/07/owl#> .
 @prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
 @prefix prov: <http://www.w3.org/ns/prov#> .
+@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
+@prefix dul:  <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#> .
 
 ap: a owl:Ontology ;
     rdfs:label "Agentic Primitives — core ontology" ;
-    owl:versionInfo "0.1.0" .
+    owl:versionInfo "0.2.0" .
 
 # ─── Classes ──────────────────────────────────────────────────────────
 
@@ -25,29 +27,127 @@ ap:CanonicalAgentId a owl:Class ;
     rdfs:label "CanonicalAgentId" ;
     rdfs:comment "A branded CAIP-10 account identifier (eip155:* / hedera:* / solana:*). The SSO subject + directory key (ADR-0016). Validated by ap:CanonicalAgentIdShape." .
 
-# Agent-kind subclasses. agentKind is 3-valued (person/org/service; cbox); the kind hierarchy is OWL and
-# aligns to PROV-O (mappings/agent-discovery-standards.ttl): PersonAgent ⊑ prov:Person, OrganizationAgent ⊑
-# prov:Organization, ServiceAgent ⊑ prov:SoftwareAgent. validator + treasury are NOT agentKinds — they are
-# KINDS OF SERVICE (⊑ ServiceAgent).
+# ─── The kind hierarchy (ADR-0046 + ADR-0061) ─────────────────────────
+#
+# THREE CLOSED ROOTS, aligned to PROV-O's trichotomy HERE in core (the mappings file keeps only
+# skos matches): PersonAgent ⊑ prov:Person, OrganizationAgent ⊑ prov:Organization,
+# ApplicationAgent ⊑ prov:SoftwareAgent. agentKind is 3-valued (person/org/service; cbox) and the
+# wire value 'service' names the ApplicationAgent ROOT (ADR-0046 amendment 2026-08-29).
+#
+# A DERIVED-TYPE LAYER subclasses the roots (spec 346 §2.1; the ap:Treasury precedent, generalized):
+#   TeamAgent, AllianceAgent      ⊑ OrganizationAgent
+#   ServiceAgent                  ⊑ ApplicationAgent   (re-seated; was ⊑ Agent)
+#   WorkspaceAgent, Treasury, RegistryAgent ⊑ ServiceAgent
+# A derived type is carried in the profile/kind record (ap:agentType + ap:serviceRole), NEVER by adding
+# a value to agentKind. A name suffix names the derived type (.me .org .team .svc .workspace .treasury
+# .registry) and is a CLAIM the on-chain record is checked against — never authority (ADR-0061).
+# validator + treasury + registry are NOT agentKinds — they are KINDS OF SERVICE (⊑ ServiceAgent).
+#
+# EVERY SERVICE AGENT IS TWO THINGS: the AGENTIC PIECE (the application — the software that can act)
+# and the SOCIAL AGENT it acts for (the workspace, the registry, the account). Only the first can
+# sign; only the second has standing. ap:ServiceAgent carries that split in full — read it there
+# before adding a service class, because a class that collapses the two grants authority to software.
 ap:PersonAgent a owl:Class ;
-    rdfs:subClassOf ap:Agent ;
+    rdfs:subClassOf ap:Agent , prov:Person ;
     rdfs:label "Person Agent" ;
-    rdfs:comment "An agent of kind 'person' (agentKind=person) — a natural person's Smart Agent." .
+    rdfs:comment "An agent of kind 'person' (agentKind=person) — a natural person's Smart Agent. A closed ROOT (prov:Person); its own derived type (the trivial specialization). Named by '.me'." .
 
 ap:OrganizationAgent a owl:Class ;
-    rdfs:subClassOf ap:Agent ;
+    rdfs:subClassOf ap:Agent , prov:Organization ;
     rdfs:label "Organization Agent" ;
-    rdfs:comment "An agent of kind 'org' (agentKind=org) — an organization's Smart Agent, with members (aporg:memberOf; membership is informational, authority lives in custody/relationships). Grounded ⊑ prov:Organization (mappings)." .
+    rdfs:comment "An agent of kind 'org' (agentKind=org) — an organization's Smart Agent, with members (aporg:memberOf). Membership is informational: being a member authorizes nothing, and authority to act for the org is a DELEGATION (ADR-0041) — not custody of its key, which is a third, separate thing (see ap:CustodyMember). A closed ROOT (prov:Organization); derived types TeamAgent and AllianceAgent subclass it. Named by '.org'." .
+
+ap:ApplicationAgent a owl:Class ;
+    rdfs:subClassOf ap:Agent , prov:SoftwareAgent ;
+    rdfs:label "Application Agent" ;
+    rdfs:comment "The prov:SoftwareAgent ROOT (wire value 'service' in AgentType / atl:agentKind — ADR-0046 amendment 2026-08-29). Closed root; derived types subclass it. 'Software agent' is the class; 'service' is what most of ours DO, so ServiceAgent is a derived type under this root, not the root itself." .
 
 ap:ServiceAgent a owl:Class ;
-    rdfs:subClassOf ap:Agent ;
+    rdfs:subClassOf ap:ApplicationAgent ;
     rdfs:label "Service Agent" ;
-    rdfs:comment "An agent of kind 'service' (agentKind=service). Service profiles, validators, and treasuries are Service Agents." .
+    rdfs:seeAlso dul:SocialAgent ;
+    rdfs:comment """An agent of kind 'service' (agentKind=service) — DERIVED under ap:ApplicationAgent
+      (re-seated by ADR-0061; was ⊑ ap:Agent). Named by '.svc'. Service profiles, validators, assistants,
+      treasuries, workspace agents and registry operators are Service Agents.
+
+      TWO SIDES, AND THE SPLIT IS THE POINT. A service agent is an AGENTIC PIECE — an application
+      (⊑ ap:ApplicationAgent ⊑ prov:SoftwareAgent): running software that can act, hold a session key,
+      sign, and answer an A2A/MCP surface. It acts FOR a SOCIAL AGENT — the standing thing the acting is
+      for, which bears the accountability and can execute nothing itself:
+
+        ap:WorkspaceAgent  acts for  aporg:Workspace   — the governed coordination plane
+        ap:RegistryAgent   acts for  apreg:Registry    — the registry instance
+        ap:Treasury        acts for  the account it holds — its own standing, no separate node
+
+      The social side is a dul:SocialAgent in DOLCE's sense (an agentive social object: it acts only
+      through what acts for it), and it is deliberately NOT asserted as an ap:Agent and holds no Smart
+      Agent — it cannot sign, so it can never be the executor (spec 344 §1.3; ADR-0061 §4). That is
+      exactly why it needs an application. What falls out of the split: the '.workspace' / '.treasury' /
+      '.registry' NAME binds to the application, never to the institution; a delegation is granted TO the
+      application, and revoking it leaves the application inert while the institution is untouched; and
+      replacing the application does not change who the institution is.
+
+      Roles (indexer, relay, marketplace, assistant, …) are an OPEN set carried by ap:serviceRole and get
+      neither a class nor a suffix; only the roles that carry their own suffix, validation predicate and
+      posture (workspace, treasury, registry) are also derived classes.""" .
+
+ap:TeamAgent a owl:Class ;
+    rdfs:subClassOf ap:OrganizationAgent ;
+    rdfs:label "Team Agent" ;
+    rdfs:comment """A CHARTERED org-kind Smart Agent operating within or across organizations
+      (aporg:TeamAffiliation): leadership, membership, continuity, responsibility, delegated
+      authority. An informal collection is aporg:WorkingGroup, not an agent. NOT a fourth agentKind
+      (the treasury⊂service precedent). ⊑ org:OrganizationalUnit under a sole 'chartered'
+      affiliation (mappings).""" .
+
+ap:AllianceAgent a owl:Class ;
+    rdfs:subClassOf ap:OrganizationAgent ;
+    rdfs:label "Alliance Agent" ;
+    rdfs:comment """An org-kind Smart Agent whose members are organizations, existing only where real
+      joint authority is delegated. A loose partnership is
+      aporg:InterorganizationalCollaborationArrangement — a record, not an agent.""" .
+
+ap:WorkspaceAgent a owl:Class ;
+    rdfs:subClassOf ap:ServiceAgent ;
+    rdfs:label "Workspace Agent" ;
+    rdfs:comment """The application that acts for ONE aporg:Workspace — the workspace's agentive face
+      (aporg:coordinatesWorkspace; the workspace points back with aporg:coordinatedBy). A service-kind SA
+      with serviceRole 'workspace', delegated by the workspace's GOVERNOR and named by '.workspace'. Never
+      an independent source of authority (spec 344 §2.1): revoke the governor's delegation and it is inert.
+      The workspace is the social side — an Entity that is never itself named and never signs (ADR-0061 §4).
+      Called 'workspace-coordinator' until 2026-08-31; renamed to sit beside treasury and registry, which
+      name the standing thing rather than the doing.""" .
 
 ap:Treasury a owl:Class ;
     rdfs:subClassOf ap:ServiceAgent ;
     rdfs:label "Treasury" ;
-    rdfs:comment "A custody-policy-governed asset account — a KIND OF SERVICE (agentKind=service), distinguished by ProfileType/serviceType='treasury' (specs 210/217/225 §6). NOT a top-level agent kind." .
+    rdfs:comment """The application that acts for a custody-policy-governed asset account — a KIND OF
+      SERVICE (agentKind=service), distinguished by ProfileType/serviceType='treasury' (specs 210/217/225
+      §6). NOT a top-level agent kind. Named by '.treasury'. Its social side is the ACCOUNT — the standing
+      that owns the assets — which this stack does not give a separate node: one SA is both the account of
+      record and the piece that can move it, so what keeps the acting bounded is the custody policy rather
+      than a second class. The other service agents get two nodes because their institution (a workspace,
+      a registry) outlives and outranks any application that serves it.""" .
+
+ap:RegistryAgent a owl:Class ;
+    rdfs:subClassOf ap:ServiceAgent ;
+    rdfs:label "Registry Agent" ;
+    rdfs:comment "The Service Agent that OPERATES a registry: admission, receipts, lifecycle log, discovery surface (spec 346 §7). Named by '.registry'; serviceRole 'registry' required; linked to its registry by apreg:operatesRegistry (range apreg:Registry). Signs RegistrationReceipts as the operator SA. The registry itself is an apreg:Registry (an Entity), never an agent; this class is its agentive face, exactly as WorkspaceAgent is the workspace's." .
+
+ap:ChurchAgent a owl:Class ;
+    rdfs:subClassOf ap:OrganizationAgent ;
+    rdfs:label "Church Agent" ;
+    rdfs:comment "An organization-class Smart Agent of congregation shape (a gathered community with leadership, membership and continuity); named by '.church'. A DERIVED type under the closed Organization root — ADR-0061 amendment 2026-08-30 (a deliberate Ring-0 carve-out from the vertical-vocabulary rule: the KIND is general, its content stays in apps)." .
+
+ap:HouseholdAgent a owl:Class ;
+    rdfs:subClassOf ap:OrganizationAgent ;
+    rdfs:label "Household Agent" ;
+    rdfs:comment "An organization-class Smart Agent of household shape: the family's own agent, chartered under a person, whose members are the people who live together with the roles and kinship the household model (aphh:) gives them (spec 368; ADR-0061 amendment 2026-09-07). It acts FOR an aphh:Household as an OrganizationAgent acts for an Organization. It is NOT the person's private household record (spec 363 W4), which stays the person's own note and needs no agent." .
+
+ap:CircleAgent a owl:Class ;
+    rdfs:subClassOf ap:OrganizationAgent ;
+    rdfs:label "Circle Agent" ;
+    rdfs:comment "An organization-class Smart Agent of small-group shape (a circle: a few people meeting with a shared purpose, able to hold a vault and act); named by '.circle'. Derived under the Organization root (ADR-0061 amendment 2026-08-30)." .
 
 ap:Facet a owl:Class ;
     rdfs:label "Facet" ;
@@ -81,3 +181,123 @@ ap:controlStatus a owl:DatatypeProperty ;
     rdfs:domain ap:CanonicalAgentId ;
     rdfs:range xsd:string ;
     rdfs:comment "Whether the subject is custodied here (custodied) or addressable-only (identifier-only). Non-EVM namespaces are identifier-only (spec 226 §4)." .
+
+# ─── Derived-type record (spec 346 §2.3; ADR-0061) ────────────────────
+
+ap:agentType a owl:ObjectProperty ;
+    rdfs:label "agentType" ;
+    rdfs:domain ap:Agent ;
+    rdfs:range skos:Concept ;
+    rdfs:comment "The DERIVED agent type (ap:agentTypeScheme, cbox — 7 values: person org team service workspace treasury registry). On-chain: atl:agentType on the SA subject (AgentProfileResolver, written by the SA itself, survives name changes). Distinct from ap:agentKind (the 3-value root scheme on the NAME node). The projection term external directory entries (ARD, A2A extension) carry. rootClassFor: team→org; service|workspace|treasury|registry→service. A suffix is checked AGAINST this record; it never overrides it." .
+
+ap:serviceRole a owl:DatatypeProperty ;
+    rdfs:label "serviceRole" ;
+    rdfs:domain ap:ServiceAgent ;
+    rdfs:range xsd:string ;
+    rdfs:comment "The OPEN role a Service Agent plays (indexer, relay, marketplace, assistant, workspace, registry, …). On-chain: atl:serviceRole on the SA subject. REQUIRED to equal 'workspace' when agentType = workspace and 'registry' when agentType = registry (spec 346 §2.3 invariant). A role is never a permission." .
+
+# ─── Standing between agents (spec 355; ADR-0061 §4) ───────────────────────────────────────────────
+#
+# WHY THIS EXISTS. "Send alice 20 USDC" names a PERSON; the money moves from a TREASURY. Nothing in the
+# sentence connects them, and nothing in their NAMES has to either — alice.me's treasury is called
+# alice2.treasury, and a resolver that guessed `alice.treasury` from the label found nothing and refused a
+# payment it should have made. What connects them is a RELATIONSHIP, and until it was named here every
+# consumer invented its own private convention for it: the Home's tree carried a `parent` field, the Ask
+# carried a table of name suffixes, and neither could be checked against the other.
+#
+# One property covers what the estate actually records: a Treasury is chartered under the Person or
+# Organization that holds it; a Team under a Workspace or Organization; a Workspace under an Organization.
+# The child is a distinct Smart Agent with its own custody — chartering is a statement of BELONGING and
+# PROVENANCE, never of authority. Revoking nothing here would grant anything: the parent's ability to act
+# for the child is a delegation, and it is elsewhere.
+
+ap:charteredUnder a owl:ObjectProperty ;
+    rdfs:label "charteredUnder" ;
+    rdfs:domain ap:Agent ;
+    rdfs:range ap:Agent ;
+    owl:inverseOf ap:charters ;
+    rdfs:comment """The agent this one was created under and belongs to: a Treasury under the Person or
+      Organization that holds it, a Team under its Workspace or Organization, a Workspace under its
+      Organization. Recorded at genesis and readable as the `parent` of a managed-agent record.
+      NOT CUSTODY, and the difference is why this property exists rather than being read off the custody
+      arrangement. Custody answers WHO CAN MAKE IT ACT; chartering answers WHOSE IT IS. They routinely
+      differ — an organization's treasury is chartered under the ORGANIZATION while being custodied by a
+      steward's personal credential — so deriving ownership from custody returns the steward and is wrong,
+      and reading chartering as custody grants an authority nobody conferred.
+      NEVER AUTHORITY (ADR-0010/0061): the child holds its own custody, and what lets a parent act for it
+      is a delegation, not this edge. A resolver may follow it to answer "which treasury does alice hold";
+      a verifier may not read it as permission to spend from one.
+      Where it is READABLE is a separate question from whether it is TRUE: today the estate records it in
+      the owner's own vault (ADR-0025), so a stranger cannot traverse it — see spec 355 §3.""" .
+
+# ── CUSTODY IS NOT MEMBERSHIP, AND NOT AUTHORITY ──────────────────────────────────────────────────────
+# Declared here because the discovery A-box already carries `ap:CustodyMember` instances, which made it
+# vocabulary this repo uses without ever having said what it means — the exact drift
+# `check:ontology-bindings` exists to stop. Naming it fixes that, and the comment is the point of the
+# class: the word "Member" in it means a member of a CUSTODY SET, and nothing else.
+
+ap:CustodyMember a owl:Class ;
+    rdfs:label "CustodyMember" ;
+    rdfs:comment """One opaque, public, chain-reproducible token standing for the fact that a credential
+      custodies a Smart Agent — sha256(lower(credential)|lower(smartAgent)), unsalted by design so that
+      anyone can reproduce it from on-chain events (ADR-0040 forbids a server pepper here).
+
+      IT ANSWERS EXACTLY ONE QUESTION: can this credential make that agent act?
+
+      IT IS NOT MEMBERSHIP. A person who custodies an organization's Smart Agent is not thereby a member
+      of it, and a member of an organization does not custody it — the two sets routinely have nobody in
+      common. Membership is `aporg:OrganizationMembership`, recorded in the organization's own roster and
+      in the person's own vault (ADR-0025), and it is the only thing that answers "what am I part of".
+
+      IT IS NOT AUTHORITY. Custody is control of the agent's own key material; authority to act ON BEHALF
+      of somebody is a delegation, signed, scoped and revocable on chain (ADR-0041). Reading custody as
+      authority would let whoever holds a steward's credential act as everything that steward touches,
+      which is precisely what the delegation chain exists to prevent.
+
+      SO: never derive membership from custody, never derive authority from custody, and never answer
+      "which organizations am I associated with" from this class. `checkCustody` asks the one question
+      above about agents the caller already named, and nothing else may read it.""" .
+
+ap:primaryPayee a owl:ObjectProperty ;
+    rdfs:label "primaryPayee" ;
+    rdfs:domain ap:Agent ;
+    rdfs:range ap:Agent ;
+    rdfs:comment """The agent this one wants to be PAID INTO — "when someone sends me money, it goes here".
+      An agent may hold several treasuries; only its owner knows which is the one to receive, and until
+      this existed a payer had to guess or be asked, which put the choice on the wrong person entirely.
+
+      A PREFERENCE, never authority and never a constraint. It does not stop anyone paying a different
+      treasury, does not permit anyone to spend from this one, and grants nothing at any gate: it answers
+      "where would you like it" and nothing else. A resolver may use it to stop asking; a verifier must
+      not read it at all.
+
+      PUBLIC BY NATURE, which bounds where it can be said: it is recorded as a role on the public
+      ap:charteredUnder edge, so an agent with no such edge — one its owner keeps unlisted — cannot carry
+      it. For those, the preference IS the grant: the owner names the one agent they are disclosing
+      (spec 338 §7).""" .
+
+ap:primaryPayer a owl:ObjectProperty ;
+    rdfs:label "primaryPayer" ;
+    rdfs:domain ap:Agent ;
+    rdfs:range ap:Agent ;
+    rdfs:comment """The account this agent USUALLY PAYS FROM — "when I send money, take it from here".
+
+      The mirror of ap:primaryPayee, and the half that was missing. The ontology could say which of
+      someone's accounts should RECEIVE, so a stranger's agent stopped asking; it could say nothing about
+      which one SPENDS, so the owner was asked every time — eighteen treasuries offered as a list, by an
+      agent that had no modelled way to know that one of them is the one they use.
+
+      A PREFERENCE, never authority. It does not permit anyone (including this agent) to spend from the
+      account: every payment still needs a mandate the payer signs for that request, and no verifier reads
+      this property. It answers "which one did you mean" and stops a question; it opens nothing.
+
+      DISTINCT FROM primaryPayee ON PURPOSE. The account you hand out to be paid into and the account you
+      spend from are often different, and an estate that conflated them would move money out of the one
+      its owner publishes. Both are roles on the same public ap:charteredUnder edge, so an agent kept
+      unlisted carries neither — for those the owner names the account in the request.""" .
+
+ap:charters a owl:ObjectProperty ;
+    rdfs:label "charters" ;
+    rdfs:domain ap:Agent ;
+    rdfs:range ap:Agent ;
+    rdfs:comment "Inverse of ap:charteredUnder — the agents created under this one. The direction a resolver traverses to answer 'what does this person hold', and the direction that must never be read as control." .

package/tbox/execution.ttl

@@ -26,6 +26,7 @@
 @prefix apexec:  <https://agenticprimitives.dev/ns/execution#> .
 @prefix aprole:  <https://agenticprimitives.dev/ns/role#> .
 @prefix ap:      <https://agenticprimitives.dev/ns/core#> .
+@prefix apactor: <https://agenticprimitives.dev/ns/actor#> .
 @prefix aps:     <https://agenticprimitives.dev/ns/skill#> .
 @prefix apguide: <https://agenticprimitives.dev/ns/guidance#> .
 @prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@@ -102,6 +103,21 @@ apexec:completionState a owl:ObjectProperty ;
   rdfs:label "completionState" ;
   rdfs:comment "The activity's terminal state. Required by every realization contract, together with prov:endedAtTime: an activity with neither is an attempt in progress, and crediting it as a realization is how a demonstrated-capability signal starts counting abandonments." .
 
+# ═══ Run provenance (spec 381) — what a run's record keeps in the acting agent's vault ═══
+# The durable half of a harness run: one activity per step, what it ran under, what it left. Read by
+# people and auditors after the fact; consulted by no verifier (a recorded allow grants nothing).
+
+apexec:endedAt a owl:DatatypeProperty ;
+  rdfs:subPropertyOf prov:endedAtTime ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:dateTime ;
+  rdfs:label "endedAt" ;
+  rdfs:comment "When the run (or a step of it) ended — PROV's endedAtTime, named as the record field that carries it (spec 381). NOT when the record was written or exported." .
+
+apexec:receiptDigest a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "receiptDigest" ;
+  rdfs:comment "SHA-256 over the canonical step receipt the activity left (spec 381): a commitment to what was done — capability, authority reference, verdict, timings — that an export may carry in place of the receipt itself. NOT the receipt, NOT evidence a verifier reads, and never a digest of the arguments alone." .
+
 apexec:usedPlanContentHash a owl:DatatypeProperty ;
   rdfs:domain prov:Activity ; rdfs:range xsd:string ;
   rdfs:label "usedPlanContentHash" ;
@@ -129,3 +145,155 @@ aprole:ConsultResponder a prov:Role ;
 aprole:ConsultRouter a prov:Role ;
   rdfs:label "ConsultRouter" ;
   rdfs:comment "The capacity an org's runtime functioned in while selecting members and synthesizing their attributed answers." .
+
+# ═══ The run as a PROV graph — spec 389 ══════════════════════════════════════
+#
+# What a harness run's provenance record (`run.provenance:<runRef>`, the acting agent's vault) says in
+# T-box terms, so that a stock PROV tool loads it and a SHACL shape can refuse a forged one. Every term
+# here is EVIDENCE — read by people, auditors and the Home after the fact — and is consulted by no
+# verifier: recording that a step was allowed grants nothing (spec 354 §1 / ADR-0041). Reused rather than
+# re-declared: prov:*, p-plan:*, ep-plan:* (plan.ttl), apvr:usedDelegation (verification-receipt.ttl),
+# apactor:ActorContext + its role properties (actor-context.ttl), apguide:AgentSkillPackage, apdel:Delegation.
+
+apexec:hasStep a owl:ObjectProperty ;
+  rdfs:domain apexec:ServiceExecution ; rdfs:range prov:Activity ;
+  rdfs:label "hasStep" ;
+  rdfs:comment "The run CONTAINS this step activity. PROV has no containment relation between activities (wasInformedBy is communication, not nesting), and reading step order off wasInformedBy would make a fan-out look sequential. Order lives on the plan (p-plan:isPrecededBy between the p-plan:Steps each activity correspondsToStep); this says only which run a step belongs to." .
+
+apexec:actorContext a owl:ObjectProperty ;
+  rdfs:domain prov:Activity ; rdfs:range apactor:ActorContext ;
+  rdfs:label "actorContext" ;
+  rdfs:comment "Who acted, for whom, and who started it, on THIS hop (spec 383): the apactor:ActorContext entity carrying actingAgent / originatingAgent / rootPrincipal. Context, never authority — the accountability root is the verified chain's root delegator (apexec:accountabilityRoot), not restated here." .
+
+apexec:delegatedToAgent a owl:ObjectProperty ;
+  rdfs:domain prov:Activity ; rdfs:range ap:Agent ;
+  rdfs:label "delegatedToAgent" ;
+  rdfs:comment "The agent a step was HANDED TO (spec 376): its run is a child of this one under a child mandate cut from the parent's. Distinct from apactor:delegatedTo, which relates two SubjectRefs inside an actor context; this relates an activity to the agent whose bundle it prov:wasInformedBy." .
+
+apexec:runRef a owl:DatatypeProperty ;
+  rdfs:domain apexec:ServiceExecution ; rdfs:range xsd:string ;
+  rdfs:label "runRef" ;
+  rdfs:comment "The run's reference — the key its record, its progress lines and its spans are kept under, and the string a done reply and a task artifact cite (hasProvenance). An identifier, never a digest of anything." .
+
+apexec:intentDigest a owl:DatatypeProperty ;
+  rdfs:domain apexec:ServiceExecution ; rdfs:range xsd:string ;
+  rdfs:label "intentDigest" ;
+  rdfs:comment "keccak256 of the ExecutionIntent (goal + context) the run served — the same digest the mandate's caveat binds (spec 336 §8.3). The record carries the digest so a reader can match a mandate to a run; it never carries the goal's words (spec 381 §1)." .
+
+apexec:authorityDecision a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "authorityDecision" ;
+  rdfs:comment "What the verifier decided for this step — `allow` or `deny` — AS RECORDED. A recorded allow is history, not permission: a replay re-derives the verdict against the chain as it is now (spec 370 P6), and no gate reads this field." .
+
+apexec:afterApproval a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:boolean ;
+  rdfs:label "afterApproval" ;
+  rdfs:comment "True when the verdict was taken AFTER a human approval (a suspended step resumed with the person's signature) — the second verification spec 350 requires, so an approval is never mistaken for the verdict itself." .
+
+apexec:chainDigest a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "chainDigest" ;
+  rdfs:comment "The digest of the VERIFIED delegation chain the step ran under (spec 383): every grant by reference from the accountability root to the acting agent. The links themselves are prov:used entities; the digest is the one value that names the whole chain." .
+
+apexec:accountabilityRoot a owl:ObjectProperty ;
+  rdfs:domain prov:Activity ; rdfs:range ap:Agent ;
+  rdfs:label "accountabilityRoot" ;
+  rdfs:comment "WHOSE AUTHORITY WAS SPENT: the root delegator of the verified chain (spec 383). Read off the verifier's evidence, never off the actor context — an actor context says who is acting, this says who answers for it." .
+
+apexec:errorClass a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "errorClass" ;
+  rdfs:comment "The CLASS of a step's failure (`authority_denied`, `tool_error`, `input_required` …), never its message: a message can carry a counterparty's name or an argument, a class cannot." .
+
+apexec:StepReceipt a owl:Class ;
+  rdfs:subClassOf prov:Entity ;
+  rdfs:label "StepReceipt" ;
+  rdfs:comment "The receipt a step left, AS AN ENTITY named by its digest (apexec:receiptDigest carries the same digest on the activity). The receipt itself — capability, authority reference, verdict, timings, bindings — stays on the run record; the graph holds the commitment. Distinct from apvr:VerificationReceipt (spec 303, a verifier's receipt about a chain check)." .
+
+apexec:ChainTransaction a owl:Class ;
+  rdfs:subClassOf prov:Entity ;
+  rdfs:label "ChainTransaction" ;
+  rdfs:comment "A transaction a step left on the chain, named by its hash — the ONE public fact a private run may cite, because anyone can look it up. The graph does not repeat what the transaction did; the chain says that." .
+
+apexec:Effect a owl:Class ;
+  rdfs:subClassOf prov:Entity ;
+  rdfs:label "Effect" ;
+  rdfs:comment "What FOLLOWED an act, per declared effect (spec 360): the record a disclosure wrote, the notice it sent. An effect that failed while the act stood is recorded with effectSucceeded false — visible evidence, never a reason the step is unwound." .
+
+apexec:effectProduces a owl:DatatypeProperty ;
+  rdfs:domain apexec:Effect ; rdfs:range xsd:string ;
+  rdfs:label "effectProduces" ;
+  rdfs:comment "The record type the effect writes (`payment.receipt`, `payment.notice`) — a name, never the record." .
+
+apexec:effectSucceeded a owl:DatatypeProperty ;
+  rdfs:domain apexec:Effect ; rdfs:range xsd:boolean ;
+  rdfs:label "effectSucceeded" .
+
+apexec:DecisionRecord a owl:Class ;
+  rdfs:subClassOf prov:Entity ;
+  rdfs:label "DecisionRecord" ;
+  rdfs:comment "What a step DECIDED for the person on the way to the act, and by which rule (spec 363 W6): which account paid, which Sarah was meant. The point and the rule id are recorded; what was chosen is not (it can be a name). Display and audit only; no verifier reads it." .
+
+apexec:decisionPoint a owl:DatatypeProperty ;
+  rdfs:domain apexec:DecisionRecord ; rdfs:range xsd:string ;
+  rdfs:label "decisionPoint" .
+
+apexec:decisionRule a owl:DatatypeProperty ;
+  rdfs:domain apexec:DecisionRecord ; rdfs:range xsd:string ;
+  rdfs:label "decisionRule" .
+
+# Completion states of a harness step (apexec:completionState, declared above). A closed list: a
+# reader that meets a state outside it is reading a record this vocabulary does not describe.
+
+apexec:Completed a apexec:CompletionState ;
+  rdfs:label "Completed" ;
+  rdfs:comment "The step ran and its tool returned." .
+
+apexec:Failed a apexec:CompletionState ;
+  rdfs:label "Failed" ;
+  rdfs:comment "The step ran and its tool failed (apexec:errorClass says how). Also an ep-plan:FailedActivity." .
+
+apexec:Refused a apexec:CompletionState ;
+  rdfs:label "Refused" ;
+  rdfs:comment "The verifier denied the step before its tool ran. A CONFORMING record — refusing to record a refusal would delete the evidence an audit most needs. Also an ep-plan:FailedActivity." .
+
+apexec:Skipped a apexec:CompletionState ;
+  rdfs:label "Skipped" ;
+  rdfs:comment "The step was not attempted (an earlier step's outcome made it moot, or a replay answered it from the record)." .
+
+apexec:Suspended a apexec:CompletionState ;
+  rdfs:label "Suspended" ;
+  rdfs:comment "The step is waiting on the person (a signature, an answer, a confirmation). Not terminal: the record of a suspended run is a checkpoint, and the run resumes under a fresh verification (spec 370 P1)." .
+
+# ═══ The span ↔ activity bridge — spec 390 W1 ═══
+# Every PROV activity names the OpenTelemetry span it IS, and every span names the activity (ap.prov.*
+# attributes). Both are derived from the same run and step references. CORRELATION, NEVER TRUST: a trace
+# id joins hops into one causal operation; nothing reads it for a verdict, and a forged one can at most
+# mis-file a trace.
+
+apexec:traceId a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "traceId" ;
+  rdfs:comment "The W3C Trace Context trace id (16 bytes, lowercase hex) of the trace this activity's span belongs to — the sender's when this run answered another (spec 381 W2), the caller's when a traceparent arrived (spec 390 W2). An identifier for a collector, never an input to admission or authority." .
+
+apexec:spanId a owl:DatatypeProperty ;
+  rdfs:domain prov:Activity ; rdfs:range xsd:string ;
+  rdfs:label "spanId" ;
+  rdfs:comment "The W3C Trace Context span id (8 bytes, lowercase hex) of the span this activity is. Derived from the run and step references, so the same record always names the same span." .
+
+# ═══ Offloaded artifacts — spec 391 ═══
+
+apexec:RunArtifact a owl:Class ;
+  rdfs:subClassOf prov:Entity ;
+  rdfs:label "RunArtifact" ;
+  rdfs:comment "A step's RAW RESULT, kept as its own record in the acting agent's vault (`run.artifact:<runRef>:<stepRef>`) because it was too large to ride in the run's record and checkpoint (spec 391). The step prov:generated it; the receipt's outputDigest commits to the same bytes. NOT an apful:Artifact (a deliverable a fulfillment promised) and not evidence a verifier reads — a body a person or a resume fetches under the agent's grant." .
+
+apexec:artifactBytes a owl:DatatypeProperty ;
+  rdfs:domain apexec:RunArtifact ; rdfs:range xsd:integer ;
+  rdfs:label "artifactBytes" ;
+  rdfs:comment "The canonical JSON length of the body — so a reader knows what fetching it costs." .
+
+apexec:artifactDigest a owl:DatatypeProperty ;
+  rdfs:domain apexec:RunArtifact ; rdfs:range xsd:string ;
+  rdfs:label "artifactDigest" ;
+  rdfs:comment "sha256 of the canonical JSON of the body. The same bytes the step receipt's outputDigest commits to, so the graph, the receipt and the vault record agree on what was produced." .

package/tbox/household.ttl

@@ -0,0 +1,142 @@
+# T-box — THE HOUSEHOLD (spec 363 W4).
+#
+# The smallest real domain that exercises every layer at once: classes (what a household IS), relation
+# axioms (how "my daughter's account" composes out of two links), and decisions (what a first name means
+# when it could be a person you live with or a stranger in a directory).
+#
+# WHY A HOUSEHOLD IS NOT AN AGENT. Every Smart Agent is a Person, an Organization or a Service
+# (ADR-0046), and a household is a body of people — so it is an Organization in the PROV sense, and it
+# MAY have an agent (a `.circle` or `.org` SA) exactly as any organization may. It need not: requiring
+# somebody to charter an agent, pay for its genesis and custody its keys before they can say who they
+# live with would be a tax on having a family. The household is a RECORD its members keep; an agent is
+# something a household may acquire when it starts acting as one.
+#
+# PRIVATE BY CONSTRUCTION. Who lives with whom is not on chain, is not derivable from chain state, and
+# therefore may never enter the discovery knowledge base (ADR-0040) — not hashed, not "temporarily", not
+# to make a lookup faster. It lives in each member's own vault (ADR-0025), which is also why this
+# ontology describes what a member RECORDS rather than a global fact: two people's households can
+# disagree, and the honest model says whose record you are reading.
+#
+# A FAMILY GRAPH IS EXACTLY THE DATA A PLATFORM SHOULD NOT HOLD. That is the reason for the tier, and it
+# is not a compliance posture: an estate that centralised this would not be worth using.
+
+@prefix aphh:  <https://agenticprimitives.dev/ns/household#> .
+@prefix ap:    <https://agenticprimitives.dev/ns/core#> .
+@prefix aporg: <https://agenticprimitives.dev/ns/org#> .
+@prefix skos:  <http://www.w3.org/2004/02/skos/core#> .
+@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
+@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix owl:   <http://www.w3.org/2002/07/owl#> .
+@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
+@prefix prov:  <http://www.w3.org/ns/prov#> .
+
+aphh: a owl:Ontology ;
+    rdfs:label "Agentic Primitives — Household" ;
+    rdfs:comment "The people someone lives with, as they record it: a private-tier body whose members may be agents, with roles and family relations that let a resolver understand 'my daughter' without a directory search (spec 363 W4)." .
+
+# ─── The body ─────────────────────────────────────────────────────────
+
+aphh:Household a owl:Class ;
+    rdfs:subClassOf prov:Organization ;
+    rdfs:label "Household" ;
+    rdfs:comment """A body of people who live as one — a family, a shared home, a house.
+
+      An ORGANIZATION in the PROV sense (a social entity with members), NOT a new agent class and not a
+      new kind of Smart Agent: the trichotomy stands (ADR-0046). It may be coordinated by an agent — a
+      `.circle` for a family that wants a shared inbox, an `.org` if it starts holding money — and it may
+      have none at all, which is the ordinary case and must stay free.
+
+      It is a RECORD ITS MEMBERS KEEP, not a global fact. Each member's vault holds their own household
+      record; two records may disagree, and the resolver always says whose it read.""" .
+
+aphh:HouseholdMembership a owl:Class ;
+    rdfs:subClassOf aporg:OrganizationMembership ;
+    rdfs:label "HouseholdMembership" ;
+    rdfs:comment """One person's place in one household, over a period, with a role.
+
+      A NODE, not an edge, for the same reason organization membership is one (ADR-0048): a role and a
+      period belong to the membership, not to the person. "Guardian" is not a property of somebody — it
+      is what they are IN this household, from a date, and possibly no longer.""" .
+
+aphh:memberOfHousehold a owl:ObjectProperty ;
+    rdfs:domain ap:Agent ; rdfs:range aphh:Household ;
+    rdfs:label "memberOfHousehold" ;
+    rdfs:comment """The households this agent belongs to — PLURAL, and meant so. A child between two
+      homes belongs to both; a carer's week is spent in one and their own life in another; a second home
+      is a household with people in it. A model that allowed only one would make somebody's second home
+      overwrite their first, which is a worse answer than not modelling it at all.
+
+      Private tier: never published, never indexed.""" .
+
+aphh:householdMember a owl:ObjectProperty ;
+    owl:inverseOf aphh:memberOfHousehold ;
+    rdfs:domain aphh:Household ; rdfs:range ap:Agent ;
+    rdfs:label "householdMember" ;
+    rdfs:comment "The agents in this household. The direction a resolver traverses to answer 'who do I live with'." .
+
+# ─── Roles and relations ──────────────────────────────────────────────
+#
+# A ROLE says what someone DOES in the household (who may decide for whom). A RELATION says how they are
+# KIN. They are different questions and conflating them is how a system decides that a spouse may act for
+# a spouse because the word sounded close enough. Neither is authority: a guardian's ability to act for a
+# dependent is a DELEGATION the dependent's custodian issued, and this vocabulary never substitutes for it.
+
+aphh:HouseholdRole a owl:Class ;
+    rdfs:subClassOf skos:Concept ;
+    rdfs:label "HouseholdRole" ;
+    rdfs:comment "What someone does in a household. NEVER authority — a guardian acts for a dependent only under a delegation, and this term is not one." .
+
+aphh:Guardian a aphh:HouseholdRole ;
+    skos:prefLabel "guardian" ;
+    rdfs:comment "Responsible for a dependent in this household. It does not grant the ability to act for them; it says who would be asked to." .
+
+aphh:Dependent a aphh:HouseholdRole ;
+    skos:prefLabel "dependent" ;
+    rdfs:comment "Cared for by a guardian of this household — a child, or an adult who has asked someone to hold that responsibility." .
+
+aphh:Member a aphh:HouseholdRole ;
+    skos:prefLabel "member" ;
+    rdfs:comment "An adult member with no dependency in either direction. The ordinary case, and the default." .
+
+aphh:householdRole a owl:ObjectProperty ;
+    rdfs:domain aphh:HouseholdMembership ; rdfs:range aphh:HouseholdRole ;
+    rdfs:label "householdRole" .
+
+aphh:KinRelation a owl:Class ;
+    rdfs:subClassOf skos:Concept ;
+    rdfs:label "KinRelation" ;
+    rdfs:comment """How one member is KIN to the person whose record this is.
+
+      DELIBERATELY SMALL. Kinship vocabularies are a well-known bottomless pit — step-, half-, in-law,
+      fostered, chosen, culture-specific — and a resolver needs exactly one thing from this: enough to
+      understand "my daughter" when somebody says it. So: the handful of words people actually use to
+      address a transfer, and `aphh:otherKin` with a free label for everything else, which is honest
+      about being a label rather than pretending to a taxonomy nobody agreed to.""" .
+
+aphh:spouse   a aphh:KinRelation ; skos:prefLabel "spouse" .
+aphh:child    a aphh:KinRelation ; skos:prefLabel "child" ;  skos:altLabel "daughter", "son" .
+aphh:parent   a aphh:KinRelation ; skos:prefLabel "parent" ; skos:altLabel "mother", "father" .
+aphh:sibling  a aphh:KinRelation ; skos:prefLabel "sibling" ; skos:altLabel "sister", "brother" .
+aphh:otherKin a aphh:KinRelation ; skos:prefLabel "relative" ;
+    rdfs:comment "Kin this vocabulary does not name. Carries the household's own label for the person, used verbatim and never re-interpreted." .
+
+aphh:kinRelation a owl:ObjectProperty ;
+    rdfs:domain aphh:HouseholdMembership ; rdfs:range aphh:KinRelation ;
+    rdfs:label "kinRelation" ;
+    rdfs:comment "How this member is kin to the record's owner. Absent for a housemate who is not kin, which is an ordinary household and not a gap." .
+
+# ─── The R-box: what composes out of the above ────────────────────────
+
+aphh:householdPayee a owl:ObjectProperty ;
+    owl:propertyChainAxiom ( aphh:householdMember ap:primaryPayee ) ;
+    rdfs:domain aphh:Household ; rdfs:range ap:Agent ;
+    rdfs:label "householdPayee" ;
+    rdfs:comment """The accounts a household's members want paid — a member, then the account that member
+      marked (ap:primaryPayee).
+
+      THIS IS WHY THE R-BOX EARNS ITS PLACE. "Send my daughter her allowance" is two links: the household
+      says who she is, her own mark says where her money goes. Written as an axiom, one traversal answers
+      it; written in code, every capability that ever needs it grows its own table and they drift.
+
+      IT COMPOSES TWO PREFERENCES AND NO PERMISSION. The chain says where money would LAND, never that
+      anyone may send it: the payment still needs a mandate the payer signs for that request.""" .

package/tbox/interaction.ttl

@@ -164,6 +164,19 @@ apix:DecisionReceipt        a owl:Class ; rdfs:subClassOf apix:Receipt ; rdfs:la
     rdfs:comment "A signed decision was made. NOT that it was executed." .
 apix:ExecutionReceipt       a owl:Class ; rdfs:subClassOf apix:Receipt ; rdfs:label "ExecutionReceipt" ;
     rdfs:comment "Work started, progressed or completed. NOT that the outcome was valid or the commitment discharged." .
+apix:PaymentReceipt         a owl:Class ; rdfs:subClassOf apix:ExecutionReceipt ; rdfs:label "PaymentReceipt" ;
+    rdfs:comment "A transfer of value OCCURRED: this payer, this payee, this asset, this amount, this transaction (spec 360). NOT that it was owed, NOT that it was accepted, NOT that any obligation is now discharged — a receipt says the money moved and nothing about why. Held by BOTH parties: the payer's copy and the payee's are the same fact, delivered twice, which is what lets either of them account for it without asking the other." .
+
+apix:receiptPayer  a owl:ObjectProperty ; rdfs:domain apix:PaymentReceipt ; rdfs:range prov:Agent ;
+    rdfs:label "receiptPayer" ; rdfs:comment "The agent whose funds moved — the mandate's delegator, never the person who typed the sentence." .
+apix:receiptPayee  a owl:ObjectProperty ; rdfs:domain apix:PaymentReceipt ; rdfs:range prov:Agent ;
+    rdfs:label "receiptPayee" ; rdfs:comment "The agent the funds reached. Pinned to the party named in the authorizing step, never a recipient chosen after the fact (spec 360 §1)." .
+apix:receiptAsset  a owl:DatatypeProperty ; rdfs:domain apix:PaymentReceipt ; rdfs:label "receiptAsset" ;
+    rdfs:comment "The asset contract the transfer moved." .
+apix:receiptAmount a owl:DatatypeProperty ; rdfs:domain apix:PaymentReceipt ; rdfs:label "receiptAmount" ;
+    rdfs:comment "The amount in the asset's own base units — never a rendered decimal, which loses the unit." .
+apix:receiptTx     a owl:DatatypeProperty ; rdfs:domain apix:PaymentReceipt ; rdfs:label "receiptTx" ;
+    rdfs:comment "The transaction that settled it — what makes this receipt checkable against the chain rather than believed." .
 
 # ─── Relations ──────────────────────────────────────────────────────────────