schema-pattern-selector

Schema Pattern Selector

Overview

Effective agent reasoning begins with schema patterns designed for machine cognition across temporal, contextual, and perspectival dimensions. Ch3 names four:

• Event-Centric — structure knowledge around occurrences, not static entities. A Meeting event with participants, start/end timestamps, location, and hasPrecedingEvent / hasFollowingEvent links. Enables "what meetings did Alice attend before the project review?" In DevOps: a DeploymentEvent node with timestamp + git commit + affected services (Example 3-14).
• Contextual-Boundary — encapsulate information within explicit scopes. A Context(Project-X) that contains tasks, is validDuring a time range, and appliesTo a team. Prevents context mixing — the agent won't apply Task-1's facts to the wrong team or period.
• Multi-Perspective — model contradictory viewpoints with attribution. A Revenue-Forecast where Finance says 10M (confidence 0.8) and Sales says 12M (confidence 0.7), each according-to a source. In DevOps: config drift where Terraform-state and AWS-api are two perspectives on the same setting.
• Capability-Model — represent the agent's own capabilities, requirements, and authorization limits as queryable nodes. A support agent that can answer product questions (Public) but needs Supervisor authorization and a $500 limit to process refunds.

The selector matches a knowledge-shape description to the fitting pattern(s), flagging composition when several apply (Ch3 Tip: an event can carry multi-perspective viewpoints; a capability can be bounded by contextual constraints). The validator enforces each pattern's contract — the relationships and fields without which the pattern is broken: an event MUST have a temporal link (else it is just an entity); a context MUST declare a scope boundary; every perspective MUST attribute its value to a source with confidence in [0,1] (else contradiction-handling loses its attribution); every capability MUST declare an authorization level.