Interactive Demos

CIRCUIT in Action

Explore the framework's core concepts interactively. The full dashboard reference implementation will be available with the GitHub release. Demos expand as source code is contributed.

Demo 1

Circuit Risk Score Calculator

Compute a CRS for any model configuration. Adjust the sliders to see how raising IMS or lowering consequence weight changes the band.

// CRS Calculator
15
AMBER
3 × (6 − 1) × 1 = 15
How to interpret

Green (1–12): Standard approval. Amber (13–47): AIGC review required. Red (48–96): CISO sign-off + remediation plan. Purple (97–120): Blocked — not deployable.

Demo 2

IMS Level Explorer

Understand what evidence is required at each Interpretability Maturity Score level, including tooling references and model category ceilings.

0
Opaque
No interpretability evidence on file. The default. Vendor will not discuss weights, features, or circuits. CRS uses maximum interpretability deficit multiplier (6).
Tooling: None required  ·  Available to: A, B, C
1
Behavioral Observability
Inputs, outputs, latency, and user-visible behavior are logged and monitored. Guardrails, DLP, and output filters in place. This is where most enterprise AI lives today.
Tooling: Any logging/monitoring stack  ·  Ceiling for: C
2
Post-hoc Explainability
SHAP, LIME, integrated gradients, attention visualizations, counterfactuals. Evidence that the model's output can be attributed, imperfectly, to input features. Required for SR 11-7 conceptual soundness in classical ML.
Tooling: SHAP, Captum, InterpretML  ·  Ceiling for: C  ·  Available to: A, B
3
Feature-level Inspection
Sparse autoencoders or transcoders trained on the model's internals. Specific internal features correspond to specific concepts and can be monitored in production. Probing-based backdoor detection lands here.
Tooling: Gemma Scope 2, Neuronpedia, SAE Lens  ·  Ceiling for: B  ·  Available to: A
4
Circuit-level Inspection
Attribution graphs, weight-sparse architectures, or equivalent causal circuit evidence for the behaviors that matter to your use case. Circuits are named, sized, and causally tested.
Tooling: circuit-tracer, openai/circuit-sparsity, Goodfire Ember  ·  Available to: A only
5
Continuous Interpretability
IMS 4 evidence integrated into CI/CD. Every model update produces a circuit diff. KPI drift triggers alerts. Red team results are fed back into circuit monitoring. This is where we are going.
Tooling: Custom + Ember enterprise + Neuronpedia enterprise  ·  Available to: A only

Demo 3

Registry Schema Example

A sample CIRCUIT registry entry for a Category A fraud classification model. Full YAML schema with JSON Schema validators is available on GitHub.

