trustgraph/specs
Cyber MacGeddon 2e83413cbe Add agent explainability instrumentation and unify envelope field naming
Addresses recommendations from the UX developer's agent experience report.
Adds provenance predicates, DAG structure changes, error resilience, and
a published OWL ontology.

Explainability additions:

- Tool candidates: tg:toolCandidate on Analysis events lists the tools
  visible to the LLM for each iteration (names only, descriptions in config)
- Termination reason: tg:terminationReason on Conclusion/Synthesis events
  (final-answer, plan-complete, subagents-complete)
- Step counter: tg:stepNumber on iteration events
- Pattern decision: new tg:PatternDecision entity in the DAG between
  session and first iteration, carrying tg:pattern and tg:taskType
- Latency: tg:llmDurationMs on Analysis events, tg:toolDurationMs on
  Observation events
- Token counts on events: tg:inToken/tg:outToken/tg:llmModel on
  Grounding, Focus, Synthesis, and Analysis events
- Tool/parse errors: tg:toolError on Observation events with tg:Error
  mixin type. Parse failures return as error observations instead of
  crashing the agent, giving it a chance to retry.

Envelope unification:

- Rename chunk_type to message_type across AgentResponse schema,
  translator, SDK types, socket clients, CLI, and all tests.
  Agent and RAG services now both use message_type on the wire.

Ontology:

- specs/ontology/trustgraph.ttl — OWL vocabulary covering all 26 classes,
  7 object properties, and 36+ datatype properties including new predicates.

DAG structure tests:

- tests/unit/test_provenance/test_dag_structure.py verifies the
  wasDerivedFrom chain for GraphRAG, DocumentRAG, and all three agent
  patterns (react, plan, supervisor) including the pattern-decision link.
2026-04-13 16:12:45 +01:00
..
api Update docs for 2.2 release (#766) 2026-04-07 22:24:59 +01:00
ontology Add agent explainability instrumentation and unify envelope field naming 2026-04-13 16:12:45 +01:00
websocket Update docs for 2.2 release (#766) 2026-04-07 22:24:59 +01:00
build-docs.sh Update API specs for 2.1 (#699) 2026-03-17 20:36:31 +00:00
README.md Add AsyncAPI spec for websocket (#613) 2026-01-15 11:57:16 +00:00

TrustGraph API Specifications

This directory contains formal specifications for the TrustGraph API Gateway.

Directory Structure

specs/
├── api/              # OpenAPI 3.1.0 specification for REST API
│   ├── openapi.yaml  # Main entry point
│   ├── paths/        # Endpoint definitions
│   ├── components/   # Reusable schemas, responses, parameters
│   └── security/     # Security scheme definitions
│
├── websocket/        # AsyncAPI 3.0.0 specification for WebSocket API
│   ├── asyncapi.yaml # Main entry point
│   ├── channels/     # Channel definitions
│   ├── components/   # Message and schema definitions
│   └── STREAMING.md  # Streaming patterns documentation
│
└── README.md         # This file

Specifications

REST API (OpenAPI 3.1.0)

Location: specs/api/openapi.yaml

The REST API specification documents:

  • 5 Global Services: config, flow, librarian, knowledge, collection-management
  • 16 Flow-Hosted Services: agent, RAG, embeddings, queries, loading, tools
  • Import/Export: Bulk data operations
  • Metrics: Prometheus monitoring

Features:

  • Modular structure with $ref to external files
  • Comprehensive request/response schemas
  • Authentication via Bearer tokens
  • Field naming in kebab-case

WebSocket API (AsyncAPI 3.0.0)

Location: specs/websocket/asyncapi.yaml

The WebSocket API specification documents:

  • Multiplexed async communication protocol
  • Request/response message envelopes with ID correlation
  • All services accessible via single WebSocket connection
  • Streaming response patterns

Features:

  • References REST API schemas (single source of truth)
  • Message-based routing (service + optional flow parameters)
  • Comprehensive streaming documentation
  • Full async/multiplexing behavior

Building Documentation

Prerequisites

npm install -g @redocly/cli @asyncapi/cli

Or use npx (no installation required).

Generate REST API Documentation

Using Redocly (HTML):

cd specs/api
npx @redocly/cli build-docs openapi.yaml -o ../../docs/api.html

Preview in browser:

cd specs/api
npx @redocly/cli preview-docs openapi.yaml

Opens interactive documentation at http://localhost:8080

Validate:

cd specs/api
npx @redocly/cli lint openapi.yaml

Generate WebSocket API Documentation

Using AsyncAPI (HTML):

cd specs/websocket
npx -p @asyncapi/cli asyncapi generate fromTemplate asyncapi.yaml @asyncapi/html-template@3.0.0 --use-new-generator -o /tmp/asyncapi-build -p singleFile=true --force-write
mv /tmp/asyncapi-build/index.html ../../docs/websocket.html
rm -rf /tmp/asyncapi-build

Notes:

  • The generator must run from the specs/websocket directory to properly resolve relative $ref paths to OpenAPI schemas
  • --use-new-generator flag enables generator v2 compatibility
  • -p singleFile=true parameter generates a single standalone HTML file

Validate:

cd specs/websocket
npx @asyncapi/cli validate asyncapi.yaml

Build All Documentation

Use the provided build script:

./specs/build-docs.sh

This generates:

  • docs/api.html - REST API documentation
  • docs/websocket.html - WebSocket API documentation

Viewing Documentation

After building:

REST API:

xdg-open docs/api.html
# or
firefox docs/api.html

WebSocket API:

xdg-open docs/websocket.html
# or
firefox docs/websocket.html

Schema Reuse

The WebSocket API specification references the REST API schemas using relative paths:

# In specs/websocket/components/messages/requests/AgentRequest.yaml
request:
  $ref: '../../../../api/components/schemas/agent/AgentRequest.yaml'

This ensures:

  • Single source of truth for all schemas
  • Consistency between REST and WebSocket APIs
  • Easy maintenance - update schemas in one place

Validation Status

Both specifications are validated and error-free:

  • OpenAPI: Validated with Redocly CLI
  • AsyncAPI: Validated with AsyncAPI CLI

Maintenance

Adding a New Service

  1. Create schemas in specs/api/components/schemas/{service-name}/

    • {ServiceName}Request.yaml
    • {ServiceName}Response.yaml
  2. Create path definition in specs/api/paths/ or specs/api/paths/flow/

  3. Add path to main spec in specs/api/openapi.yaml

  4. Create WebSocket message in specs/websocket/components/messages/requests/

    • Reference the OpenAPI request schema
  5. Add to ServiceRequest message in specs/websocket/components/messages/ServiceRequest.yaml

  6. Validate both specs:

    cd specs/api && npx @redocly/cli lint openapi.yaml
    cd specs/websocket && npx @asyncapi/cli validate asyncapi.yaml
    

Modifying an Existing Service

  1. Update schema in specs/api/components/schemas/{service-name}/

  2. Changes automatically apply to WebSocket spec via $ref

  3. Validate both specs to ensure consistency

Tools and Resources

OpenAPI Tools:

AsyncAPI Tools:

Online Validators:

API Version

Current version: 1.8.0

Version is specified in both:

  • specs/api/openapi.yamlinfo.version
  • specs/websocket/asyncapi.yamlinfo.version

Update both when releasing a new API version.