ActionGate

ActionGate turns AI-generated meeting actions into human-reviewed PASS, WARN, or BLOCK proposals before any work item reaches an external system.

Comment

Inspiration

I started ActionGate after thinking about a practical problem in AI-assisted meeting workflows: a fluent summary can sound correct even when it turns a suggestion, unresolved condition, or reversed decision into false work.

I did not want to build another tool that only generated a better meeting summary. I wanted to create a clear boundary between AI interpretation and consequential action.

Meetings often mix confirmed commitments with suggestions, conditions, corrections, and reversals. Without a review layer, uncertain statements can easily become false, duplicated, or unsupported work items.

ActionGate was therefore built around one principle:

AI proposes. Deterministic rules verify. Humans approve.

What it does

ActionGate is a human-in-the-loop safety gate for AI-generated work-item changes.

GPT-5.6 acts as an optional semantic extractor. It proposes structured operations, targets, fields, rationale, and supporting evidence from meeting content.

Deterministic Python rules—not the model—then classify every proposal as:

  • PASS — eligible for human approval
  • WARN — requires explicit risk acceptance
  • BLOCK — approval remains unavailable because a required condition failed

A human reviewer can inspect the supporting evidence, compare a proposed update with an existing issue, edit selected fields, approve a proposal, explicitly approve a warning, or reject it.

ActionGate also distinguishes between creating a new work item and updating an existing one. For updates, it displays a read-only diff so that reviewers can understand the proposed change without creating a duplicate issue.

The application never writes directly to GitHub or another work-management system. It produces proposal-only JSON and Markdown review exports.

How I built it

I built the application with Python, Streamlit, Pydantic, and an OpenAI API integration for GPT-5.6 structured extraction.

The architecture deliberately separates responsibilities:

  1. GPT-5.6 proposes structured changes.
  2. Pydantic validates the structured output.
  3. Deterministic SafetyGate rules compute PASS, WARN, or BLOCK.
  4. The Streamlit interface presents the proposal, evidence, findings, and review controls.
  5. A human makes every final approval or rejection decision.

Codex supported the project across planning, implementation, testing, documentation, debugging, UX refinement, and release verification.

I used Codex to help break the project into smaller milestones, inspect implementation details, design and extend tests, improve the review workflow, document safety boundaries, and verify the final release. I still reviewed the product decisions, risk boundaries, test results, and final behavior myself.

The public hosted walkthrough uses an explicitly labeled Golden Mock replay with fixed synthetic data. It does not require an API key and does not make an OpenAI API request.

Separately, I completed a local GPT-5.6 smoke test using synthetic input. I also maintained an offline deterministic safety evaluation so that fixed policy behavior could be tested without relying on live model output.

Challenges I ran into

The main challenge was preventing the language model from becoming the final authority.

A model can produce confident structured output even when a condition is unresolved, evidence is missing, or an existing work item should be updated rather than duplicated. I therefore kept semantic extraction separate from deterministic policy enforcement and final human approval.

Another challenge was making editing behavior safe.

I spent considerable time refining the distinction between editing and approving. Saving an edited proposal must run SafetyGate again, but it must never silently count as a final human decision. The reviewer must still make an explicit approval or rejection after the edit.

It was also important to preserve previous and current states in the review record. The export therefore keeps the original proposal, edited proposal, initial gate result, final gate result, and final human decision separate.

A further challenge was presenting the hosted demo honestly. The public version uses a fixed Golden Mock replay, while the live GPT-5.6 smoke test was performed separately using synthetic input. I kept those verification paths clearly separated in the interface, documentation, and demo video.

Accomplishments that I am proud of

I am especially proud that the final project does not treat GPT-5.6 as the safety authority. The model proposes structured changes, while deterministic code computes the gate result and the reviewer retains the final decision.

Other accomplishments include:

  • Clear separation between AI proposals, deterministic verification, and human authority
  • PASS, WARN, and BLOCK safety states
  • Approval protection for blocked proposals
  • Explicit risk acceptance for warning proposals
  • Revalidation after proposal edits
  • Editing that never silently counts as approval
  • Read-only diffs for updates to existing work items
  • Proposal-only JSON and Markdown exports
  • Explicit review-complete and external-system-modified status
  • No direct modification of an external work-management system
  • 132 automated tests passing
  • Offline deterministic evaluation matched 16 of 16 fixed cases
  • 0 of 12 unsafe cases incorrectly passed
  • 0 of 9 critical unsafe cases incorrectly passed

These evaluation results are based on a fixed synthetic regression corpus. They are not a general safety guarantee or a measurement of GPT-5.6 accuracy.

What I learned

Before this project, it was easy to think of structured model output as the end of an AI workflow. Building ActionGate taught me that structured output is only the beginning when the result could affect real work.

I learned to separate semantic extraction, schema validation, deterministic policy enforcement, review-state transitions, and final human approval into explicit layers.

I also learned that a safe user interface must communicate responsibility clearly. A disabled approval button, visible evidence, explicit warning acceptance, revalidation after edits, and a review-complete state are not just UX details—they are part of the safety design.

This project also helped me understand how to use Codex as an engineering collaborator. Codex accelerated implementation and verification, but I still needed to define the product boundary, decide what the model was allowed to do, review generated changes, interpret test results, and verify the final release.

What's next for ActionGate

Future work could include:

  • Additional work-management system adapters
  • Configurable organization-specific safety policies
  • Role-based review permissions
  • Persistent audit logs and review history
  • More synthetic evaluation fixtures and adversarial cases
  • Improved diff views for complex updates
  • Optional private or on-premise deployment patterns
  • Broader testing across different meeting and issue formats

Any future external integration would still preserve ActionGate's proposal-first boundary. A human decision should remain explicit, and an external write should never happen automatically just because a model produced a plausible result.

The core design will remain unchanged:

GPT-5.6 proposes; deterministic rules and humans retain authority.

Built With

  • ai-safety
  • codex
  • developer-tools
  • gpt-5.6
  • human-in-the-loop
  • json
  • markdown
  • openai-api
  • pydantic
  • pytest
  • python
  • streamlit
  • structured-outputs
Share this project:

Updates