Reflection Blueprints¶

Status: Core Concept
Prerequisites: Basic familiarity with Cognitive Traces
Related: Tripwires, Cognitive Traces, Runtime Governance Contracts, ACGP-3 Specification

TL;DR (30 Seconds)¶

A Reflection Blueprint is the policy configuration (YAML/JSON) that tells a Governance Steward what to evaluate and how strict to be: checks, CTQ metrics, thresholds, evidence requirements, tripwires, trust debt, and scoring.

Why it matters: Blueprints separate policy from code—so governance rules can be authored, reviewed, versioned, and rolled out like any other policy artifact.

What a Blueprint Is (Conceptually)¶

Think of a blueprint as the steward’s “policy program” for a class of actions/traces:

What to check: rule checks, metric checks, evidence constraints
How to score: CTQ aggregation + thresholds → interventions (ok, nudge, flag, escalate, block, halt)
What is non-negotiable: tripwires are fast, high-priority safety checks (often Tier 0/1)
How it evolves: versioning + inheritance + controlled rollout

Blueprints are intentionally human-readable and machine-executable.

What a Blueprint Is Not¶

Not a model prompt or agent “system prompt”
Not a runtime SLA (that’s handled by Runtime Governance Contracts in ACGP 1.1)
Not a Governance Tier definition (Governance Tiers define default enforcement strictness; blueprints define policy)

Where Blueprints Fit in the System¶

At runtime, a steward evaluates traces/actions against a blueprint:

Select applicable blueprint(s) (scope + inheritance)
Run tripwires first (fail-fast, high priority)
Run CTQ checks/metrics and compute final scores
Map score → intervention (using thresholds; stricter of blueprint vs Governance Tier defaults where applicable)
Emit decision + evidence/audit data

Relationship to Runtime Governance Contracts¶

Blueprints define what must be enforced; Runtime Governance Contracts define how deep and how fast those controls are applied for a specific request:

Blueprint: checks/metrics/tripwires/thresholds/evidence
Contract: risk_level, eval_tier, latency_budget_ms, preview evaluation-timeout behavior (fallback_on_timeout), not core profile-failure fallback

This keeps policy stable while allowing runtime performance/safety trade-offs when appropriate.

Minimal Example (Illustrative)¶

id: finance/customer_comms@1.2
version: "1.2.0"
description: "Customer-facing finance communications"
inherits: clarity.baseline@1.0

tripwires:
  - id: secrets_leak
    when: { hook: "output" }
    condition: "matches_regex(output, \"API_KEY_PATTERN\")"
    eval_tier: 0
    latency_budget_ms: 50
    on_fail: { decision: "halt", reason: "Potential secret in output" }

checks:
  - id: knowledge_grounding
    when: { hook: "output" }
    metric:
      name: "knowledge_grounding"
      weight: 0.25
      check: { type: "tool", args: { name: "source_validator" } }

scoring:
  thresholds:
    ok: 0.25
    nudge: 0.40
    escalate: 0.55
    # Risk > escalate -> block (implicit; halt is tripwire-only)

For the authoritative schema and semantics, see: - ACGP-3: Blueprints, Traces & Evaluation - Blueprint Schema reference