Helpifyr - Governed Execution for AI Agents

Autonomous agents shouldn't grade their own homework. Helpifyr gates every outcome behind real evidence and human approval - no false-green, no shadow truth. Built with Codex.

Comment

Inspiration

Autonomous coding agents are great at doing work - and terrible at proving it. They mark their own tasks "done", summarize their own success, and quietly skip the one test that failed. Running a platform that is itself built by agents, we kept hitting the same failure mode: self-declared green. In production, that is exactly where trust dies. We wanted a system where an agent can do almost anything - but can never certify its own outcome.

What it does

Helpifyr is an open governance layer that sits between agents and real systems. Agents plan, execute, and change things - but completion is never self-declared. Every outcome has to pass through:

  • deterministic risk & gate derivation - same input produces the same gates, monotonically (more risk can only add gates, never remove them);
  • tamper-evident evidence - verify results, diffs, and authoritative owner readbacks;
  • a human gate before anything reaches "ready".

No false-green. No shadow truth. If evidence is missing or a test was skipped, the work stays blocked - visibly, with a reason.

You can see it live in Lantern, the operator console - try it at https://lantern.helpifyr.com (read-only, preview/fixture data, labeled in-app):

  • Plan Studio - a Fabric-backed planning session with a Scorecard and a maturity gate. The Scorecard sets a Target Stage of 11/10, and warns that pushing beyond it (a 12) is "deliberate extra hardening - may be overengineered". Planning that grades itself on evidence.
  • Inbox / Human Gate - Blocked · Ready · Followthrough, "Owner-decision readback only", and an explicit "No shadow queue controls" panel. The console states what it is not allowed to do.

Every surface carries its own maturity label (OBSERVE, HUMAN GATE, PREVIEW). The product refuses to lie about its own readiness - which is the entire point.

How to test: open the console above and browse Plan Studio, Inbox / Human Gate, and the Overview blockers list. It runs on preview/fixture data (labeled in-app, in keeping with "no false-green"); the full multi-container runtime is not hosted due to its size, and every surface is demonstrated live in the 3-minute video.

How we built it

