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.
When to Use
- Modeling events, contexts, conflicting data, or agent authority for reasoning
- Deciding which schema pattern (or composition) a knowledge shape needs
- Reviewing a graph schema for the missing temporal/scope/attribution link
- DevOps: deployment-history modeling, config-drift detection structure
Phrases: "event-centric", "contextual boundary", "multi-perspective",
"capability model", "schema design pattern", "temporal reasoning structure",
"model conflicting data", "config drift schema".
When NOT to Use
- Choosing the graph model class. Use
graph-model-selector (LPG vs RDF vs
hypergraph); this picks the schema pattern within a model.
- Runtime authorization enforcement. This validates that a Capability-Model
instance is well-formed;
capability-authorization-gate enforces the limit at
request time.
- Plain entity data. If the knowledge has no temporal, scope, perspectival,
or capability dimension, a simple node/edge is correct — no pattern needed.
Process
| Step |
Input |
Action |
Output |
Verification |
| 1 |
free-text knowledge-shape description |
lib.select_patterns(desc) |
[{pattern, score, matched_signals}, ...] desc |
top pattern matches the dominant signal class |
| 2 |
same |
lib.recommend_pattern(desc) |
{recommended, scores, contract, compose?} |
composition flagged when 2+ patterns score > 0 |
| 3 |
pattern + instance dict |
lib.validate_instance(pattern, instance) |
{valid, errors, pattern} |
required relationships/fields enforced per contract |
| 4 |
event instance |
lib.validate_instance("event_centric", ...) |
invalid if no temporal link |
enforces "event needs >= 1 temporal relationship" |
| 5 |
multi-perspective instance |
lib.validate_instance("multi_perspective", ...) |
invalid if a perspective lacks source/confidence or confidence outside [0,1] |
enforces attribution contract |
Rationalizations
| Agent rationalization |
Documented rebuttal |
| "I'll model the deployment as a property on the service node." |
Then "what deployments affected payment-service last week?" and "which commit deployed v2.3.1?" become impossible. The Event-Centric pattern makes the deployment a first-class node with temporal links precisely so the agent can reason about sequence and cause/effect (Example 3-14). |
| "Conflicting values mean my data is dirty — I'll pick one and move on." |
Forcing a single value loses the disagreement the agent needs to reason about. Multi-Perspective turns the contradiction into a structural advantage: each value is attributed to a source with confidence, and config-drift detection becomes a graph traversal instead of custom comparison logic. |
| "Context boundaries are bureaucratic — facts are facts." |
Context mixing is a named, common source of reasoning errors. Without validDuring / appliesTo, the agent applies Task-1's engineering-team facts to the wrong team or period. The boundary is what scopes the inference correctly. |
| "Capabilities are obvious from the code — I don't need them in the graph." |
"Obvious from the code" means not queryable at planning time. The Capability-Model makes authorization a node the agent checks BEFORE acting (refund $600 vs $500 limit -> escalate). Vague operational guidelines become concrete, queryable structure. |
| "The selector said compose two patterns — that's too complex." |
Ch3 explicitly recommends hybrids: an event can carry multi-perspective viewpoints, a capability can be bounded by contextual constraints. Composition is the intended design, not accidental complexity. |
Red Flags
- An event node with no
hasStartTime/hasPrecedingEvent/etc. It is an
entity wearing an event label; temporal queries will return nothing.
- A perspective with no confidence or a confidence outside [0,1]. The
attribution is unusable for source-weighted reasoning; the validator fails it.
- A context with
contains but no validDuring/appliesTo. No scope
boundary means no protection against context mixing — the pattern's whole job.
- A capability with no authorization-level. The agent cannot decide whether
to act or escalate; the self-awareness is incomplete.
- Selector recommends
None on a real modeling task. The description is too
vague — re-describe the temporal/scope/perspectival/capability dimension.
Non-Negotiable Verification
- Run the benchmark battery.
python cli.py benchmark must report 10/10:
- each signal class selects the right pattern; irrelevant text recommends None
- composition flagged when patterns co-occur
- validator passes well-formed instances and fails missing-temporal-link,
out-of-range-confidence, and missing-authorization-level instances
- Run the scenario.
python cli.py scenario devops-drift selects
event-centric for deployments, multi-perspective for drift, and shows a broken
event failing validation.
- Verify CLI help.
python cli.py --help exits 0 and prints this SKILL.md
description (so any harness can discover the skill from --help).
Security Posture
- Prompt injection. The knowledge-shape description is untrusted free text
tokenized against a fixed signal vocabulary - embedded instructions can at
most mis-select a pattern. Instance dicts are validated against fixed
contracts; field values are never executed or interpolated.
- Data exfiltration. No network calls, no file writes. Instance payloads
(forecasts, org data, capability limits) stay in-process and appear only in
the stdout validation report the caller owns.
- Privilege escalation. No shell invocation, no eval, no dynamic import.
Validating a Capability-Model instance as well-formed does NOT authorize it -
enforcement is capability-authorization-gate plus the platform's IAM.
Source Attribution
Distilled from Agentic GraphRAG (O'Reilly, by Anthony Alcaraz and Sam Julien) Ch3 — Knowledge
Representation, section "Schema Design Patterns": Event-Centric (Example 3-3),
Contextual-Boundary (Example 3-4), Multi-Perspective (Example 3-5),
Capability-Model, and the composition Tip. DevOps manifestations
(DeploymentEvent, Terraform-vs-AWS config drift) are from the chapter's
"Applying schema patterns to infrastructure" section (Example 3-14).
1---2name: schema-pattern-selector3description: Select and validate the four agent schema design patterns from Ch3 — Event-Centric (temporal reasoning), Contextual-Boundary (scope/validity boundaries), Multi-Perspective (contradictory viewpoints with attribution and confidence), and Capability-Model (agent self-awareness of authority limits). Given a free-text description of a knowledge shape, it scores which pattern(s) fit and flags composition when several apply; given a pattern instance, it validates the required relationships/fields without which the pattern is broken. Use when modeling knowledge for agent reasoning, when deciding how to structure events / contexts / conflicting data / agent authority, or when reviewing a schema for the missing temporal- or attribution-relationship that breaks the pattern. NOT for choosing the graph model class (use graph-model-selector), NOT for runtime authorization enforcement (use capability-authorization-gate), NOT for entity-centric data with no temporal/perspectival/scope dimension (a plain node is fine).4---56# Schema Pattern Selector78## Overview910Effective agent reasoning begins with schema patterns designed for machine11cognition across temporal, contextual, and perspectival dimensions. Ch3 names12four:1314- **Event-Centric** — structure knowledge around occurrences, not static15 entities. A `Meeting` event with participants, start/end timestamps, location,16 and `hasPrecedingEvent` / `hasFollowingEvent` links. Enables "what meetings17 did Alice attend before the project review?" In DevOps: a `DeploymentEvent`18 node with timestamp + git commit + affected services (Example 3-14).19- **Contextual-Boundary** — encapsulate information within explicit scopes. A20 `Context(Project-X)` that `contains` tasks, is `validDuring` a time range, and21 `appliesTo` a team. Prevents context mixing — the agent won't apply Task-1's22 facts to the wrong team or period.23- **Multi-Perspective** — model contradictory viewpoints with attribution. A24 `Revenue-Forecast` where Finance says 10M (confidence 0.8) and Sales says 12M25 (confidence 0.7), each `according-to` a source. In DevOps: config drift where26 Terraform-state and AWS-api are two perspectives on the same setting.27- **Capability-Model** — represent the agent's own capabilities, requirements,28 and authorization limits as queryable nodes. A support agent that can answer29 product questions (Public) but needs Supervisor authorization and a $500 limit30 to process refunds.3132The selector matches a knowledge-shape description to the fitting pattern(s),33flagging composition when several apply (Ch3 Tip: an event can carry34multi-perspective viewpoints; a capability can be bounded by contextual35constraints). The validator enforces each pattern's contract — the36relationships and fields without which the pattern is broken: an event MUST37have a temporal link (else it is just an entity); a context MUST declare a38scope boundary; every perspective MUST attribute its value to a source with39confidence in [0,1] (else contradiction-handling loses its attribution); every40capability MUST declare an authorization level.4142## When to Use4344- Modeling events, contexts, conflicting data, or agent authority for reasoning45- Deciding which schema pattern (or composition) a knowledge shape needs46- Reviewing a graph schema for the missing temporal/scope/attribution link47- DevOps: deployment-history modeling, config-drift detection structure4849Phrases: "event-centric", "contextual boundary", "multi-perspective",50"capability model", "schema design pattern", "temporal reasoning structure",51"model conflicting data", "config drift schema".5253## When NOT to Use5455- **Choosing the graph model class.** Use `graph-model-selector` (LPG vs RDF vs56 hypergraph); this picks the schema pattern within a model.57- **Runtime authorization enforcement.** This validates that a Capability-Model58 instance is well-formed; `capability-authorization-gate` enforces the limit at59 request time.60- **Plain entity data.** If the knowledge has no temporal, scope, perspectival,61 or capability dimension, a simple node/edge is correct — no pattern needed.6263## Process6465| Step | Input | Action | Output | Verification |66|------|-------|--------|--------|--------------|67| 1 | free-text knowledge-shape description | `lib.select_patterns(desc)` | `[{pattern, score, matched_signals}, ...]` desc | top pattern matches the dominant signal class |68| 2 | same | `lib.recommend_pattern(desc)` | `{recommended, scores, contract, compose?}` | composition flagged when 2+ patterns score > 0 |69| 3 | pattern + instance dict | `lib.validate_instance(pattern, instance)` | `{valid, errors, pattern}` | required relationships/fields enforced per contract |70| 4 | event instance | `lib.validate_instance("event_centric", ...)` | invalid if no temporal link | enforces "event needs >= 1 temporal relationship" |71| 5 | multi-perspective instance | `lib.validate_instance("multi_perspective", ...)` | invalid if a perspective lacks source/confidence or confidence outside [0,1] | enforces attribution contract |7273## Rationalizations7475| Agent rationalization | Documented rebuttal |76|------------------------|--------------------|77| "I'll model the deployment as a property on the service node." | Then "what deployments affected payment-service last week?" and "which commit deployed v2.3.1?" become impossible. The Event-Centric pattern makes the deployment a first-class node with temporal links precisely so the agent can reason about sequence and cause/effect (Example 3-14). |78| "Conflicting values mean my data is dirty — I'll pick one and move on." | Forcing a single value loses the disagreement the agent needs to reason about. Multi-Perspective turns the contradiction into a structural advantage: each value is attributed to a source with confidence, and config-drift detection becomes a graph traversal instead of custom comparison logic. |79| "Context boundaries are bureaucratic — facts are facts." | Context mixing is a named, common source of reasoning errors. Without `validDuring` / `appliesTo`, the agent applies Task-1's engineering-team facts to the wrong team or period. The boundary is what scopes the inference correctly. |80| "Capabilities are obvious from the code — I don't need them in the graph." | "Obvious from the code" means not queryable at planning time. The Capability-Model makes authorization a node the agent checks BEFORE acting (refund $600 vs $500 limit -> escalate). Vague operational guidelines become concrete, queryable structure. |81| "The selector said compose two patterns — that's too complex." | Ch3 explicitly recommends hybrids: an event can carry multi-perspective viewpoints, a capability can be bounded by contextual constraints. Composition is the intended design, not accidental complexity. |8283## Red Flags8485- **An event node with no `hasStartTime`/`hasPrecedingEvent`/etc.** It is an86 entity wearing an event label; temporal queries will return nothing.87- **A perspective with no confidence or a confidence outside [0,1].** The88 attribution is unusable for source-weighted reasoning; the validator fails it.89- **A context with `contains` but no `validDuring`/`appliesTo`.** No scope90 boundary means no protection against context mixing — the pattern's whole job.91- **A capability with no authorization-level.** The agent cannot decide whether92 to act or escalate; the self-awareness is incomplete.93- **Selector recommends `None` on a real modeling task.** The description is too94 vague — re-describe the temporal/scope/perspectival/capability dimension.9596## Non-Negotiable Verification97981. **Run the benchmark battery.** `python cli.py benchmark` must report 10/10:99 - each signal class selects the right pattern; irrelevant text recommends None100 - composition flagged when patterns co-occur101 - validator passes well-formed instances and fails missing-temporal-link,102 out-of-range-confidence, and missing-authorization-level instances1032. **Run the scenario.** `python cli.py scenario devops-drift` selects104 event-centric for deployments, multi-perspective for drift, and shows a broken105 event failing validation.1063. **Verify CLI help.** `python cli.py --help` exits 0 and prints this SKILL.md107 description (so any harness can discover the skill from --help).108109## Security Posture110111- **Prompt injection.** The knowledge-shape description is untrusted free text112 tokenized against a fixed signal vocabulary - embedded instructions can at113 most mis-select a pattern. Instance dicts are validated against fixed114 contracts; field values are never executed or interpolated.115- **Data exfiltration.** No network calls, no file writes. Instance payloads116 (forecasts, org data, capability limits) stay in-process and appear only in117 the stdout validation report the caller owns.118- **Privilege escalation.** No shell invocation, no eval, no dynamic import.119 Validating a Capability-Model instance as well-formed does NOT authorize it -120 enforcement is capability-authorization-gate plus the platform's IAM.121122## Source Attribution123124Distilled from *Agentic GraphRAG* (O'Reilly, by Anthony Alcaraz and Sam Julien) Ch3 — Knowledge125Representation, section "Schema Design Patterns": Event-Centric (Example 3-3),126Contextual-Boundary (Example 3-4), Multi-Perspective (Example 3-5),127Capability-Model, and the composition Tip. DevOps manifestations128(DeploymentEvent, Terraform-vs-AWS config drift) are from the chapter's129"Applying schema patterns to infrastructure" section (Example 3-14).
AnthonyAlcaraz