trustgraph/specs
cybermaggedon d2751553a3
Add agent explainability instrumentation and unify envelope field naming (#795)
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:16:42 +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 (#795) 2026-04-13 16:16:42 +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.