For integration teams
Build with Policy Window as your AI-governance substrate
Policy Window is designed to be embedded — a primary-source- cited, machine-readable AI-governance catalog with structured IDs, confidence tiers, and historical snapshots. This page covers the integration patterns we see most often and points at the substrate primitives that support them. For the raw endpoint reference, see /wiki/api.
Integration patterns
Compliance vendor — coverage-cell lookup
Use case: customer asks "does the EU AI Act govern biometric ID?" Pull the cell from /wiki/catalog/json, read coverage["EU-AIA-2024:biometric_id"]. Cell carries type (governs/implicit/silent/conflicts), confidence tier, and pinpoint citation. Display in your customer console with a ?asOf=YYYY-MM-DD link back to Policy Window for the permanent reference.
AI lab — model-card cross-walk
Use case: your model card needs to disclose which jurisdictions classify your model as "systemic" or "high-risk". Query the concept-instrument mapping (CONCEPTS[i].usedByInstruments) for systemic-risk, frontier-tier, asl-3. Generate jurisdiction-by-jurisdiction tables programmatically.
Internal governance agent — change-feed subscription
Use case: notify your governance team when a tracked instrument changes. Premium scope change-feed.subscribe + an authenticated bearer token gives you paginated SemanticDiff rows (field-level changes to catalog rows). Pull-only today; webhook delivery on roadmap. Available on inquiry; see /wiki/services.
Policy consultancy — comparative briefings at scale
Use case: produce 12 comparative briefings per quarter for different client engagements. Use /wiki/compare for two-instrument side-by-side queries; bulk-export the underlying coverage matrix from /wiki/catalog/csv for your in-house analysis. Source-defensibility status (verbatim_quote_with_anchor vs. general_reference) on every cell makes cite-checking automatable.
AI agent — MCP-style tool integration
Use case: your LLM agent needs to answer regulatory questions with grounded citations. The OpenAPI 3.1 spec at /api/openapi is designed for LLM tool-use without schema-inference workarounds. MCP endpoint with native agent integration is on the roadmap; current pattern is OpenAPI-as-tool with the catalog JSON pulled into the agent context.
Substrate primitives to know
- Stable short-codes (e.g.
EU-AIA-2024) — use as your foreign key; the slug can rename, the short- code is forever - Confidence tierson every coverage cell — don't treat
loworpendingthe same ashigh - ?asOf=YYYY-MM-DD — every URL accepts the snapshot pin; use it for cited references so your output stays defensible after catalog updates
- JSON-LD @context at /wiki/catalog/jsonld-context — for triple-store / SPARQL consumers
- CSVW schema at /wiki/catalog/csv-schema — for typed CSV ingestion
- DataCite XML at
/wiki/[slug]/datacite.xml— for repository harvesters + future Zenodo DOIs - RSS changelog feed at
/wiki/changelog/feed— for low-friction change monitoring - pw: vocabulary at /vocab — dereferenceable per-term URIs (e.g. /vocab/coverageType)
What we want from integration partners
- Cite-back permanence. When you display a Policy Window cell to your end user, link back with
?asOf=YYYY-MM-DDso they can verify against the version your output was built on. - Don't over-attribute. Policy Window is an evidence reference, not a court-citation authority. Customer-facing claims should also link to the primary source (regulator publication, court order, etc.); PW is the structured-lookup layer, not the legal authority.
- Feed gaps back.If your customer asks a question we don't cover, file a topic-gap issue via /wiki/for-advocates. The catalog improves when integration teams surface real-world coverage gaps.
- Disclose AI use downstream. If you wrap PW data with your own LLM-generated commentary, mark it clearly so your end users can distinguish PW catalog content from your synthesis layer.