@agenticprimitives/ontology 1.0.0-alpha.18 → 1.0.0-alpha.19

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,124 @@
1
+ # T-box — orthogonal context facets + capability-map views (spec 330 W0 §4; spec 331).
2
+ #
3
+ # Implements docs/architecture/capability-architecture.md §3. The governing rule:
4
+ #
5
+ # A capability participates in SEVERAL facets of SEVERAL kinds. There is no forced
6
+ # single-parent hierarchy, and a capability MAP is a VIEW projected from the graph —
7
+ # never the class hierarchy. Presentation level lives on a CapabilityMapEntry, never
8
+ # on the capability.
9
+ #
10
+ # "Vertical" and "horizontal" are diagram orientations, not ontology. Nothing here
11
+ # authorizes anything: a facet is classification, and classification is never possession
12
+ # and never permission (capability-architecture.md §2 axiom 4).
13
+
14
+ @prefix apctx: <https://agenticprimitives.dev/ns/context#> .
15
+ @prefix aps: <https://agenticprimitives.dev/ns/skill#> .
16
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
17
+ @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
18
+ @prefix owl: <http://www.w3.org/2002/07/owl#> .
19
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
20
+ @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
21
+
22
+ apctx: a owl:Ontology ;
23
+ rdfs:label "Agentic Primitives — context facet ontology" ;
24
+ owl:versionInfo "0.1.0" ;
25
+ rdfs:seeAlso <https://agenticprimitives.dev/docs/architecture/capability-architecture.md> ;
26
+ rdfs:comment "Orthogonal classification facets for capabilities and executions, plus the capability-map VIEW vocabulary. Classification only — never identity, never authority." .
27
+
28
+ # ─── The facets (orthogonal; a capability may bear many of many kinds) ──────
29
+
30
+ apctx:ContextFacet a owl:Class ;
31
+ rdfs:label "ContextFacet" ;
32
+ rdfs:comment "Abstract parent of the orthogonal classification facets. NOT a taxonomy root: facets of different kinds are independent axes, and bearing one never implies bearing another." .
33
+
34
+ apctx:IndustryDomain a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
35
+ rdfs:label "IndustryDomain" ;
36
+ rdfs:comment "Economic or professional field (e.g. family-office advisory; agent-trust infrastructure)." .
37
+
38
+ apctx:KnowledgeDomain a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
39
+ rdfs:label "KnowledgeDomain" ;
40
+ rdfs:comment "Subject-matter partition (e.g. taxation; wealth transfer; discovery). A SUBJECT domain is never a capability — conflating them re-opens ADR-0051. This is the facet atl:focusAreas projects onto." .
41
+
42
+ apctx:ValueStreamStage a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
43
+ rdfs:label "ValueStreamStage" ;
44
+ rdfs:comment "Stage in an outcome lifecycle (assess → design → implement → monitor). A stage is never a separate capability from the ability it stages." .
45
+
46
+ apctx:BoundedContext a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
47
+ rdfs:label "BoundedContext" ;
48
+ rdfs:comment "Boundary of a consistent model + vocabulary with ONE accountable owner. Every capability has exactly one owning bounded context (architecture invariant 2) and may participate in many others." .
49
+
50
+ apctx:SharedSemanticDomain a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
51
+ rdfs:label "SharedSemanticDomain" ;
52
+ rdfs:comment "Semantics reused across most contexts: party, money/units, time, agreements, provenance." .
53
+
54
+ # The ONE bounded context THIS repo owns. Every capability needs exactly one accountable owner
55
+ # (invariant 2), and the substrate's own capabilities — Member Consultation, Consultation Routing,
56
+ # and the advisory-consult realization PARAMETER — are owned here, not by any downstream domain
57
+ # catalog. Advisory capabilities (adv:*) are owned by the New City catalog's own context, declared
58
+ # in that downstream repo (architecture §4, §9); they never point here.
59
+ apctx:SubstrateContext a apctx:BoundedContext ;
60
+ rdfs:label "Agentic-primitives substrate" ;
61
+ rdfs:comment "The bounded context of this repo's own coordination-substrate capabilities (spec 329 consult path and its realization machinery). Distinct from any downstream domain catalog: the substrate ships the machinery, a domain catalog owns its own capabilities in its own context." .
62
+
63
+ apctx:ControlDomain a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
64
+ rdfs:label "ControlDomain" ;
65
+ rdfs:comment "Cross-cutting governance: privacy (ADR-0040), audit, authority separation. A control domain constrains realizations; it never grants them." .
66
+
67
+ apctx:JurisdictionFacet a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
68
+ rdfs:label "JurisdictionFacet" ;
69
+ rdfs:comment "The legal/regulatory space a realization is scoped to, drawn from the GeoFeatureRegistry controlled vocabulary (spec 251). A jurisdiction is a CONTEXT of a capability, never a specialization of it: 'Spanish wealth tax' is wealth-and-transfer-tax analysis IN the ES jurisdiction facet, not a distinct ability." .
70
+
71
+ apctx:LanguageFacet a owl:Class ; rdfs:subClassOf apctx:ContextFacet ;
72
+ rdfs:label "LanguageFacet" ;
73
+ rdfs:comment "A natural language a realization can be conducted in, as a BCP-47 tag. Delivery context, never an ability: an advisor does not have a 'Spanish' capability." .
74
+
75
+ apctx:ContextProfile a owl:Class ;
76
+ rdfs:label "ContextProfile" ;
77
+ rdfs:comment "A named composition of facets scoping a capability or an execution (e.g. jurisdiction + knowledge domains + controls)." .
78
+
79
+ apctx:composedOfFacet a owl:ObjectProperty ;
80
+ rdfs:domain apctx:ContextProfile ; rdfs:range apctx:ContextFacet ;
81
+ rdfs:label "composedOfFacet" .
82
+
83
+ # ─── Classification (navigational; NEVER structural) ────────────────────────
84
+
85
+ apctx:classifiedBy a owl:ObjectProperty ;
86
+ rdfs:range apctx:ContextFacet ;
87
+ rdfs:label "classifiedBy" ;
88
+ rdfs:comment "Subject → facet. Navigational/reporting classification. Deliberately NOT rdfs:subClassOf: a capability bearing a facet is not a subclass of anything, and stacking facets must never produce a hierarchy." .
89
+
90
+ apctx:inJurisdiction a owl:ObjectProperty ;
91
+ rdfs:subPropertyOf apctx:classifiedBy ; rdfs:range apctx:JurisdictionFacet ;
92
+ rdfs:label "inJurisdiction" .
93
+
94
+ apctx:inLanguage a owl:ObjectProperty ;
95
+ rdfs:subPropertyOf apctx:classifiedBy ; rdfs:range apctx:LanguageFacet ;
96
+ rdfs:label "inLanguage" .
97
+
98
+ apctx:ownedByContext a owl:ObjectProperty ;
99
+ rdfs:range apctx:BoundedContext ;
100
+ rdfs:label "ownedByContext" ;
101
+ rdfs:comment "The ONE accountable owning bounded context. Exactly one per capability; sh:maxCount 1 in cbox/capability-catalog-shapes.shacl.ttl." .
102
+
103
+ # ─── Capability maps are VIEWS ──────────────────────────────────────────────
104
+
105
+ apctx:CapabilityMap a owl:Class ;
106
+ rdfs:label "CapabilityMap" ;
107
+ rdfs:comment "A named view projected from the architecture graph for presentation or reporting. A map is never the class hierarchy and never the source of composition." .
108
+
109
+ apctx:CapabilityMapEntry a owl:Class ;
110
+ rdfs:label "CapabilityMapEntry" ;
111
+ rdfs:comment "One capability's placement in ONE map. apctx:levelInMap lives HERE — the same capability may sit at different levels in different maps." .
112
+
113
+ apctx:hasMapEntry a owl:ObjectProperty ;
114
+ rdfs:domain apctx:CapabilityMap ; rdfs:range apctx:CapabilityMapEntry ;
115
+ rdfs:label "hasMapEntry" .
116
+
117
+ apctx:entryCapability a owl:ObjectProperty ;
118
+ rdfs:domain apctx:CapabilityMapEntry ; rdfs:range aps:Capability ;
119
+ rdfs:label "entryCapability" .
120
+
121
+ apctx:levelInMap a owl:DatatypeProperty ;
122
+ rdfs:domain apctx:CapabilityMapEntry ; rdfs:range xsd:integer ;
123
+ rdfs:label "levelInMap" ;
124
+ rdfs:comment "Presentation level within one map. Asserting this on an aps:Capability is a SHACL violation (cbox/capability-catalog-shapes.shacl.ttl NoLevelOnCapabilityShape)." .
@@ -0,0 +1,216 @@
1
+ # T-box — coordination vocabulary (spec 332 §3; ADR-0054).
2
+ #
3
+ # The Endeavor is the durable, multi-principal coordination Situation — the thing a person or org
4
+ # posts as a request ("issue", "work item", "case", "project" in product vocabulary) and a group
5
+ # coordinates to satisfy. Everything around it is REUSED, never re-minted: goals are apint:Intent,
6
+ # capability requirements are aps:Capability + assertion strengths (ADR-0053), execution is
7
+ # apful:Task / apexec:ServiceExecution, evidence is apatt:, conversation is fabric. What is new is
8
+ # the durable middle: shared plan, participation, allocation, commitment.
9
+ #
10
+ # ── W0 SUBSET (the execution.ttl rule) ───────────────────────────────────────────────────────────
11
+ # This module declares EXACTLY the spec-332 core subset — the classes the wave-1 package, the
12
+ # provenance projection, and the coverage ledger reference — PLUS apcoord:Recommendation, whose
13
+ # reader shipped with the spec-334 W4 agent-triage slice. The REST of the spec-333 vocabulary
14
+ # (DecisionRequest, Risk, CapacityOffer, EndeavorCollection, …) is SPECIFIED but NOT declared here:
15
+ # vocabulary minted ahead of a reader is a named mistake, and the coverage ledger carries each
16
+ # term's honest status instead. When spec 333's wave lands, it EXTENDS this file.
17
+ #
18
+ # ── The doctrine that governs everything below (ADR-0054 §4) ─────────────────────────────────────
19
+ # ALLOCATION IS NEVER AUTHORITY. capable / available / allocated / committed / authorized /
20
+ # performing / satisfied are SEVEN separate facts. No gate reads an apcoord: term; a Recommendation,
21
+ # a plan step, a participation role, or a commitment grants nothing — authority remains
22
+ # delegation ∩ entitlement ∩ policy, evaluated at the gate at the moment of use.
23
+
24
+ @prefix apcoord: <https://agenticprimitives.dev/ns/coordination#> .
25
+ @prefix apsit: <https://agenticprimitives.dev/ns/situation#> .
26
+ @prefix apint: <https://agenticprimitives.dev/ns/intent#> .
27
+ @prefix ap: <https://agenticprimitives.dev/ns/core#> .
28
+ @prefix p-plan: <http://purl.org/net/p-plan#> .
29
+ @prefix prov: <http://www.w3.org/ns/prov#> .
30
+ @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
31
+ @prefix owl: <http://www.w3.org/2002/07/owl#> .
32
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
33
+ @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
34
+
35
+ apcoord: a owl:Ontology ;
36
+ rdfs:label "Agentic Primitives — coordination ontology (spec 332 core subset)" ;
37
+ owl:versionInfo "0.1.0" ;
38
+ 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." ;
39
+ 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." .
40
+
41
+ # ═══ Intake + the Endeavor itself ════════════════════════════════════════════
42
+
43
+ apcoord:EndeavorRequest a owl:Class ;
44
+ rdfs:subClassOf prov:Entity ;
45
+ rdfs:label "EndeavorRequest" ;
46
+ 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." .
47
+
48
+ apcoord:Endeavor a owl:Class ;
49
+ rdfs:subClassOf apsit:Situation ;
50
+ rdfs:label "Endeavor" ;
51
+ 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." .
52
+
53
+ apcoord:OutcomeSpecification a owl:Class ;
54
+ rdfs:subClassOf prov:Entity ;
55
+ rdfs:label "OutcomeSpecification" ;
56
+ 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." .
57
+
58
+ apcoord:OutcomeCriterion a owl:Class ;
59
+ rdfs:subClassOf prov:Entity ;
60
+ rdfs:label "OutcomeCriterion" ;
61
+ 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." .
62
+
63
+ apcoord:EndeavorRelation a owl:Class ;
64
+ rdfs:label "EndeavorRelation" ;
65
+ 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." .
66
+
67
+ # ═══ The shared plan (P-Plan-grounded; see plan.ttl for the trichotomy) ═══════
68
+
69
+ apcoord:CoordinationPlan a owl:Class ;
70
+ rdfs:subClassOf p-plan:Plan ;
71
+ rdfs:label "CoordinationPlan" ;
72
+ 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." .
73
+
74
+ apcoord:PlanStep a owl:Class ;
75
+ rdfs:subClassOf p-plan:Step ;
76
+ rdfs:label "PlanStep" ;
77
+ 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." .
78
+
79
+ apcoord:PlanEdge a owl:Class ;
80
+ rdfs:label "PlanEdge" ;
81
+ rdfs:comment "Reified typed step relation: precedes (projects onto p-plan:isPrecededBy) | depends-on | alternative | condition | compensates | refines." .
82
+
83
+ apcoord:MilestoneDefinition a owl:Class ;
84
+ rdfs:subClassOf prov:Entity ;
85
+ rdfs:label "MilestoneDefinition" ;
86
+ rdfs:comment "A named convergence point DEFINED BY CRITERIA (OutcomeCriterion refs), not merely a date." .
87
+
88
+ apcoord:MilestoneAchievement a owl:Class ;
89
+ rdfs:subClassOf prov:Entity ;
90
+ rdfs:label "MilestoneAchievement" ;
91
+ rdfs:comment "Evidence that a milestone's criteria became true — references apatt: evidence; never a checkbox." .
92
+
93
+ # ═══ Participation lifecycle: proposal → allocation → commitment ══════════════
94
+
95
+ apcoord:EndeavorParticipation a owl:Class ;
96
+ rdfs:subClassOf apsit:Situation ;
97
+ rdfs:label "EndeavorParticipation" ;
98
+ 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." .
99
+
100
+ apcoord:ContributionProposal a owl:Class ;
101
+ rdfs:subClassOf prov:Entity ;
102
+ rdfs:label "ContributionProposal" ;
103
+ rdfs:comment "An offer to perform bounded PlanSteps. An offer binds nobody." .
104
+
105
+ apcoord:AllocationDecision a owl:Class ;
106
+ rdfs:subClassOf prov:Entity ;
107
+ rdfs:label "AllocationDecision" ;
108
+ 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." .
109
+
110
+ apcoord:ContributionCommitment a owl:Class ;
111
+ rdfs:subClassOf prov:Entity ;
112
+ rdfs:label "ContributionCommitment" ;
113
+ 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." .
114
+
115
+ # ═══ Agent triage (spec 333 §3 — W4 minimal slice; reader: @agenticprimitives/coordination /decisions) ═══
116
+
117
+ apcoord:Recommendation a owl:Class ;
118
+ rdfs:subClassOf prov:Entity ;
119
+ rdfs:label "Recommendation" ;
120
+ 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." .
121
+
122
+ # ═══ Execution context + adapter boundary ═════════════════════════════════════
123
+
124
+ apcoord:CoordinationContextSnapshot a owl:Class ;
125
+ rdfs:subClassOf prov:Entity ;
126
+ rdfs:label "CoordinationContextSnapshot" ;
127
+ 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." .
128
+
129
+ apcoord:ExternalObjectBinding a owl:Class ;
130
+ rdfs:subClassOf prov:Entity ;
131
+ rdfs:label "ExternalObjectBinding" ;
132
+ 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." .
133
+
134
+ # ═══ Properties ═══════════════════════════════════════════════════════════════
135
+
136
+ apcoord:adoptedFrom a owl:ObjectProperty ;
137
+ rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:EndeavorRequest ;
138
+ rdfs:label "adoptedFrom" ;
139
+ rdfs:comment "Provenance back to intake: which request this Endeavor was adopted from." .
140
+
141
+ apcoord:hasOutcomeSpecification a owl:ObjectProperty ;
142
+ rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:OutcomeSpecification ;
143
+ rdfs:label "hasOutcomeSpecification" .
144
+
145
+ apcoord:hasCriterion a owl:ObjectProperty ;
146
+ rdfs:domain apcoord:OutcomeSpecification ; rdfs:range apcoord:OutcomeCriterion ;
147
+ rdfs:label "hasCriterion" .
148
+
149
+ apcoord:hasRelation a owl:ObjectProperty ;
150
+ rdfs:domain apcoord:Endeavor ; rdfs:range apcoord:EndeavorRelation ;
151
+ rdfs:label "hasRelation" .
152
+
153
+ apcoord:relatedEndeavor a owl:ObjectProperty ;
154
+ rdfs:domain apcoord:EndeavorRelation ; rdfs:range apcoord:Endeavor ;
155
+ rdfs:label "relatedEndeavor" .
156
+
157
+ apcoord:relationKind a owl:ObjectProperty ;
158
+ rdfs:domain apcoord:EndeavorRelation ; rdfs:range skos:Concept ;
159
+ rdfs:label "relationKind" ;
160
+ rdfs:comment "depends-on | blocks | contributes-to | duplicates | supersedes | related-to | child-of (C-box codelist)." .
161
+
162
+ apcoord:plansEndeavor a owl:ObjectProperty ;
163
+ rdfs:domain apcoord:CoordinationPlan ; rdfs:range apcoord:Endeavor ;
164
+ rdfs:label "plansEndeavor" .
165
+
166
+ apcoord:edgeFrom a owl:ObjectProperty ;
167
+ rdfs:domain apcoord:PlanEdge ; rdfs:range apcoord:PlanStep ;
168
+ rdfs:label "edgeFrom" .
169
+
170
+ apcoord:edgeTo a owl:ObjectProperty ;
171
+ rdfs:domain apcoord:PlanEdge ; rdfs:range apcoord:PlanStep ;
172
+ rdfs:label "edgeTo" .
173
+
174
+ apcoord:edgeKind a owl:ObjectProperty ;
175
+ rdfs:domain apcoord:PlanEdge ; rdfs:range skos:Concept ;
176
+ rdfs:label "edgeKind" ;
177
+ rdfs:comment "precedes | depends-on | alternative | condition | compensates | refines (C-box codelist)." .
178
+
179
+ apcoord:achieves a owl:ObjectProperty ;
180
+ rdfs:domain apcoord:MilestoneAchievement ; rdfs:range apcoord:MilestoneDefinition ;
181
+ rdfs:label "achieves" .
182
+
183
+ apcoord:participatesIn a owl:ObjectProperty ;
184
+ rdfs:domain apcoord:EndeavorParticipation ; rdfs:range apcoord:Endeavor ;
185
+ rdfs:label "participatesIn" .
186
+
187
+ apcoord:proposesSteps a owl:ObjectProperty ;
188
+ rdfs:domain apcoord:ContributionProposal ; rdfs:range apcoord:PlanStep ;
189
+ rdfs:label "proposesSteps" .
190
+
191
+ apcoord:selectsProposal a owl:ObjectProperty ;
192
+ rdfs:domain apcoord:AllocationDecision ; rdfs:range apcoord:ContributionProposal ;
193
+ rdfs:label "selectsProposal" .
194
+
195
+ apcoord:acceptsAllocation a owl:ObjectProperty ;
196
+ rdfs:domain apcoord:ContributionCommitment ; rdfs:range apcoord:AllocationDecision ;
197
+ rdfs:label "acceptsAllocation" .
198
+
199
+ apcoord:bindsPlanRevision a owl:ObjectProperty ;
200
+ rdfs:domain apcoord:ContributionCommitment ; rdfs:range apcoord:CoordinationPlan ;
201
+ rdfs:label "bindsPlanRevision" ;
202
+ rdfs:comment "The EXACT adopted revision the commitment was signed against; a stale hash is a rejected commitment, never coerced forward." .
203
+
204
+ apcoord:planContentHash a owl:DatatypeProperty ;
205
+ rdfs:domain apcoord:CoordinationPlan ; rdfs:range xsd:string ;
206
+ rdfs:label "planContentHash" ;
207
+ rdfs:comment "Hash of steps+edges+milestones — the adoption, commitment, and adapter-provenance key. Same load-bearing role apexec:usedPlanContentHash plays for playbooks." .
208
+
209
+ apcoord:snapshotHash a owl:DatatypeProperty ;
210
+ rdfs:domain apcoord:CoordinationContextSnapshot ; rdfs:range xsd:string ;
211
+ rdfs:label "snapshotHash" .
212
+
213
+ apcoord:entryPoint a owl:ObjectProperty ;
214
+ rdfs:domain apcoord:EndeavorRequest ; rdfs:range skos:Concept ;
215
+ rdfs:label "entryPoint" ;
216
+ 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." .
@@ -19,7 +19,7 @@
19
19
 
