Platform Capability Events¶

Platform capabilities are authored in the untool.ai system ontology, loaded into Fuseki, and projected onto NATS as subscribable system messages.

The current docs-backed capability log remains the human-readable projection, but the source of truth should be the platform self-model:

ontology/platform-self-model/model/model.yaml
ontology/platform-self-model/model/instances.yaml
        |
        v
Fuseki named graph: https://agentarmy.dev/graphs/platform/capabilities
        |
        v
NATS JetStream subject: platform.capability.changed.v1
        |
        v
coding-agent teams, Fleet Console, adoption audit, RSS/webhook projections

Source Of Truth¶

Capability facts live in the platform self-model, not in a hand-maintained feed:

Ontology element	Purpose
`Capability`	The verb the platform provides.
`CapabilityAnnouncement`	A planned, available, changed, degraded, or retired capability fact.
`SystemMessageSubject`	The subscribable NATS subject carrying the announcement.
`capability-announcement-channel`	Relator tying announcement, capability, Fuseki, NATS, and subject together.

For the first capability, ann-uda-dataobject-runtime-receivers announces uda.dataobject.runtime.receivers and projects through platform.capability.changed.v1.

NATS Subject¶

Field	Value
Subject	`platform.capability.changed.v1`
CloudEvents type	`platform_capability.changed.v1`
Schema	`contracts/platform-capability-event.schema.json`
Example	`contracts/platform-capability-event.example.json`
Stream	`PLATFORM`
Replay	Keep the latest event per `capabilityId` so late subscribers can hydrate.

Subscribers should filter by data.capabilityId, data.status, or adoption-track repo.

For the split between durable GitHub messaging and high-speed MCP/NATS orchestration, see platform-capability-messaging.md.

Projection Contract¶

The projection service reads the Fuseki graph with SPARQL and publishes a CloudEvents-compatible JSON message to NATS. The first query can be a narrow construct/select around the announcement relator:

Implementation tracker: backend-core #168.

PREFIX self: <https://agentarmy.dev/self#>

SELECT ?announcement ?capability ?subject ?status ?changeType ?summary ?trackingIssue
WHERE {
  ?channel a self:capability-announcement-channel ;
    self:announcement ?announcement ;
    self:capability ?capability ;
    self:sourceOfTruth self:plat-fuseki ;
    self:messageBus self:plat-nats ;
    self:subject ?subject .

  ?announcement self:status ?status ;
    self:changeType ?changeType ;
    self:summary ?summary .

  OPTIONAL { ?announcement self:trackingIssueUrl ?trackingIssue . }
}

The message data must include:

ontology pointers: graph IRI, capability IRI, announcement IRI, and source path;
adoption pointers: hub rollup issue and per-repo adoption tracks;
validation and source artifacts from the capability announcement projection.

Subscriber Rules¶

Coding-agent teams subscribe to platform.capability.changed.v1.
Agents treat available and changed events as adoption candidates.
Agents treat planned events as spikes or design issues.
Agents treat degraded and retired events as mitigation or migration work.
Every adoption issue must name data.capabilityId.
Closing adoption still requires validation evidence; receiving an event is not proof.

Implementation Slices¶

Load the updated platform self-model into Fuseki.
Add a small projection job that queries Fuseki and publishes the schema-valid CloudEvent to NATS.
Extend tools/capability-adoption-audit.mjs to optionally read from Fuseki/NATS instead of the docs feed.
Add a Fleet Console subscriber view for current capability status and adoption state.
Project the same source into RSS/Atom or webhook notifications if human subscribers need them.