Skip to content

Platform Capability Log

The platform capability log is the canonical announcement record for newly available, changed, degraded, or retired platform capabilities.

It exists so operators, spoke repos, frontend surfaces, and agent teams can answer one plain question without reading every PR: what can the platform do now, and how should I subscribe to changes?

Current Feed

The feed is intentionally small for now. Each entry identifies the capability, the audiences that need to know, source artifacts, validation evidence, and the subscription subject. The target architecture is ontology-first: capability facts are authored in the platform self-model, loaded into Fuseki, then projected to platform.capability.changed.v1 on NATS. Later work can project that same source into RSS/Atom, webhooks, Fleet Console notifications, or GitHub issue comments.

Entry Format

Every capability announcement should include:

Field Purpose
id Stable announcement identifier.
announcedAt UTC timestamp when the capability was announced.
status planned, available, changed, degraded, or retired.
changeType Why the entry exists, such as receiver-ready or contract-shipped.
capabilityId Stable capability key that downstream systems can filter on.
title Human-readable announcement title.
summary Short explanation of what changed.
audiences Teams, surfaces, or repos expected to react.
sourceArtifacts Contracts, docs, reports, or code paths that define the capability.
validation Evidence used to trust the announcement.
adoption Issue template, routing, and done criteria for coding-agent teams.
subscribe Event/feed/issue pointers for follow-up.

Announcements

2026-05-31: UDA DataObject Runtime Receivers Available

Status: available
Change type: receiver-ready
Capability: uda.dataobject.runtime.receivers

backend-core can now consume the Forge UDA fixture families through the standard DataObject runtime route. The handoff backlog for the current fixture set is zero.

Audiences:

  • Forge builders producing receiver-ready fixture families.
  • backend-core implementers wiring DataObjects to UDA sources.
  • frontend-core consumers expecting stable typed object access.
  • platform operators watching UDA capability readiness.

Source artifacts:

  • docs/uda-data-connector-object-model.md
  • docs/forge-uda-generation-profile.md
  • docs/backend-core-object-model.md
  • contracts/uda-data-object-runtime.openapi.yaml
  • contracts/uda-data-connector.schema.json
  • contracts/uda-forge-fixture-index.schema.json
  • contracts/uda-contract-readiness.example.json

Validation evidence:

  • backend-core receiver compatibility checks passed.
  • backend-core Rust test suite passed.
  • backend-core Python receiver tests passed.
  • Forge UDA handoff validation passed.
  • Forge full suite passed.
  • Hub UDA fail-closed validator and tests passed.
  • Contract bundle check passed.

Subscribe/follow:

2026-05-31: HVFS Source-Control Foundation Planned

Status: planned
Change type: new-capability
Capability: hvfs.source-control.foundation

HVFS is the source-control substrate for the future untool.ai GitHub replacement. The first implementation path is lakeFS-backed metadata versioning over content-addressed object storage, exposed through UDA and a shared virtual filesystem client instead of local clone assumptions.

Audiences:

  • backend-core implementers adding the lakeFS/HVFS UDA connector.
  • commons-core implementers defining the agent-facing VFS client contract.
  • Fleet Console and platform operators watching workspace/version events.
  • coding-agent teams that need repository-like state without direct GitHub coupling.

Source artifacts:

Subscribe/follow:

2026-05-31: Platform Messaging Update System Planned

Status: planned
Change type: contract-shipped
Capability: platform.messaging.update-system

The platform now has a specified messaging update system: NATS JetStream for high-speed semantic updates, webhook projection for HTTPS subscribers, MCP discovery for coding agents, and GitHub as the durable evidence lane.

Audiences:

  • backend-core, commons-core, agentarmy-forge, frontend-core, and middle-core.
  • Fleet Console and platform operators.
  • agent coding systems subscribing through MCP, NATS, or webhook projections.

Source artifacts:

Subscribe/follow:

  • Capability NATS subject: platform.capability.changed.v1.
  • First MECE families: platform.capability.*, platform.adoption.*, platform.hvfs.*, fleet.agent.*, and platform.security.*.