Jikken — Governing Feature Flags Across Four Product Surfaces

Jikken is a feature-flag governance system independently designed and built by Ryan using an AI-assisted development workflow. It is organized around one demanding product principle: a rollout decision must keep the same meaning across the CLI, Dashboard, SDK, and CI gate.

Role: Independent Product Design & Engineering · Year: 2026 · Timeframe: 1 day

Product surfaces: 4
Shared engine: 1
Defined exit codes: 0–6
Spec to deployed product: 1 day

Product Walkthrough

Follow one proposed targeting change through the complete system—from the first CLI conflict to the Dashboard review, SDK response, and CI gate that stops the unsafe deployment.

The Challenge

Feature flags start as simple switches. At scale, each switch becomes a policy interpreted by engineers, product managers, application code, and delivery pipelines. The risk is not only a bad configuration. It is semantic drift: a change can look safe in one interface, ambiguous in another, and still reach production because each surface tells a different story.

Jikken was conceived as a governance product for that gap. Before a rollout ships, it evaluates a proposed change against a representative audience, shows who gains or loses access, assigns an allow, hold, or needs-review verdict, and carries the decision—with its reason and audit trail—through every place it is consumed.

One Decision, Four Surfaces

The experience was designed as one continuous product flow rather than four adjacent tools. The CLI gives engineers a terse diff and meaningful exit code. The Dashboard gives reviewers the audience context behind it. The SDK exposes the same typed contract to application code. The CI gate enforces the verdict before deployment.

Jikken Dashboard showing a portfolio of feature flags, rollout exposure, and governance status — The flag portfolio makes rollout exposure and governance status scannable before a reviewer opens a change.

Jikken flag simulation with audience decision counts, governance signals, and per-user reasoning — The simulation view connects the high-level verdict to provenance and per-user reasoning.

Designing for Coherence

Consistency is the core feature. Green always means receives, red always means excluded, and yellow always means review. The field rollout_percentage is spelled the same way everywhere. Exit code 1 always means conflict. A simulation ID links the human-readable interface to the machine response, so reviewers and automation can refer to the same event without translating between systems.

A deterministic, seeded TypeScript engine shared across browser, Node, and Supabase Edge runtimes
Transparent decisions with reasons, source rules, audience provenance, and tamper-evident history
Role-specific interfaces that preserve one underlying vocabulary and decision model
Actionable validation that names the failing field and suggests how to recover
A coherence test suite that fails the build when colors, terms, exit codes, or engine copies drift

Jikken Simulation History with an expanded audit record and decision details — Simulation History preserves an attributable, searchable record of every verdict.

Jikken Settings showing the active data source, environments, and authentication configuration — Workspace settings make infrastructure and authentication state explicit instead of implicit.

The Machine Contract Is Part of the UX

The SDK does not reduce a governance decision to an opaque boolean. It returns a typed result with the simulation ID, verdict, exit code, audience summary, and recovery guidance. Callers that only need a gate can use isSafeToDeploy(), while more sophisticated integrations can inspect the complete contract. The interface meets each consumer at the level of detail it needs without changing the meaning of the decision.

Jikken SDK example using a typed FlagClient to evaluate whether a deployment is safe — The SDK asks the same safety question from application code and maps it directly to process behavior.

Jikken SDK response showing a conflict verdict, exit code, simulation ID, and audience summary — Automation receives structured data rather than being forced to parse presentation text.

Technical Architecture

Jikken is a TypeScript monorepo with six workspaces: a dependency-free shared decision engine, Commander.js CLI, React Dashboard, typed SDK, guided product presentation, and portfolio site. The same engine runs in three environments—the browser, Node, and a Deno-based Supabase Edge Function—so the product does not reimplement its most important decision at each boundary.

A deterministic core

The shared engine is pure and seeded. It reads no clock, randomness, or environment variable that can affect a verdict. A stable FNV-1a hash assigns rollout buckets and derives each simulation ID from the flag, targeting rules, rollout percentage, and user IDs. Identical inputs therefore produce bit-identical audience decisions, summaries, and exit codes across every runtime.

Browser, machine, and pipeline boundaries

The Dashboard and browser presentation use the shared engine for immediate feedback. The Edge Function exposes the same evaluation to the SDK and CI, authenticating machine calls with a constant-time API-key comparison and browser calls with a Supabase user token. Requests are validated and bounded to 500 users before evaluation; successful runs are appended to the simulation audit log and streamed back to the Dashboard.

React, Vite, and Tailwind CSS for the Dashboard and guided presentation
Commander.js for simulate, validate, and diff commands with real process exit codes
A typed TypeScript SDK with timeouts, structured errors, retry guidance, and isSafeToDeploy()
Supabase Auth, Postgres audit storage, Realtime updates, and a Deno Edge Function
Vitest integration contracts plus ESLint, type checking, unit tests, and GitHub Actions gates

The product thesis enforced in code

The integration suite turns coherence into a release requirement. It verifies that semantic colors resolve to the same Tailwind values, CLI process output exactly matches the in-process engine, Edge Function copies cannot drift from the canonical source, and rollout_percentage keeps one spelling across the CLI, Dashboard, SDK, and shared types. GitHub Actions runs linting, unit tests, these cross-surface contracts, and Jikken's own validation gate on every push and pull request.

Independently Built with an AI Development Workflow

Ryan independently conceived, specified, designed, engineered, tested, and deployed Jikken end to end. There was no separate product, design, or engineering team. AI tools—including Claude Code, Codex, and Gemma—were used as implementation collaborators inside a workflow Ryan directed: write the product specification, define the architecture and acceptance criteria, delegate bounded implementation tasks, inspect the running result, reject or revise incoherent output, and verify the accepted work through code review, type checks, tests, builds, and direct walkthroughs.

The workflow compressed the path from specification to deployed product to roughly one working day, but speed was not the definition of completion. Human judgment determined the product thesis, system boundaries, interaction model, security posture, and release bar. Models accelerated production; Ryan remained accountable for every decision and for the integrated system that shipped.

Continuous integration pipeline with the Jikken gate blocking a risky deployment — The final surface consumes the same exit code and prevents an unsafe change from reaching production.

What Shipped

Jikken shipped as a working monorepo with a CLI, React Dashboard, TypeScript SDK, Supabase Edge Function, GitHub Actions gate, guided product presentation, and integration tests that enforce cross-surface coherence. The live walkthrough lets a reviewer follow one targeting conflict from the terminal to the production gate.