099 v1.26 Specialist Domains Documented

Event Bridge

Event bridge connecting knowledge pack observations to skill pipeline events — domain-specific observations route to skill promotion and agent activation.

Structured Data

Capability Metadata

Field	Value
ID	CAP-099
Version	v1.27
Domain	Specialist Domains
Group	Knowledge Packs
Status	Documented
Related	CAP-015, CAP-098, CAP-104
Architecture	Publish-subscribe event routing
Extends	CAP-015 inter-skill event system

Configuration Reference

Event type registry:

observation.recorded — knowledge pack observation captured

pattern.detected — knowledge pattern threshold reached

skill.activated — knowledge pack skill loaded into session

agent.composed — knowledge pack triggered agent composition

Bridge routing rules: knowledge-pack.* events route to domain-specific handlers; core skill events route to standard pipeline

Event priority levels: interrupt > active > passive (matching observation hook modes)

// Knowledge pack event routing
eventBridge.subscribe('knowledge-pack.*', (event: KPEvent) => {
  switch (event.type) {
    case 'observation.recorded':
      patternDetector.ingest(event.observation);
      break;
    case 'pattern.threshold.reached':
      promotionPipeline.evaluate(event.pattern);
      break;
    case 'skill.suggested':
      notifyUser(event.suggestion);
      break;
  }
});

Technical Specifications

Extends: inter-skill event system (CAP-015) with domain-aware routing

Isolation guarantee: knowledge pack events route to different handlers than core skill events — no cross-contamination

Extensibility: new domain types emit events without pipeline awareness — bridge handles routing transparently

Event subscriptions: declared in knowledge pack YAML frontmatter (CAP-104 format)

Overview

The Event Bridge decouples knowledge pack observations from skill pipeline behaviour, making each extensible independently. When a knowledge pack's observation hook fires (CAP-098), it emits an event — the bridge routes that event to the appropriate handler based on event type and domain. The skill pipeline never needs to know which knowledge pack emitted the event; it only sees a well-formed observation payload.

This publish-subscribe architecture allows any number of knowledge pack types to emit events without pipeline awareness. Adding a new specialist domain (say, OpenStack networking) requires only a new knowledge pack with observation hooks and event subscriptions — no modification to the core pipeline, no changes to the bridge routing rules, no new handler code for existing domains.

The bridge extends the inter-skill event system (CAP-015) with domain-aware routing. Core skill events continue to route through the standard pipeline; knowledge-pack.* events are intercepted by the bridge and routed to domain-specific handlers. The separation is clean: adding knowledge packs doesn't risk breaking existing skill event flows.

History

Without the bridge, knowledge packs had to directly call skill pipeline APIs — creating tight coupling that made it impossible to add new domain types without modifying core code. The first implementation of knowledge packs (pre-v1.26 prototype) directly called promotionPipeline.evaluate() from observation hook handlers. This worked for one domain, but adding a second domain required modifying the promotion pipeline to handle a new event shape.

The Event Bridge was introduced in v1.26 to break this coupling. By standardising knowledge pack events as knowledge-pack.* namespaced events on the existing CAP-015 event bus, the bridge could intercept and route them without the pipeline ever knowing a knowledge pack was involved. The publish-subscribe model was chosen over direct API calls specifically to enable horizontal scalability — ten simultaneous knowledge packs (one per specialist domain) can all emit events concurrently without coordination overhead.

Key Concepts

For Students & Teachers

Think of the Event Bridge like a telephone exchange. When a knowledge pack makes an "observation" (like noticing AGC assembly code), it doesn't call the pattern detector directly — that would be like calling someone's personal phone number. Instead, it posts a message to the exchange, which routes it to whoever should handle that type of message.

The benefit is that the knowledge pack doesn't need to know who handles its messages. The exchange (bridge) figures that out. And if you add a new knowledge pack for a new domain, it just posts to the same exchange — no rewiring needed.

Usage Examples

Example 1: Subscribing to knowledge pack events

// Subscribe to all knowledge pack observation events
eventBridge.subscribe('knowledge-pack.observation.recorded', (event) => {
  console.log(`Domain: ${event.domain}, Pack: ${event.pack}`);
  patternDetector.ingest(event.observation);
});

// Subscribe to promotion threshold events
eventBridge.subscribe('knowledge-pack.pattern.threshold.reached', (event) => {
  promotionPipeline.evaluate(event.pattern, event.learnerState);
});

Example 2: Declaring event subscriptions in knowledge pack YAML

# In knowledge pack frontmatter (CAP-104 format)
event_subscriptions:
  - event: "agc.instruction.executed"
    handler: record_pattern
  - event: "agc.dsky.input.received"
    handler: record_interaction_pattern