How the research engine works
AGI Social Scientist research engine
A commissioned research module flows through three stages: AI-native evidence mapping (AGI Social Scientist), human validation (on-demand expert bench), and structured-output publication (the reusable evidence graph). This page documents each stage end-to-end. For the AI-use map, see /wiki/ai-disclosure §4; for the productised offerings, see /wiki/services.
Stage 1 — Commission
A customer (foundation, policy lab, AI-governance organisation, consultancy) commissions a research module via hello@policywindow.org. The commission inquiry includes the question, jurisdictions in scope, timeline, and budget envelope. Policy Window responds within 5 business days with a fixed-scope proposal (per /wiki/services) — or an honest "not yet" if the engagement is outside current capacity. Commissioned modules land as ResearchModule rows with status draft.
Stage 2 — AI-native evidence mapping
The AGI Social Scientist research engine produces an initial evidence map: claim extraction from primary sources, regulatory-gap identification, policy-transfer assessment, and (where the methodology calls for it) comparative analysis against the catalog. Every claim is proposed, never published; the AI output is a working draft that the human validator opens for review. Module status flips to active.
The substrate-side mechanism: AGI SS produces a structured findings JSON + a list of claims-needing-validation, then fires the /api/webhooks/agi-ss-result inbound webhook (HMAC-signed; cross-app server-to-server). Policy Window receives the result, writes ResearchModule.findings + transitions status to validation_pending. The cross-app handshake is documented at /wiki/ai-disclosure §4.
Stage 3 — On-demand expert validation
A named expert on the validation bench (see /wiki/research-bench/onboarding) reviews the AGI SS output for validity-critical issues: claim-extraction accuracy, source-context fidelity, methodological soundness, and (where applicable) interview evidence under the consent + retention protocol from charter §7.7. The validator records their decision as a ValidationRecord row (status validated or disputed) with a written rationale. Module status transitions to complete once the validation gate passes.
The validation badge (component <ValidationBadge />) renders on every published output — readers see at a glance whether the output has passed the gate. Disputed outputs stay visible (per the no-silent-retraction commitment in charter §6) with the dispute rationale attached.
Stage 4 — Structured-output publication
Validated outputs publish to /wiki/research/[slug] as CaseStudy rows. Every output contributes structured fields back to the reusable evidence graph — new CaseStudy rows, updated CoverageCell rationale, new SemanticDiff entries on touched catalog rows. The sponsor-PW relationship is structurally additive (per charter §4.5), not extractive.
Published outputs carry the funder name, the validator role, and the validation date on the rendered page. Citation form uses the same ?asOf=YYYY-MM-DD permanent URL pattern as catalog articles (see /wiki/persistent-id).
What the workflow does NOT do
- No legal advice. Outputs are evidence references; consult counsel for jurisdictional opinions (charter §7.4).
- No lobbying automation. The engine does not produce bulk regulatory comments, synthetic consultation submissions, or persuasion content (charter §7.5).
- No covert persuasion or microtargeting. All outputs are signed + dated; no per-audience tailoring (charter §7.6).
- No unapproved human-subject research. Interview-based work follows informed consent + anonymisation + written protocol (charter §7.7).
- No synthetic-respondent evidence. AI-generated personas, simulated panels, model-vs-model dialogues are never published as empirical findings. See the synthetic-agents disclaimer in the footer.
- No auto-publication. Every output requires explicit human approval (editorial board for catalog content, validation bench for research modules) before it ships.
Current scaffolding state
As of iter-313 (2026-05-30) the workflow is in productised scaffolding state — Prisma models + API endpoints + render paths exist; the substrate-side AGI Social Scientist inbound-result webhook + the curator dashboard for validator assignment are still in development. The validation bench (/wiki/research-bench/onboarding) is recruited per-engagement; no full-time validator roster yet. Status disclosure is honest: every service on /wiki/services is marked available_on_inquiry with first-customer-gated notes.