Helpifyr is an existing platform, and it has been built by Codex from the start - the entire multi-module stack (100+ services) is authored through Codex, and Build Week was no exception. This is an attested practice, not a git-only claim: the in-window increment below is the part that is Codex-authored and timestamped in the submission window (July 13–21). Everything in this window was driven through Codex on GPT-5.6. Codex-authored commits that landed:

  • Lantern (operator console): Plan Studio knowledge-studio readback (#663); Universal Work rubric/gate dual-read (#666); live human-queue, delegation, and gate-status readback (feature #664, merged as PR #668); and a W9 fail-closed evidence gate (#671).
  • Fabric (contract/gate/evidence core): runtime-evidence classification for W9 (#1407); the capability-gap lifecycle contract (#1415); and execution-resource budgets bound to model-budget and currency policy (#1416).

What git proves vs. what we attest - in the spirit of this project, we keep the two apart:

  • Git-verifiable: every implementation commit above is authored codex <codex@helpifyr.com>, timestamped inside the submission window, and merged through a reviewed PR (no self-merge).
  • Attested (not provable from git alone): those Codex commits were produced with Codex Desktop on GPT-5.6, driving the loop issue → branch → implementation → verify → PR → review → merge.

Codex session references: 019f653d-383e-79d2-840d-700b7a5be17c (#664), 019f6556-b8e0-7180-b3ce-88abe0bb90c4 (#666), 019f6974-c75f-7482-bee6-af747b847da9 (#669/W9), 019f6add-9fd0-7b93-b261-5093882bf35b (#671), and 019f6687-e062-7a73-b760-deb34faf7eb4 (Fabric implementation lane).

Stack: Fabric on Python/FastAPI with Postgres, NATS and Dapr; Lantern on TypeScript/React/Vite with a BFF; identity via Keycloak/OIDC; ingress via Caddy; Gitea as source-of-truth for repos, issues and PRs.

Challenges we ran into

  • Building a system that refuses to declare its own success is harder than building one that claims it. We had to make fail-closed the default everywhere: unknown blocks, missing evidence blocks, a skipped test blocks.
  • Keeping strict owner boundaries across many modules - no component may fake another's truth, and there is deliberately no central "program run" shadow state.
  • Staying honest about maturity: some runtime lanes (semantic activation, alert routing) are still blocked. Rather than hide that, the product shows it - which meant designing for "not ready" as a first-class, visible state.

Accomplishments that we're proud of

  • An entire governance stack authored by an agent - Codex builds and maintains all modules; Build Week hardened the evidence and gate core under that same loop.
  • A live operator console that renders governance as an actual product, not a diagram - with a maturity gate that even warns about overengineering.
  • The "No shadow queue controls" and "Owner-decision readback only" surfaces: a system that openly declares its own limits.
  • Git-provable Codex authorship across the entire in-window increment, merged through a reviewed, no-self-merge loop.
  • The meta-result: an agent built the grader - under the grader's own rules.

What we learned

Building a large, multi-module system entirely through an agent forced our governance to be machine-checkable, not aspirational. It also taught us to separate evidence from claim even in our own submission - git proves the author and timing; the tool and model are an attested process. The strongest proof that "agents shouldn't grade their own homework" was watching an agent build the grader and get stopped by it.

What's next for Helpifyr - Governed Execution for AI Agents

  • Close the open runtime lanes honestly: activate the semantic/knowledge layer and finish the W9 evidence routing, on evidence rather than assertion.
  • Extend the human-work model: delegation, multi-approver deadlock handling, and atomic approval binding before every side effect.
  • Package the evidence core as a standalone "flight recorder" any coding agent can plug into - turning a session into a verifiable delivery trail with a ready/blocked verdict.
  • A first SMB pilot, where governed agent work has to survive contact with a real business.

Built With

Share this project:

Updates

posted an update —

Product journal

Promotion Context Integrity: Closing the Loop on Private Artifact Delivery

Today, the Helpifyr / JaddaHelpifyr stack eliminates a subtle but critical blind spot in private promotion flows: ensuring that every private artifact promotion is deterministically bound to the exact evidence and context that produced it, even across retries, errors, and resumed flows.

Jul 22, 2026 · Jadda Helpifyr · Updates

Picture a late-night operator, eyes on the console, waiting for a private promotion to finalize. The workflow has retried twice, the artifact index is slow to resolve, and a prior run left behind ambiguous evidence. In this moment, the difference between a deterministic, provenance-bound promotion and a context-leaking, error-prone flow is not academic-it is the difference between safe, auditable delivery and a night spent untangling mismatched states. The stack’s promotion engine has long handled the happy path, but as usage grew, edge cases in retry, collector reconciliation, and context preservation surfaced subtle threats to the integrity of private artifact delivery.

Why This Day Mattered

For operators and automation developers, this shift means that every private promotion-no matter how many retries, resumptions, or error paths it traverses-retains a verifiable, unambiguous binding to its originating evidence and context. This closes the door on accidental mismatches, double-promotions, or silent context leaks, enabling auditability and reliable downstream automation. For users, it means that the artifacts they receive and depend on for daily work are always the ones actually produced by the intended workflow run, not a stale or ambiguous predecessor.

The closed UTC day 2026-07-21 resolved into 73 merged PRs across 14 repos, led by n8n-expert (20), helpifyr-fabric (9), jhf-jadda-interface (9).

What Actually Changed

The core promotion and collector subsystems now deterministically bind every private promotion to the exact artifact identities and evidence from the finalized workflow run. Collector artifacts are now indexed and retried with guaranteed resolution before terminal evidence is committed, and promotion success gates require reconciliation of Bolt finalizer evidence before marking the promotion as complete. Crucially, context and run identity are preserved and propagated through all error and resumption paths, preventing cross-run leakage and ensuring that resumed promotions never lose their provenance. Non-deterministic routing and ambiguous context reuse have been systematically eliminated.

Why It Holds Better Now

By enforcing that each promotion is gated on reconciled, context-matched evidence, the stack eliminates a whole class of race conditions and provenance ambiguity. Even in the face of retries, manual recoveries, or resumed collectors, the system now guarantees that only the intended artifact-proven by its exact run context-can be promoted. This technical guarantee is enforced at the contract and runtime level, not just by convention, ensuring that every downstream consumer can trust the integrity of delivered artifacts and audit their origins.

Want to Know More?

How might downstream automation or user-facing audit tooling now leverage these deterministic promotion guarantees to surface richer provenance, enable traceability, or trigger conditional workflows based on artifact lineage?

Log in or sign up for Devpost to join the conversation.

posted an update —

Product journal

Anonymous Read-Only Previews: Safe, Filtered Fixture Surfaces for Lantern Developers

Today, Lantern unlocks anonymous, read-only fixture previews on Cloudflare Pages, built from rigorously filtered artifacts. This new pathway gives developers and reviewers a frictionless, zero-credential route to interact with real stack surfaces, while holding a hard line on what evidence is admitted and what code is ever exposed.

Jul 21, 2026 · Jadda Helpifyr · Updates

Imagine iterating on a complex Lantern fixture, but every preview requires a login, and every public link risks leaking internal code or unvetted data. Now, picture a world where you can hand a URL to anyone, confident that it exposes only the surfaces you intend, and absolutely nothing else. Today, that world is real: Lantern's fixture previews are now published as anonymous, read-only artifacts, filtered at build time to admit just the evidence-backed, public-safe bundle. The result: instant, zero-friction access for stakeholders and developers, with no shadow of a security gap.

Why This Day Mattered

Developers and reviewers can now share and verify real Lantern fixture surfaces instantly, without managing credentials or risking overexposure. This shift accelerates the review cycle, enables safer collaboration with external partners, and ensures that only vetted, immutable artifacts ever reach a public endpoint. Operators can trust that every preview link is as safe as a static page, with no dynamic code or internal data ever leaking past the publication boundary.

The closed UTC day 2026-07-20 resolved into 16 merged PRs across 6 repos, led by jhf-lantern (10), helpifyr-fabric (2), jhf-web (1).

What Actually Changed

Lantern's build and deployment pipeline now compiles a static, read-only preview of fixture artifacts, filtered to include only the explicitly admitted, evidence-backed surfaces. This artifact is published to Cloudflare Pages, where it is accessible via anonymous, zero-auth URLs. The artifact boundary is enforced at build time, ensuring that no internal code, dynamic runtime, or unfiltered evidence is ever shipped. The preview shell is rendered against a fixture adapter, and route-specific surfaces are statically packaged, guaranteeing exact correspondence with mainline, filtered state.

Why It Holds Better Now

By shifting fixture preview publication to a filtered, static artifact model, the stack eliminates the risk of accidental code leakage or dynamic data exposure. The build process enforces an immutable boundary: only what passes evidence admission is ever included, and the resulting artifact is inert to runtime mutation or exploitation. This architectural guarantee means developers can share previews freely, without auditing every endpoint, and reviewers can trust that what they see is both current and safe.

Want to Know More?

How could this static, filtered publication approach be extended to enable safe, anonymous previews for more dynamic or user-generated stack surfaces, without sacrificing the integrity of the evidence admission boundary?

Log in or sign up for Devpost to join the conversation.

posted an update —

Product journal

Filtered Admission Surfaces: Raising the Floor for Daily Publication Security Today, we advanced the Helpifyr / JaddaHelpifyr stack's daily publication process by enforcing filtered admission surfaces across core Boost and JHF components. This move tightens the evidence contract for what can be published each day, reducing the attack surface and eliminating accidental leakage paths by making every surface explicit, reviewable, and testable.

20.07.2026 · Jadda Helpifyr · Updates

Imagine a daily bundle publication accidentally exposing a sensitive field or admitting a record that lacks the required evidence. In a fast-moving stack with many independent surfaces, even a small gap in admission policy can propagate quickly, undermining both security and operator confidence. Before today, several daily publication endpoints still admitted unfiltered or loosely filtered surfaces, relying on convention and discipline rather than enforceable, testable boundaries.

Why This Day Mattered

By enforcing filtered admission on every major daily publication surface-across Boost, Insurance, Frame, Bolt, Winnow, and JHF executive sales-this work closes legacy gaps and makes the daily evidence contract explicit. Operators and downstream consumers can now trust that only records passing the defined filter criteria are ever published, which directly reduces the risk of data leaks and unintentional exposure. For developers, this means that the shape and scope of daily publication is now a contract, not a convention, enabling safer iteration and easier auditing.

The closed UTC day 2026-07-19 resolved into 135 merged PRs across 25 repos, led by jhf-openclaw-env (27), jhf-bobbin (26), n8n-expert (15).

What Actually Changed

The stack now requires every daily publication bundle to be constructed from a pre-filtered, contractually-admitted surface. This is enforced programmatically at the boundary: the publication layer only admits records that pass the defined filter logic, with no fallback or silent bypass. The mechanism is a set of explicit filter contracts and boundary checks, integrated into the publication routines of each relevant component. This is not just a patch to individual endpoints, but a systemic shift in how daily admission is modeled and enforced.

Why It Holds Better Now

With explicit filter contracts and enforced boundary checks, the risk of accidental over-publication is eliminated: only records that satisfy the evidence-based filter criteria can ever be bundled or surfaced. This is strictly testable and reviewable, unlike implicit or convention-based approaches. The system now fails closed by default, making accidental leaks or policy regressions far less likely. Furthermore, this structure simplifies reasoning about what is or isn’t admitted, which helps both auditors and developers during reviews or incident response.

Want to Know More?

How will this enforced admission boundary enable new forms of automated evidence validation or pave the way for self-serve publication diagnostics for operators?

Log in or sign up for Devpost to join the conversation.