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.

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

1. 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

1. 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.

1. 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).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: AnthonyAlcaraz
• Source: AnthonyAlcaraz/agentic-graph-rag-skills
• License: MIT
• Homepage: https://www.oreilly.com/library/view/agentic-graphrag/9798341623163/

Install and usage instructions live in the source repository linked above.