Public Review CandidateBuild 15 · SIW / Canon Reader integrationReview guidenoindex · staged, not linked
Process flow · plain-language walkthrough

How GGKS works

A research question moves through six stages before it can become a governed, evidence-bearing result. This page names each stage and is explicit about which parts are demonstrated in the current build today, which are synthetic teaching examples, and which are specified but not yet connected.

Open the GGKS Studio → Watch the guided walkthrough →

Demonstrated in the current build Synthetic / simulated only Specified, not yet connected
GGKS research-question flow Research question enters the Studio Composer as a proposed query. The Genesis Gateway checks identity, permission, credential and quota. Synthetic execution is demonstrated today; live AlphaGenome execution is specified but not connected. Results, evidence and provenance return to the originating inquiry for inspection and permitted next actions. 1. Research question Scientist opens Composer DEMONSTRATED 2. Proposed query Inputs, dependencies, gaps DEMONSTRATED (Composer) 3. Genesis Gateway checks Identity · role · purpose Credential status · quota DEMONSTRATED (synthetic policy) 4. Scoped execution Synthetic scenarios only SYNTHETIC — no real prediction AlphaGenome API Future live provider NOT CONNECTED 5. Result, evidence, provenance and receipt DEMONSTRATED (synthetic) Return to originating Studio inquiry SPECIFIED — not yet wired
6. Inspection and permitted next actions

Once a result returns, the scientist can inspect its evidence, provenance and standing, and take a permitted next action (refine the query, request review, or preserve a private finding). Broad automatic restoration of the exact prior view is a specified target, not demonstrated current behavior — see the walkthrough for the exact claim boundary on this step.

Text equivalent

The same six stages, in words

  1. Research question. A scientist opens the Composer from the GGKS Studio or the Studio's own workflow tools. Demonstrated today via the GGKS → Composer context handoff.
  2. Proposed query. The question becomes an inspectable proposal: biological inputs, dependencies, requested output, and unresolved assumptions stay visible rather than being invented. Demonstrated in the Composer's existing genomics examples and intake flow.
  3. Genesis Gateway checks. Before anything executes, the Gateway evaluates the current actor's identity, role, purpose, credential status and remaining quota. Demonstrated for the synthetic policy path; a real institutional identity/credential backend requires a separate Cloudflare Access sign-in step (see Keys & Provider Access).
  4. Scoped execution. Today this always returns one of four clearly labeled synthetic scenarios. No real AlphaGenome call is made. Live execution remains disabled regardless of any configured key.
  5. Results, evidence and provenance. A synthetic result, its evidence basis and a signed receipt are produced and shown. Demonstrated for synthetic runs. Returning that result to the exact originating Studio inquiry/revision is a specified target, reported missing in the most recent source review.
  6. Inspection and permitted next actions. The scientist inspects standing and evidence and may take a bounded next action. Full context restoration on return is a specified target, not yet demonstrated end-to-end.

This page reflects the GGKS AlphaGenome flow and implementation coverage specification and the current repository state at commit 3ef0f87 on build15-integration-001, reviewed 2026-09-16. It will drift as the implementation changes — treat the live Studio, not this page, as the source of truth for exact current behavior.