20
20
  apdisc: a owl:Ontology ;
21
21
  rdfs:label "Agentic Primitives — discovery ontology" ;
22
- owl:versionInfo "0.1.0" ;
22
+ owl:versionInfo "0.2.0" ;
23
23
  rdfs:seeAlso <https://github.com/agentictrustlabs/agent-explorer/tree/main/apps/ontology/ontology> ;
24
24
  rdfs:comment "Vocabulary for GraphDB-backed discovery queries, evidence paths, trust determinations, graph snapshots, and intent candidate matching." .
25
25
 
@@ -147,3 +147,127 @@ apdisc:inferenceProfileId a owl:DatatypeProperty ;
147
147
  rdfs:domain apdisc:InferenceProfile ;
148
148
  rdfs:range xsd:string ;
149
149
  rdfs:label "inferenceProfileId" .
150
+
151
+ # ═══════════════════════════════════════════════════════════════════════════════════════════════
152
+ # Offerings (spec 286; ADR-0040 amended) — the crawled, HOST-ASSERTED service surface.
153
+ #
154
+ # WHY THIS BLOCK EXISTS. `apdisc:Offering` and its thirteen properties were written into the
155
+ # production knowledge graph by apps/demo-discovery-indexer and read back by
156
+ # apps/demo-discovery-mcp's `getOfferings` SPARQL — while being declared in NO T-box file. This is
157
+ # the same gap `tbox/profile.ttl` closed for `approf:`, and it is closed the same way: NOTHING IS
158
+ # MINTED HERE. Every IRI below is verbatim what the indexer already emits and the MCP already
159
+ # selects, because both are already in the live graph. Renaming any of them would be a migration,
160
+ # not an edit (ADR-0009; ADR-0013 — no read path for an undeclared term).
161
+ #
162
+ # ── What an Offering IS, and what it is NOT (capability-architecture.md §1) ─────────────────────
163
+ # An Offering is an `aps:CapabilityProtocolProjection`: ONE agent's public ADVERTISEMENT of ONE
164
+ # skill, crawled from that agent's own `GET /offerings?view=public` card. It is:
165
+ # · host-asserted, therefore the WEAKEST assertion strength (declared, never claimed, never
166
+ # demonstrated) — `apdisc:hasOffering` carries exactly as much authority as `atl:skills` does,
167
+ # which is none;
168
+ # · provenance-bearing by construction (sourceEndpoint + observedAt + cardDigest), because a
169
+ # crawled assertion whose observation point and time are unrecorded cannot be aged out or
170
+ # challenged;
171
+ # · NEVER an `apguide:AgentSkillPackage` reference. An Offering names no playbook (architecture
172
+ # §2 axiom 1: the `implementedBy exactly-1` error), and no gate may read one (axiom 4).
173
+ # ═══════════════════════════════════════════════════════════════════════════════════════════════
174
+
175
+ apdisc:Offering a owl:Class ;
176
+ rdfs:subClassOf prov:Entity , dul:InformationObject ;
177
+ rdfs:label "Offering" ;
178
+ rdfs:comment "One crawled, host-asserted public skill advertisement of ONE agent (spec 286). A projection of a capability, never the capability and never a plan. Its A-box IRI is deterministic per (chain, agent, skillId) — `urn:ap:offering:eip155:<chain>:<sa>:<skillId>` — so a re-crawl converges on the same subject instead of accumulating duplicates." ;
179
+ # NOT rdfs:subClassOf aps:CapabilityProtocolProjection, and the reason is load-bearing rather
180
+ # than fussy. An Offering plays the projection ROLE — it is an advertisement and nothing more —
181
+ # but `aps:CapabilityProtocolProjectionShape` requires `aps:declaresCapability` exactly once, and
182
+ # an Offering declares NOTHING resolvable: its `skillId` is whatever string the host put on its
183
+ # own card. Subclassing would make RDFS entailment sweep every crawled offering into that shape's
184
+ # target set, and the production graph would report thousands of violations that describe the
185
+ # ontology's wishful thinking rather than any defect in the data. When a host publishes a
186
+ # catalog capability id, the honest edge is an explicit `aps:declaresCapability` triple on the
187
+ # offering node — asserted per offering, never entailed from its class.
188
+ skos:related aps:CapabilityProtocolProjection .
189
+
190
+ # ── The two link predicates (agent ↔ child node) ────────────────────────────
191
+
192
+ apdisc:hasOffering a owl:ObjectProperty ;
193
+ rdfs:domain ap:Agent ;
194
+ rdfs:range apdisc:Offering ;
195
+ rdfs:label "hasOffering" ;
196
+ rdfs:comment "Agent → its crawled Offerings. FRESHNESS IS PER LINK PREDICATE: a crawl that fails returns no children at all and the indexer PRESERVES the existing offerings; only a successful crawl (possibly of zero offerings) refreshes them. Crawl failure is not zero offerings (ADR-0013)." .
197
+
198
+ apdisc:ofAgent a owl:ObjectProperty ;
199
+ rdfs:range ap:Agent ;
200
+ rdfs:label "ofAgent" ;
201
+ rdfs:comment "The child-node → agent backlink the projection store writes for EVERY first-class child node — Offerings, aptrust:TrustGraphEdge, apatt:Attestation. Deliberately left with NO rdfs:domain: constraining it to apdisc:Offering would, under RDFS entailment, type every attestation and every trust edge as an Offering. It is a generic backlink that happens to live in the apdisc: namespace because the offerings projector coined it first." .
202
+
203
+ # ── The thirteen Offering-node properties ───────────────────────────────────
204
+ # Order matches apps/demo-discovery-indexer/src/ontology.ts so the two files can be diffed by eye.
205
+
206
+ apdisc:skillId a owl:DatatypeProperty ;
207
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
208
+ rdfs:label "skillId" ;
209
+ rdfs:comment "The host's own id for the advertised skill, verbatim from its card. It is the offering's identity component (the A-box IRI derives from it), NOT a resolvable `aps:capabilityId` and NOT the on-chain keccak256 skillId — a host may advertise anything it likes here. An offering without one is not projected at all." .
210
+
211
+ apdisc:offeringName a owl:DatatypeProperty ;
212
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
213
+ rdfs:label "offeringName" ;
214
+ rdfs:comment "The card's human label for this skill." .
215
+
216
+ apdisc:offeringDescription a owl:DatatypeProperty ;
217
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
218
+ rdfs:label "offeringDescription" ;
219
+ rdfs:comment "The card's per-skill blurb. Its OWN term, and G8's third writer: this was emitted under `approf:description`, whose rdfs:domain is `approf:AgentProfile`, so every crawled Offering entailed itself to be an agent profile and an 'agent self-description' query that dropped its subject filter would sweep up host-asserted skill blurbs. A skill's blurb is not an agent's bio (agent-metadata-tiers.md: same field name ≠ same field)." .
220
+
221
+ apdisc:offeringVersion a owl:DatatypeProperty ;
222
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
223
+ rdfs:label "offeringVersion" ;
224
+ rdfs:comment "The host's version string for this skill, opaque and uninterpreted — never parsed, never ordered, never compared." .
225
+
226
+ apdisc:effect a owl:DatatypeProperty ;
227
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
228
+ rdfs:label "effect" ;
229
+ rdfs:comment "The card's self-declared effect class (e.g. read/write). AN OPEN VALUE SPACE ON PURPOSE: it is a host's claim about its own skill, so no codelist here could be authoritative, and pinning one would make an unrecognised value indistinguishable from an absent one. It informs presentation and ranking; it never gates anything (authority is delegation ∩ entitlement ∩ policy, at the gate)." .
230
+
231
+ apdisc:exposure a owl:DatatypeProperty ;
232
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
233
+ rdfs:label "exposure" ;
234
+ rdfs:comment "The card's self-declared exposure class. Same posture as apdisc:effect: host-asserted, open, advisory, never an authorization input." .
235
+
236
+ apdisc:family a owl:DatatypeProperty ;
237
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
238
+ rdfs:label "family" ;
239
+ rdfs:comment "The card's grouping label for related skills. A NAVIGATIONAL category (apctx:classifiedBy in spirit), never `aps:specializesCapability` — a host's grouping is not a statement that one ability is a narrower form of another." .
240
+
241
+ apdisc:requiredCapability a owl:DatatypeProperty ;
242
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
243
+ rdfs:label "requiredCapability" ;
244
+ rdfs:comment "MULTIVALUED — one triple per entry (`requiredCapabilities[]` on the card), which is why the MCP's getOfferings groups rows by offering node. What the host says a CALLER must present to invoke this skill. It is a published precondition, not a grant and not a check: the caller's actual authority is decided at the gate." .
245
+
246
+ apdisc:hasInputSchema a owl:DatatypeProperty ;
247
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
248
+ rdfs:label "hasInputSchema" ;
249
+ rdfs:comment "Whether the card advertises an input schema for this skill. STRING-TYPED, NOT BOOLEAN, and deliberately so: the indexer writes `String(o.hasInputSchema)` and the MCP reads `value === 'true'`, so the live value space is exactly the two lexical forms 'true' and 'false'. The C-box shape pins that set, because any third value reads as false in the MCP and would be a silent miss (ADR-0013). Declaring it xsd:boolean here would describe a graph that does not exist." .
250
+
251
+ apdisc:offeringStatus a owl:DatatypeProperty ;
252
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
253
+ rdfs:label "offeringStatus" ;
254
+ rdfs:comment "The card's lifecycle label for this skill. Host-asserted and open — an agent taking a skill down is a fact about its card, observable only at the next crawl." .
255
+
256
+ # ── Provenance of the crawl itself (ADR-0040 amended) ───────────────────────
257
+ # A host-asserted fact with no observation point and no observation time cannot be aged, diffed or
258
+ # challenged — it is a rumour with a subject IRI. These three are what make an Offering evidence.
259
+
260
+ apdisc:sourceEndpoint a owl:DatatypeProperty ;
261
+ rdfs:range xsd:string ;
262
+ rdfs:label "sourceEndpoint" ;
263
+ rdfs:comment "The `a2aEndpoint` the card was crawled from — the spec-280 node-keyed endpoint record, not a profile property. Also emitted on the agent's own offerings facet, hence NO rdfs:domain. The crawl requires the card's self-reported agentId to equal the SA being crawled: a host may never project offerings for a different agent." .
264
+
265
+ apdisc:observedAt a owl:DatatypeProperty ;
266
+ rdfs:range xsd:integer ;
267
+ rdfs:label "observedAt" ;
268
+ rdfs:comment "Unix SECONDS at which the card was observed (the card's own `observedAt` when it states one, else crawl time). Written as a bare Turtle integer, hence xsd:integer, not xsd:dateTime — declared as it is emitted, not as one might wish it were. Also emitted on the agent's offerings facet, hence no rdfs:domain." .
269
+
270
+ apdisc:cardDigest a owl:DatatypeProperty ;
271
+ rdfs:domain apdisc:Offering ; rdfs:range xsd:string ;
272
+ rdfs:label "cardDigest" ;
273
+ rdfs:comment "`sha256:<64 lowercase hex>` over the RAW card body the offering was parsed from. It is what makes 'did this host's advertisement change?' answerable without having stored the card: every offering crawled in one pass shares one digest, so a changed digest scopes exactly which advertisements must be re-examined. Same load-bearing role the pinned playbook content hash plays for a realization contract." .
@@ -0,0 +1,131 @@
1
+ # T-box — the EXECUTION plane: what actually happened (spec 330 §8, W0 remainder;
2
+ # capability-architecture.md §5). PROV-O-grounded throughout.
3
+ #
4
+ # ── Why this file exists now, and why it is SMALL ───────────────────────────────────────────────
5
+ # `cbox/capability-catalog-shapes.shacl.ttl` has shipped two realization contracts since spec 331,
6
+ # and both of them target classes that were declared NOWHERE:
7
+ # `apexec:MemberConsultationActivity`, `apexec:ConsultationSynthesisActivity`, `apexec:AgentRuntime`,
8
+ # `apexec:completionState`, `apexec:usedPlanContentHash`, `aprole:ConsultResponder`,
9
+ # `aprole:ConsultRouter`. Spec 330's checklist records the gap in as many words — "referenced by IRI
10
+ # in the contracts but not yet declared". A contract whose `sh:targetClass` names a class no module
11
+ # declares does not validate anything: it has an empty target set, and it passes by vacuity. That is
12
+ # precisely the "unenforceable contract" the catalog's own governing rule forbids.
13
+ #
14
+ # So this module declares EXACTLY the terms the shipped contracts reference, plus the one new term
15
+ # the parameterised advisory contract needs — and NOT the rest of spec 330 §8. The other twelve
16
+ # `apexec:` classes and the six environment specializations stay parked with W1, because nothing
17
+ # references them yet and a vocabulary minted ahead of a reader is the other half of the same
18
+ # mistake. When W1 lands its emission records, it extends this file; it does not rewrite it.
19
+ #
20
+ # ── The doctrine that governs everything below (architecture §2 axioms 5–6, §6) ─────────────────
21
+ # Provenance is EVIDENCE, never an authorization input. No gate may branch on an `apexec:` record.
22
+ # A role (`prov:hadRole`) is a CAPACITY, not a permission: `aprole:ConsultResponder` says what the
23
+ # runtime was doing, never that it was allowed to. Authority is delegation ∩ entitlement ∩ policy,
24
+ # evaluated at the gate at the moment of use, and it reads none of these terms.
25
+
26
+ @prefix apexec: <https://agenticprimitives.dev/ns/execution#> .
27
+ @prefix aprole: <https://agenticprimitives.dev/ns/role#> .
28
+ @prefix ap: <https://agenticprimitives.dev/ns/core#> .
29
+ @prefix aps: <https://agenticprimitives.dev/ns/skill#> .
30
+ @prefix apguide: <https://agenticprimitives.dev/ns/guidance#> .
31
+ @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
32
+ @prefix owl: <http://www.w3.org/2002/07/owl#> .
33
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
34
+ @prefix prov: <http://www.w3.org/ns/prov#> .
35
+ @prefix dul: <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#> .
36
+ @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
37
+
38
+ apexec: a owl:Ontology ;
39
+ rdfs:label "Agentic Primitives — execution ontology (W0 subset)" ;
40
+ owl:versionInfo "0.1.0" ;
41
+ rdfs:comment "The execution plane: activities that realize capabilities, the runtimes that bore responsibility, and the completion conditions that separate a realization from an attempt. W0 SUBSET — only the terms the shipped realization contracts reference. Spec 330 W1 extends it." ;
42
+ skos:scopeNote "WITHIN-AGENT plane (coordination-vs-orchestration.md). Orchestration sequences one agent's run: the executor's knowledge is local — harness-activated Agent Skill packages (apguide:AgentSkillPackage / SKILL.md, pinned by apexec:usedPlanContentHash) and injected tools — and the loop never queries naming/registry/apdisc: discovery. Distinct from apcoord: (the BETWEEN-AGENTS coordination plane); an apexec:ExecutionPlan compiles FROM an apcoord:PlanStep (plan.ttl), it never is one." .
43
+
44
+ aprole: a owl:Ontology ;
45
+ rdfs:label "Agentic Primitives — execution roles" ;
46
+ owl:versionInfo "0.1.0" ;
47
+ rdfs:comment "prov:Role individuals naming the CAPACITY an agent functioned in during an activity. A role is never an authorization (architecture §6): it answers 'what was it doing', not 'what was it allowed to do'." .
48
+
49
+ # ═══ Runtimes ═══════════════════════════════════════════════════════════════
50
+
51
+ apexec:AgentRuntime a owl:Class ;
52
+ rdfs:subClassOf prov:SoftwareAgent ;
53
+ rdfs:label "AgentRuntime" ;
54
+ rdfs:comment "The durable, IDENTIFIED runtime that bore responsibility for an activity — in this substrate, one Smart Agent's A2aTaskDO + InteractionsDO pair. NOT the environment it runs in, and NOT the model it called: a model is swapped without changing who is answerable. It `prov:actedOnBehalfOf` the ap:Agent whose authority it acted under, and that edge is what lets a realization be attributed to a party rather than to a process." .
55
+
56
+ # ═══ Activities ═════════════════════════════════════════════════════════════
57
+
58
+ apexec:ServiceExecution a owl:Class ;
59
+ rdfs:subClassOf prov:Activity , dul:Action ;
60
+ rdfs:label "ServiceExecution" ;
61
+ rdfs:comment "The externally meaningful activity that REALIZES a capability: an A2A task fulfillment, an assistant turn, an automation run. Distinct from the apful:Task that TRACKS it (architecture §2 axiom 3) and from the SkillExecutions it contains." .
62
+
63
+ apexec:SkillExecution a owl:Class ;
64
+ rdfs:subClassOf prov:Activity , dul:Action ;
65
+ rdfs:label "SkillExecution" ;
66
+ rdfs:comment "Work performed under ONE activated playbook, with a prov:qualifiedAssociation whose prov:hadPlan is that playbook. A sub-activity of a ServiceExecution, and never evidence of authority — activating a plan grants nothing (ADR-0050)." .
67
+
68
+ apexec:MemberConsultationActivity a owl:Class ;
69
+ rdfs:subClassOf apexec:SkillExecution ;
70
+ rdfs:label "MemberConsultationActivity" ;
71
+ rdfs:comment "ONE member agent's turn answering ONE routed consultation (spec 329 §3.2): it prov:used the ConsultRequestV1 and the member's own vault playbook, and prov:generated the answered-XOR-declined ConsultAnswerV1 with the actor pinned to the member. Depth-1 by construction — a member never re-routes. This is the target class of aps:MemberConsultationRealizationContract, and — when the turn carries apexec:routedOnCapability — also of the parameterised advisory contract: ONE activity, TWO realizations, which is the whole point of separating capability identity from activity type." .
72
+
73
+ apexec:ConsultationSynthesisActivity a owl:Class ;
74
+ rdfs:subClassOf apexec:ServiceExecution ;
75
+ rdfs:label "ConsultationSynthesisActivity" ;
76
+ rdfs:comment "The ORG side of a routed consultation (spec 329 §4/§6): structural eligibility, spec-281 ranking, fan-out, and the synthesis post whose attribution names each contributing member. A ServiceExecution rather than a SkillExecution because it composes several member turns plus its own playbook-guided synthesis." .
77
+
78
+ # ═══ Completion — the part that makes a contract about REALIZATION ══════════
79
+ # A capability is not a prov:Activity: the capability is what COULD be achieved, an activity is an
80
+ # occurrence that attempted it. Without a terminal state and an end time, a contract validates
81
+ # attempts and calls them realizations.
82
+
83
+ apexec:CompletionState a owl:Class ;
84
+ rdfs:subClassOf skos:Concept ;
85
+ rdfs:label "CompletionState" ;
86
+ rdfs:comment "The TERMINAL state of an activity. A closed codelist per contract (the contract pins which members it accepts with sh:in) — never an open string, because an unrecognised terminal state would read as 'not completed' in some consumers and 'completed' in others." .
87
+
88
+ apexec:Answered a apexec:CompletionState ;
89
+ rdfs:label "Answered" ;
90
+ rdfs:comment "The consulted member produced answer text attributed to itself." .
91
+
92
+ apexec:Declined a apexec:CompletionState ;
93
+ rdfs:label "Declined" ;
94
+ rdfs:comment "The consulted member explicitly declined. A CONFORMING REALIZATION, not a failure: the contract governs shape, not outcome, and treating a decline as non-realization would create an incentive to answer outside one's documented positions — the opposite of what the consult path exists for. `buildConsultAnswer` already makes answered-xor-declined structural." .
95
+
96
+ apexec:NoEligibleMember a apexec:CompletionState ;
97
+ rdfs:label "NoEligibleMember" ;
98
+ rdfs:comment "The ORG side terminated with an empty eligible set — nobody held both the consultability hint and the grant. A conforming realization of routing: correctly finding nobody is a result, and a router that hid it would be a router that guessed." .
99
+
100
+ apexec:completionState a owl:ObjectProperty ;
101
+ rdfs:domain prov:Activity ; rdfs:range apexec:CompletionState ;
102
+ rdfs:label "completionState" ;
103
+ 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." .
104
+
105
+ apexec:usedPlanContentHash a owl:DatatypeProperty ;
106
+ rdfs:domain prov:Activity ; rdfs:range xsd:string ;
107
+ rdfs:label "usedPlanContentHash" ;
108
+ rdfs:comment "The content hash of the playbook AS PINNED AT ACTIVATION — not as it reads now. LOAD-BEARING, NOT BOOKKEEPING: without it, 'which realizations must be re-examined now this playbook changed?' is unanswerable, and any demonstrated-capability signal computed over unpinned plans is unfalsifiable. Same role apdisc:cardDigest plays for a crawled advertisement." .
109
+
110
+ # ═══ The routing parameter — what an advisory realization is a realization OF ═══
111
+ #
112
+ # READ THIS BEFORE USING IT. This term is DECLARED, and is NOT EMITTED by anything today. It is the
113
+ # single datum that stands between the parameterised advisory realization contract and
114
+ # enforceability, and it is declared here so that the gap is a named, testable, one-field gap
115
+ # rather than a paragraph of prose. See cbox/capability-catalog-shapes.shacl.ttl §4.
116
+
117
+ apexec:routedOnCapability a owl:ObjectProperty ;
118
+ rdfs:subPropertyOf apexec:realizesCapability ;
119
+ rdfs:domain prov:Activity ; rdfs:range aps:Capability ;
120
+ rdfs:label "routedOnCapability" ;
121
+ rdfs:comment "The capability the ORG's routing selected this responder ON — the intersection of the question's resolved need and the responder's declared ids, which `rankConsultCandidates` already computes and then discards into a free-text evidence line. WHY IT MUST BE THE ROUTED-ON ID AND NOT MERELY A DECLARED ONE: an agent may declare up to twelve capabilities, so crediting a realization to every id it happens to declare would let one answered question realize twelve capabilities at once — turning the only assertion strength that cannot be faked by writing a string into one that can. A subproperty of apexec:realizesCapability because it is a realization claim with a stated basis, not a second kind of claim." .
122
+
123
+ # ═══ Roles — capacity, never permission ═════════════════════════════════════
124
+
125
+ aprole:ConsultResponder a prov:Role ;
126
+ rdfs:label "ConsultResponder" ;
127
+ rdfs:comment "The capacity a member's runtime functioned in while answering a routed consultation. The AUTHORITY for that turn is the consultability delegation checked at the member's gate; this term records what was done, and no gate reads it." .
128
+
129
+ aprole:ConsultRouter a prov:Role ;
130
+ rdfs:label "ConsultRouter" ;
131
+ rdfs:comment "The capacity an org's runtime functioned in while selecting members and synthesizing their attributed answers." .
package/tbox/identity.ttl CHANGED
@@ -43,6 +43,12 @@ apnam:resolvesTo a owl:ObjectProperty ;
43
43
  rdfs:domain apnam:NameFacet ;
44
44
  rdfs:range ap:Agent .
45
45
 
46
+ apnam:description a owl:DatatypeProperty ;
47
+ rdfs:label "description (name record)" ;
48
+ rdfs:domain apnam:NameFacet ;
49
+ rdfs:range xsd:string ;
50
+ rdfs:comment "atl:description read NODE-KEYED off AgentNameAttributeResolver — the description attached to the NAME RECORD, written by the name's owner. facet-registries G8: it shares the on-chain predicate key keccak256(\"atl:description\") with the SA-keyed profile description, but it is NOT the same fact and must NOT be emitted as approf:description, which tbox/profile.ttl reserves for the agent's own self-description. The two differ in author (name owner vs the agent itself), in subject (name node vs Smart Agent), and in survival: this one TRANSFERS WITH THE NAME and disappears if the name lapses, while approf:description survives a rename and exists for nameless agents (ADR-0010/0020). Projecting both under one IRI let the node-keyed loop clobber the SA-keyed one by loop order. Descriptive, low-authority, free text — never a filter target and never evidence." .
51
+
46
52
  aporg:memberOf a owl:ObjectProperty ;
47
53
  rdfs:label "memberOf" ;
48
54
  rdfs:domain ap:Agent ;