circuit_registry_entry.yaml — Category A · High Risk · Amber Band
circuit_registry_entry:
  version: "1.1.0"

  # ── Section 1: Identity ──────────────────────────────────────────
  identity:
    model_id: "fraud-classifier-v3"
    name: "Real-Time Fraud Scoring v3 (Gemma-3 9B fine-tune)"
    vendor: "internal"             # open weights, self-hosted
    category: "A"                  # A | B | C
    risk_tier: "High"              # Low | Moderate | High | Critical
    owner: "security-eng@company.com"
    consequence: "Automated"       # Advisory..Catastrophic (DCW 3)
    business_process: "Real-time transaction fraud detection"
    upstream_dependencies: ["gemma-3-9b", "feature-store-v2"]
    hosting_location: "aws-us-east-1 / EKS prod cluster"
    data_classification: "PII, financial"

  # ── Section 2: Maturity ──────────────────────────────────────────
  maturity:
    ims: 3
    ims_ceiling: 5                 # Category A ceiling
    evidence:
      - {artifact: "fraud_sae_gemma3_9b_v3.pkl", type: sparse_autoencoder,
         date: "2026-03-15", hash: "a3f8c2...", location: "s3://registry/fraud/"}
    level_history:
      - {from_level: 1, to_level: 3, date: "2026-03-15",
         evidence_artifact: "fraud_sae_gemma3_9b_v3.pkl"}

  # ── Section 3: Circuit Inventory ─────────────────────────────────
  circuit_inventory:
    - {name: "fraud_signal_primary", behavior: "Main fraud detection",
       size_nodes: 84, edge_count: 318, monosemanticity: 0.87,
       robustness: 0.94, artifact_link: "fraud_sae_gemma3_9b_v3.pkl#c0042"}

  # ── Section 4: KPI Baseline ──────────────────────────────────────
  kpi_baseline:
    circuit_size: 84               # ≤ 100 ✓
    edge_count: 318                # ≤ 500 ✓
    monosemanticity: 0.87          # ≥ 0.70 target ✓
    robustness: 0.94               # ≥ 0.90 ✓
    stability_across_versions: 0.91 # ≥ 0.75 ✓
    acfr_last_quarter: 0           # count of P1 bypasses; Rule 7 trigger ≥ 1
    measurement_date: "2026-03-20"
    methodology: "SAE concept-purity + adversarial suite"
    time_series: []

  # ── Section 5: Vendor Transparency ──────────────────────────────
  vendor_transparency:
    questionnaire_date: "2026-03-01"
    questionnaire_version: "1.0"
    vendor_contact: "internal — n/a"
    responses: []                  # 29 responses (see Appendix C)
    section_scores: {A: 100, B: 89, C: 100, D: 83}
    overall_score: 93
    rule_8_status: "complete"      # complete|vendor_declined|pending|nonresponsive
    outreach_attempts: []
    nonresponsive_since: null

  # ── Section 6: Red Team ──────────────────────────────────────────
  red_team:
    last_engagement_date: "2026-02-14"
    next_scheduled_date: "2026-08-14"
    methodology: "Circuit-aware red team"
    mitre_atlas_coverage: ["AML.T0051", "AML.T0043", "AML.T0018"]
    findings: []

  # ── Section 7: Compensating Controls ───────────────────────────
  compensating_controls:
    required_if_band: ["red"]      # mandatory at Red; recommended at Amber
    controls:
      - "Output rate limiting (100 req/min per tenant)"
      - "PII output filter (DLP v2)"
      - "Canary deployment for model updates"

  # ── Section 8: Lifecycle ─────────────────────────────────────────
  lifecycle:
    deployment_date: "2025-09-01"
    material_updates: []
    planned_retirement_date: null
    rollback_procedure: "Blue/green to v2; 5-min cutover"
    incident_history: []
    retention_expires: "2029-09-01" # minimum 3 years (Rule 10)
    registry_version: "1.1.0"
    last_reviewed: "2026-04-01"

  # ── Computed Fields (derived; not manually entered) ──────────────
  crs:
    calculated: 27     # 3 (High) × (6 − 3) × 3 (Automated) = 27
    band: "amber"      # 13–47
    consequence_floor_applied: false  # DCW 3 < 4
    computed_date: "2026-04-01"
    next_review_date: "2026-07-01"

Coming Soon

Dashboard Reference Implementation

The full open-source dashboard — fleet view, per-model deep dive, executive summary, and regulatory posture crosswalk — will be available with the GitHub release.

📊

Fleet View

Every model on a CRS × IMS grid, colored by band. Dot size equals consequence weight. Sort by largest CRS exposure.

Coming in v1.0 Release
🔍

Per-model Deep Dive

All eight registry sections rendered. KPI time series with thresholds. Circuit inventory with artifact links. Red team findings.

Coming in v1.0 Release
📋

Executive Summary

One-page PDF render per month per committee. Five numbers, one chart, one list. Board-ready in two minutes.

Coming in v1.0 Release
🏛️

Regulatory Posture

Each row is a framework requirement (EU AI Act, NIST, SR 11-7). Each column is a model. Each cell is the evidence link. Auditors love this view.

Coming in v1.0 Release

Have source code to contribute? We welcome pilots and contributions.

Get Involved →