@agenticprimitives/ontology 1.0.0-alpha.4 → 1.0.0-alpha.40

package/tbox/coordination.ttl

@@ -0,0 +1,263 @@
+# T-box — coordination vocabulary (spec 332 §3; ADR-0054).
+#
+# The Endeavor is the durable, multi-principal coordination Situation — the thing a person or org
+# posts as a request ("issue", "work item", "case", "project" in product vocabulary) and a group
+# coordinates to satisfy. Everything around it is REUSED, never re-minted: goals are apint:Intent,
+# capability requirements are aps:Capability + assertion strengths (ADR-0053), execution is
+# apful:Task / apexec:ServiceExecution, evidence is apatt:, conversation is fabric. What is new is
+# the durable middle: shared plan, participation, allocation, commitment.
+#
+# ── W0 SUBSET (the execution.ttl rule) ───────────────────────────────────────────────────────────
+# This module declares EXACTLY the spec-332 core subset — the classes the wave-1 package, the
+# provenance projection, and the coverage ledger reference — PLUS apcoord:Recommendation, whose
+# reader shipped with the spec-334 W4 agent-triage slice. The REST of the spec-333 vocabulary
+# (DecisionRequest, Risk, CapacityOffer, EndeavorCollection, …) is SPECIFIED but NOT declared here:
+# vocabulary minted ahead of a reader is a named mistake, and the coverage ledger carries each
+# term's honest status instead. When spec 333's wave lands, it EXTENDS this file.
+#
+# ── The doctrine that governs everything below (ADR-0054 §4) ─────────────────────────────────────
+# ALLOCATION IS NEVER AUTHORITY. capable / available / allocated / committed / authorized /
+# performing / satisfied are SEVEN separate facts. No gate reads an apcoord: term; a Recommendation,
+# a plan step, a participation role, or a commitment grants nothing — authority remains
+# delegation ∩ entitlement ∩ policy, evaluated at the gate at the moment of use.
+
+@prefix apcoord: <https://agenticprimitives.dev/ns/coordination#> .
+@prefix apsit:   <https://agenticprimitives.dev/ns/situation#> .
+@prefix apint:   <https://agenticprimitives.dev/ns/intent#> .
+@prefix ap:      <https://agenticprimitives.dev/ns/core#> .
+@prefix p-plan:  <http://purl.org/net/p-plan#> .
+@prefix prov:    <http://www.w3.org/ns/prov#> .
+@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 skos:    <http://www.w3.org/2004/02/skos/core#> .
+
+apcoord: a owl:Ontology ;
+    rdfs:label "Agentic Primitives — coordination ontology (spec 332 core subset)" ;
+    owl:versionInfo "0.1.0" ;
+    rdfs:comment "The durable coordination plane: Endeavor (a multi-principal Situation pursuing an outcome), its intake, shared plan, and participation lifecycle. Runtime record shapes live in @agenticprimitives/coordination. Spec 333 extends this module in its own wave." ;
+    skos:scopeNote "BETWEEN-AGENTS plane (coordination-vs-orchestration.md). Coordination schedules work between agents: participants are resolved through DISCOVERY (agent-naming, registry-kit, apdisc: capability-level matching) and needs are stated as aps:Capability requirements — never MCP tool ids or SKILL.md content. Distinct from apexec: (the WITHIN-AGENT orchestration plane); the only seam is compilation provenance in plan.ttl." .
+
+# ═══ Intake + the Endeavor itself ════════════════════════════════════════════
+
+apcoord:EndeavorRequest a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "EndeavorRequest" ;
+    rdfs:comment "Structured intake BEFORE adoption: goal statement, requester, target principal, entry-point context. Not yet a commitment by anyone. One engine, many doors (ADR-0054 §2): a Home request, a discussion @ask, a 1:1 inbox ask, and an A2A intent response all produce this same entity — the door sets intake context and default profile, never a different model." .
+
+apcoord:Endeavor a owl:Class ;
+    rdfs:subClassOf apsit:Situation ;
+    rdfs:label "Endeavor" ;
+    rdfs:comment "A PERSISTENT, MULTI-PRINCIPAL Situation pursuing a desired outcome — the durable coordination object products call issue/work item/case/project. Distinct from the run-specific execution it spawns and from the conversation about it. Vault-resident, managing-principal single-writer in V1." .
+
+apcoord:OutcomeSpecification a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "OutcomeSpecification" ;
+    rdfs:comment "The OBSERVABLE success definition for an Endeavor; versioned (revisions are new entities). Satisfaction is evidenced through apatt: Outcome/Validation attestations, never asserted by fiat." .
+
+apcoord:OutcomeCriterion a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "OutcomeCriterion" ;
+    rdfs:comment "One measurable, attestable, or reviewable success condition inside an OutcomeSpecification. Also the definition substance of milestones — a milestone is criteria, not merely a date." .
+
+apcoord:EndeavorRelation a owl:Class ;
+    rdfs:label "EndeavorRelation" ;
+    rdfs:comment "Reified TYPED link between Endeavors: depends-on | blocks | contributes-to | duplicates | supersedes | related-to | child-of (composite Endeavors). Never one overloaded 'related' edge; hierarchy (child-of) is distinct from collection membership (spec 333) and from PlanStep decomposition." .
+
+# ═══ The shared plan (P-Plan-grounded; see plan.ttl for the trichotomy) ═══════
+
+apcoord:CoordinationPlan a owl:Class ;
+    rdfs:subClassOf p-plan:Plan ;
+    rdfs:label "CoordinationPlan" ;
+    rdfs:comment "The DURABLE, VERSIONED, SHARED plan of an Endeavor. Revisions are new entities (prov:wasRevisionOf chains); adoption is an explicit decision, never implicit. COMPILES INTO run-specific apexec:ExecutionPlans — never a synonym for one (ADR-0054 §3). Content-hashed: commitments and executions bind the exact revision hash." .
+
+apcoord:PlanStep a owl:Class ;
+    rdfs:subClassOf p-plan:Step ;
+    rdfs:label "PlanStep" ;
+    rdfs:comment "One prescribed contribution, interaction, decision, aggregation, or validation inside a CoordinationPlan (p-plan:isStepOfPlan). Executed activities point back via p-plan:correspondsToStep. May carry capability requirements (aps:Capability + minimum assertion strength) — a requirement, never a permission." .
+
+apcoord:PlanEdge a owl:Class ;
+    rdfs:label "PlanEdge" ;
+    rdfs:comment "Reified typed step relation: precedes (projects onto p-plan:isPrecededBy) | depends-on | alternative | condition | compensates | refines." .
+
+apcoord:MilestoneDefinition a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "MilestoneDefinition" ;
+    rdfs:comment "A named convergence point DEFINED BY CRITERIA (OutcomeCriterion refs), not merely a date." .
+
+apcoord:MilestoneAchievement a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "MilestoneAchievement" ;
+    rdfs:comment "Evidence that a milestone's criteria became true — references apatt: evidence; never a checkbox." .
+
+# ═══ Participation lifecycle: proposal → allocation → commitment ══════════════
+
+apcoord:EndeavorParticipation a owl:Class ;
+    rdfs:subClassOf apsit:Situation ;
+    rdfs:label "EndeavorParticipation" ;
+    rdfs:comment "A participant's relationship to an Endeavor: role + scope + validity. Generalizes the apmsg:DiscussionParticipation pattern — asserted through invitation-acceptance or allocation-commitment, never implied. The role (sponsor | coordinator | contributor | validator | beneficiary | observer) is an apsit:SituationRole: capacity, not permission." .
+
+apcoord:ContributionProposal a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "ContributionProposal" ;
+    rdfs:comment "An offer to perform bounded PlanSteps. An offer binds nobody." .
+
+apcoord:AllocationDecision a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "AllocationDecision" ;
+    rdfs:comment "The Endeavor's SELECTION of a participant for a contribution. GRANTS NOTHING — 'allocated' is the third of the seven separate facts (ADR-0054 §4), and no gate reads it. The product-familiar 'assignee' is a projection over allocation + commitment." .
+
+apcoord:ContributionCommitment a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "ContributionCommitment" ;
+    rdfs:comment "The participant's SIGNED acceptance of bounded responsibility, binding the EXACT adopted plan revision hash. Signed via the universal signature paths (ERC-1271/6492/ECDSA/WebAuthn), fail-closed. STILL grants nothing: authorized remains a separate fact evaluated at the gate." .
+
+# ═══ Decisions by declared approvers (spec 333 §3, shipped by spec 393; reader: @agenticprimitives/coordination /decisions) ═══
+
+apcoord:ApprovalRequirement a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "ApprovalRequirement" ;
+    rdfs:comment "Declares WHO must approve: the addresses that may decide (the managing principal's address names the organization — a steward decides AS it), and a quorum. Quorum references organization/custody machinery (spec 333 §10 rule 3) — coordination never implements voting. Not authority: it names who may RECORD a decision, never what any step may do." .
+
+apcoord:DecisionRequest a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "DecisionRequest" ;
+    rdfs:comment "A decision that must be supplied before something proceeds, raised for its ApprovalRequirement by the organization or an active participant, scoped to plan steps when it concerns them, with an optional window (dueAt). Pending until an approver records approved or rejected; a deferral leaves it pending." .
+
+apcoord:DecisionRecord a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "DecisionRecord" ;
+    rdfs:comment "IMMUTABLE: who decided (the actor), on whose behalf (the organization when a steward decided as it), the outcome, the rationale, evidence refs, the scope, when. Never edited — a reversal is a new DecisionRequest citing the old. Admitted by the reducer only for an actor the requirement names: steward standing never substitutes for being named (spec 393 §1)." .
+
+# ═══ Agent triage (spec 333 §3 — W4 minimal slice; reader: @agenticprimitives/coordination /decisions) ═══
+
+apcoord:Recommendation a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "Recommendation" ;
+    rdfs:comment "AGENT-GENERATED, NON-AUTHORITATIVE proposed change: TYPED proposed commands + confidence + explanation + evidence, targeting a pending EndeavorRequest (triage, spec 334 §10) or an Endeavor. Lifecycle proposed → accepted | rejected, decided by the managing principal / a steward — NEVER auto-applied without an explicit CoordinationRule naming the class (spec 333 §5). Acceptance replays the proposed commands through ORDINARY command validation; a Recommendation grants nothing and no gate reads it." .
+
+# ═══ Execution context + adapter boundary ═════════════════════════════════════
+
+apcoord:CoordinationContextSnapshot a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "CoordinationContextSnapshot" ;
+    rdfs:comment "The IMMUTABLE, ENTITLEMENT-FILTERED, hash-addressed execution context handed to any executor: exact Endeavor revision, adopted plan hash, PlanStep, selected messages, selected artifacts, profiles, capability requirements, privacy filtering applied. Executions prov:used it by hash — reproducibility never requires handing anyone the whole discussion history." .
+
+apcoord:ExternalObjectBinding a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "ExternalObjectBinding" ;
+    rdfs:comment "Stable mapping to an EXTERNAL product object + revision (Linear/Jira/Asana/…): provider, external id/revision, sync mode, provider-extension schema/payload refs. The adapters themselves live in sibling repos (ADR-0037); an imported vendor 'task' must be semantically classified (Request | PlanStep | Task | DecisionRequest | Risk | Impediment | …), never a generic WorkItem." .
+
+# ═══ Properties ═══════════════════════════════════════════════════════════════
+
+apcoord:adoptedFrom a owl:ObjectProperty ;
+    rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:EndeavorRequest ;
+    rdfs:label "adoptedFrom" ;
+    rdfs:comment "Provenance back to intake: which request this Endeavor was adopted from." .
+
+apcoord:hasOutcomeSpecification a owl:ObjectProperty ;
+    rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:OutcomeSpecification ;
+    rdfs:label "hasOutcomeSpecification" .
+
+apcoord:hasCriterion a owl:ObjectProperty ;
+    rdfs:domain apcoord:OutcomeSpecification ; rdfs:range apcoord:OutcomeCriterion ;
+    rdfs:label "hasCriterion" .
+
+apcoord:hasRelation a owl:ObjectProperty ;
+    rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:EndeavorRelation ;
+    rdfs:label "hasRelation" .
+
+apcoord:relatedEndeavor a owl:ObjectProperty ;
+    rdfs:domain apcoord:EndeavorRelation ; rdfs:range apcoord:Endeavor ;
+    rdfs:label "relatedEndeavor" .
+
+apcoord:relationKind a owl:ObjectProperty ;
+    rdfs:domain apcoord:EndeavorRelation ; rdfs:range skos:Concept ;
+    rdfs:label "relationKind" ;
+    rdfs:comment "depends-on | blocks | contributes-to | duplicates | supersedes | related-to | child-of (C-box codelist)." .
+
+apcoord:plansEndeavor a owl:ObjectProperty ;
+    rdfs:domain apcoord:CoordinationPlan ; rdfs:range apcoord:Endeavor ;
+    rdfs:label "plansEndeavor" .
+
+apcoord:edgeFrom a owl:ObjectProperty ;
+    rdfs:domain apcoord:PlanEdge ; rdfs:range apcoord:PlanStep ;
+    rdfs:label "edgeFrom" .
+
+apcoord:edgeTo a owl:ObjectProperty ;
+    rdfs:domain apcoord:PlanEdge ; rdfs:range apcoord:PlanStep ;
+    rdfs:label "edgeTo" .
+
+apcoord:edgeKind a owl:ObjectProperty ;
+    rdfs:domain apcoord:PlanEdge ; rdfs:range skos:Concept ;
+    rdfs:label "edgeKind" ;
+    rdfs:comment "precedes | depends-on | alternative | condition | compensates | refines (C-box codelist)." .
+
+apcoord:achieves a owl:ObjectProperty ;
+    rdfs:domain apcoord:MilestoneAchievement ; rdfs:range apcoord:MilestoneDefinition ;
+    rdfs:label "achieves" .
+
+apcoord:participatesIn a owl:ObjectProperty ;
+    rdfs:domain apcoord:EndeavorParticipation ; rdfs:range apcoord:Endeavor ;
+    rdfs:label "participatesIn" .
+
+apcoord:proposesSteps a owl:ObjectProperty ;
+    rdfs:domain apcoord:ContributionProposal ; rdfs:range apcoord:PlanStep ;
+    rdfs:label "proposesSteps" .
+
+apcoord:selectsProposal a owl:ObjectProperty ;
+    rdfs:domain apcoord:AllocationDecision ; rdfs:range apcoord:ContributionProposal ;
+    rdfs:label "selectsProposal" .
+
+apcoord:acceptsAllocation a owl:ObjectProperty ;
+    rdfs:domain apcoord:ContributionCommitment ; rdfs:range apcoord:AllocationDecision ;
+    rdfs:label "acceptsAllocation" .
+
+apcoord:bindsPlanRevision a owl:ObjectProperty ;
+    rdfs:domain apcoord:ContributionCommitment ; rdfs:range apcoord:CoordinationPlan ;
+    rdfs:label "bindsPlanRevision" ;
+    rdfs:comment "The EXACT adopted revision the commitment was signed against; a stale hash is a rejected commitment, never coerced forward." .
+
+apcoord:planContentHash a owl:DatatypeProperty ;
+    rdfs:domain apcoord:CoordinationPlan ; rdfs:range xsd:string ;
+    rdfs:label "planContentHash" ;
+    rdfs:comment "Hash of steps+edges+milestones — the adoption, commitment, and adapter-provenance key. Same load-bearing role apexec:usedPlanContentHash plays for playbooks." .
+
+apcoord:snapshotHash a owl:DatatypeProperty ;
+    rdfs:domain apcoord:CoordinationContextSnapshot ; rdfs:range xsd:string ;
+    rdfs:label "snapshotHash" .
+
+apcoord:entryPoint a owl:ObjectProperty ;
+    rdfs:domain apcoord:EndeavorRequest ; rdfs:range skos:Concept ;
+    rdfs:label "entryPoint" ;
+    rdfs:comment "home-request | discussion-ask | inbox-ask | a2a-intent (C-box codelist). The door, recorded for provenance — never a different semantic model per door." .
+
+# ═══ Spec 438 W1/W4 — how a commitment ENDS, and attribution as evidence ══════════════════════════
+#
+# A commitment that only ever reads "accepted" cannot be told apart from one that was kept. Three endings,
+# and the difference between them is WHO SAYS SO: a discharge is asserted by the participant with evidence
+# refs; a breach is DECLARED by the coordinator after the deadline and is a judgment about conduct; a lapse is
+# neither party's fault. None is derived automatically by a timer — a timer produces a fact nobody asserted.
+apcoord:CommitmentState a owl:Class ; rdfs:subClassOf skos:Concept ; rdfs:label "CommitmentState" ;
+    rdfs:comment "How a ContributionCommitment stands. The notations are the words the reducer actually persists — a scheme that renamed them would describe a system nobody runs. Still grants nothing: authorized remains a separate fact at the gate." .
+apcoord:CommitmentStates a skos:ConceptScheme ; rdfs:label "Commitment states" .
+apcoord:cs-active a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "active" ; skos:prefLabel "active" ; skos:definition "Signed and live. Where a commitment STAYS while nobody has asserted otherwise — never evidence that it is going well." .
+apcoord:cs-fulfilled a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "fulfilled" ; skos:prefLabel "fulfilled" ; skos:definition "Discharged: the participant asserted completion CITING receipt references or a satisfied plan step. A discharge with no evidence reference is refused before append (spec 438 §3)." .
+apcoord:cs-withdrawn a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "withdrawn" ; skos:prefLabel "withdrawn" ; skos:definition "The participant withdrew before the deadline. No blame is recorded." .
+apcoord:cs-reallocated a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "reallocated" ; skos:prefLabel "reallocated" ; skos:definition "The contribution moved to another participant. The handoff never widens authority." .
+apcoord:cs-breached a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "breached" ; skos:prefLabel "breached" ; skos:definition "The coordinator DECLARED the bounded responsibility unmet after its deadline. A judgment about conduct, and never a timer's output — nothing derives it (spec 438 §3)." .
+apcoord:cs-lapsed a apcoord:CommitmentState ; skos:inScheme apcoord:CommitmentStates ; skos:notation "lapsed" ; skos:prefLabel "lapsed" ; skos:definition "The allocation expired with nobody at fault. Distinct from breach, which blames, and from withdrawn, which someone chose." .
+
+# ATTRIBUTION IS EVIDENCE. Who contributed is provenance; how valuable is this; who gets PAID is an agreement
+# plus a mandate, and the three are never the same record. A number produced here is readable by a person and
+# by an agreement's author — and by no gate. The build enforces it (`check:attribution-not-entitlement`).
+apcoord:AttributionPolicy a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "AttributionPolicy" ;
+    rdfs:comment "A DECLARED method for apportioning credit over a contribution graph (betweenness, path-count, declared weights) with its parameters and version, cited by digest. Declaring it is what makes the number arguable; an undeclared method is a verdict with no premises." .
+
+apcoord:AttributionAssessment a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "AttributionAssessment" ;
+    rdfs:comment "The output of applying an AttributionPolicy to one Endeavor's contribution graph. EVIDENCE, NEVER AN ENTITLEMENT: no payment, mandate or agreement may take this as an input (spec 438 §7)." .
+

package/tbox/core.ttl

@@ -3,6 +3,7 @@
 # The on-chain OntologyTermRegistry / ShapeRegistry (ADR-0009) instantiate
 # this vocabulary; off-chain TTL is the source of truth for the IRIs.
 
+@prefix apsit: <https://agenticprimitives.dev/ns/situation#> .
 @prefix ap:   <https://agenticprimitives.dev/ns/core#> .
 @prefix apid: <https://agenticprimitives.dev/ns/identity#> .
 @prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@@ -10,14 +11,17 @@
 @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.1" .
 
 # ─── Classes ──────────────────────────────────────────────────────────
 
 ap:Agent a owl:Class ;
+    rdfs:subClassOf prov:Agent ;
     rdfs:label "Agent" ;
     rdfs:comment "The canonical ERC-4337 Smart Agent (ADR-0010). Every other node is a facet of, or edge to, an Agent. Identified by an ap:CanonicalAgentId." .
 
@@ -25,17 +29,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. treasury is NOT an agentKind — it is a KIND OF SERVICE.
+# ─── 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 , prov:Person ;
+    rdfs:label "Person 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 , 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: 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:label "ServiceAgent" ;
-    rdfs:comment "An agent of kind 'service' (agentKind=service). Service profiles and treasuries are ServiceAgents." .
+    rdfs:subClassOf ap:ApplicationAgent ;
+    rdfs:label "Service Agent" ;
+    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" ;
@@ -69,3 +183,207 @@ 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.
+
+# ─── Stewardship — the relation the WORD "steward" names (agent-vocabulary.md R.2, §5) ─────────────
+# A person stewards an organization or a service: she oversees it and may act for it, on the strength of the OVERSIGHT
+# DELEGATION the agent signed to her at birth (spec 246) — the same artifact the Home's related-orgs link records as
+# `relationship: steward`. It is NOT custody (custody is a KEY's relation to an address — ap:CustodyMember — and on a
+# KMS-custodied home the key is one the person has never seen), and it is NOT membership (a steward need not be a
+# member; a member does not steward). Until this class existed the relation lived only in app code, and the Home's
+# switcher called it "acting as custodian" — the wrong word, for the lack of a right one to bind to.
+ap:Stewardship a owl:Class ;
+    rdfs:subClassOf apsit:Situation ;
+    rdfs:label "Stewardship" ;
+    rdfs:comment "A person's oversight of an organization or a service she can act for, evidenced by the agent's oversight delegation to her (its digest is the record). Standing, never authority: what she MAY do as it is what its grants say." .
+# Spec 410 §8 — the VAULT form of a relationship: one credential, two signatures, two copies. Each principal holds
+# its side; nothing is one party's alone if two signed it. The chain edge (where a gate must follow it) carries only
+# this credential's digest; the public projection (spec 410 §4) reduces it to a blinded commitment.
+ap:RelationshipCredential a owl:Class ;
+    rdfs:subClassOf prov:Entity ;
+    rdfs:label "RelationshipCredential" ;
+    rdfs:comment "A countersigned record of a relationship (has-member ⇒ aporg:OrganizationMembership, steward-of ⇒ ap:Stewardship, chartered-under ⇒ ap:charteredUnder), held by BOTH parties in their own vaults and presented under grant from the holder's vantage point — the counterparty verifies the other party's signature against its Smart Agent and reads no chain edge. What it is NOT: authority (it grants nothing), the chain record (that stays where a gate follows it), or a one-sided claim (relationships.data is the person's private index; this is what the organization agreed)." .
+ap:relationshipKind a owl:DatatypeProperty ;
+    rdfs:domain ap:RelationshipCredential ; rdfs:range xsd:string ;
+    rdfs:label "relationshipKind" .
+ap:revokes a owl:ObjectProperty ;
+    rdfs:domain prov:Entity ; rdfs:range ap:RelationshipCredential ;
+    rdfs:label "revokes" ;
+    rdfs:comment "A two-sided (or labelled-unilateral) revocation of a relationship credential, written to both vaults; the departing party keeps her copy and the revocation, never the organization's records." .
+
+ap:steward a owl:ObjectProperty ;
+    rdfs:domain ap:Stewardship ; rdfs:range ap:PersonAgent ;
+    rdfs:label "steward" ;
+    rdfs:comment "The person who stewards." .
+ap:stewarded a owl:ObjectProperty ;
+    rdfs:domain ap:Stewardship ; rdfs:range ap:Agent ;
+    rdfs:label "stewarded" ;
+    rdfs:comment "The organization-class or service-class agent stewarded (never a person — a person is not stewarded, she is)." .
+ap:stewardshipDelegation a owl:DatatypeProperty ;
+    rdfs:domain ap:Stewardship ; rdfs:range xsd:string ;
+    rdfs:label "stewardshipDelegation" ;
+    rdfs:comment "The digest of the oversight delegation that evidences the stewardship (spec 246) — the record, not the authority." .
+
+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.""" .
+
+# ─── Which of my people am I? (the custodian's own choice over the agents they custody) ───────────
+# A CUSTODIAN IS NOT LIMITED TO ONE PERSON. Somebody walks a long trail and is known on it as Summit;
+# somebody writes under another name; somebody plays a part in a game for six evenings and wants what that
+# character learned kept in its own vault rather than muddled into theirs. Each is a person-shaped agent of
+# its own — its own name, its own card, its own memory of the people it has met under that name — and all of
+# them are custodied by the same human, who can move between them.
+#
+# Until this existed nothing could answer "which of these is you". The Home resolved whichever agent was
+# linked to the credential FIRST, which is an accident of enrolment order rather than an answer, and every
+# surface that had to choose either guessed or asked. Guessing about identity is the one place a system must
+# not.
+#
+# WHY IT HANGS OFF ap:CustodyMember. The choice is not a fact about an agent in the abstract — an agent is
+# nobody's default, it is THIS credential's default. The pair (credential, agent) already has a public,
+# chain-reproducible name in this ontology, and that pair is exactly what is being chosen between. The choice
+# is modelled as a SITUATION of its own rather than a property ON that token, because CustodyMember answers
+# exactly one question by design and must go on answering only that one.
+ap:DefaultPersonChoice a owl:Class ;
+    rdfs:subClassOf apsit:Situation ;
+    rdfs:label "DefaultPersonChoice" ;
+    rdfs:comment """Of the person agents one credential custodies, the one that credential's Home opens as.
+
+      A PREFERENCE, never authority. Moving to another of your people is a change of CONTEXT, not of power:
+      every act still runs under a mandate signed for that request, by that agent, and no verifier reads
+      this. What it removes is a question only the custodian can answer, asked on every connection.
+
+      AT MOST ONE PER CREDENTIAL, and a reader that finds none falls back to however the credential resolved
+      before rather than inventing an answer — the absence of a choice is not a choice.
+
+      IT SAYS NOTHING ABOUT THE AGENTS THEMSELVES. A person agent that is somebody's default is not thereby
+      more real, more authoritative or more them than the others; the others are equally theirs, equally
+      person-shaped, and equally able to hold an organization, a service or a vault of their own.""" .
+ap:choiceOfCustody a owl:ObjectProperty ;
+    rdfs:domain ap:DefaultPersonChoice ; rdfs:range ap:CustodyMember ;
+    rdfs:label "choiceOfCustody" ;
+    rdfs:comment "The (credential, agent) pair chosen — the custody token, which is the only public, chain-reproducible name the relation has." .
+ap:choiceOfPerson a owl:ObjectProperty ;
+    rdfs:domain ap:DefaultPersonChoice ; rdfs:range ap:PersonAgent ;
+    rdfs:label "choiceOfPerson" ;
+    rdfs:comment "The person agent chosen, named directly so a reader does not have to reverse a hash to know who was meant." .
+ap:chosenAt a owl:DatatypeProperty ;
+    rdfs:domain ap:DefaultPersonChoice ; rdfs:range xsd:dateTime ;
+    rdfs:label "chosenAt" ;
+    rdfs:comment "When the custodian last chose. A later choice supersedes an earlier one; nothing is deleted, because which person somebody presented as at a given time is a fact about the past." .
+
+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." .