The product
An AI workflow and app platform: state a goal, and Noetfield turns it into apps and workflows, coordinating the work across models and agents. Product overview · Open the app ↗
Assurance · The acceptance layer
The agent should not be the final judge of its own work.
Capable agents are abundant. What remains scarce is a credible answer to the questions every consequential deployment gets asked: who authorized the action, what exactly was produced, who accepted it, and what evidence remains. Noetfield builds that answer into execution itself.
One system, three layers
The assurance layer
The acceptance, evidence, and improvement plane for agentic execution: explicit authority before action, separate acceptance of the exact result, bounded repair, and replayable evidence before anything is promoted. Provider- and model-neutral by design.
The runtime
Governed agent runtimes and the execution control plane underneath: AI Motors. Technical architecture
What acceptance means here
The sequence: agent runtime → exact artifact/effect binding → separate verifier → ACCEPT / REJECT / REPAIR / ESCALATE / STOP / NOT_EVALUABLE → external promotion authority → replayable receipt.
Every governed run follows the same path: an authorized event; an authority, policy, and budget envelope; bounded execution; exact binding of the candidate result; evaluation by a verifier that is separate from the worker that produced it; bounded repair, escalation, or a documented safe stop; a human promotion decision outside both executor and verifier; and a machine-readable receipt. Missing required evidence fails closed. A receipt is not certification.
Watch a complete run: a full first-party pass of this path on a real change, published with its verification history. The company-stage page states exactly what first-party operation proves and does not prove.
What exists, exactly
Proven first-party
RUNNING Separate-verifier acceptance, bounded repair with documented safe stops, exact-artifact binding by digest, human promotion outside executor and verifier, and inspectable failed attempts. These run on Noetfield's own delivery today, receipts published.
Internally demonstrated
FIRST-PARTY The complete governed replacement run, escalation practice, and the release pipeline's claim gates. First-party evidence, stated limits: internal use does not prove external adoption.
Chartered, not built
IN DESIGN The portable Acceptance Gateway itself: its standalone API and SDK, the fail-closed NOT_EVALUABLE decision class, signed verdict digests, and platform adapters. Chartered in canon; no portable component ships today.
Missing for portability
NOT YET External third-party proof, security review, cross-platform conformance testing, and attestable verifier identity. Stated plainly so nothing here overstates.
Noetfield Acceptance Gateway
IN DESIGN The acceptance layer is being extracted into a standalone component: the Noetfield Acceptance Gateway, a provider-neutral service that takes an authorized event, an authority envelope, an acceptance contract, an exact candidate digest, and an evidence bundle, and returns one of five decisions (accept, repair, escalate, stop, or not evaluable) with a signed receipt. It is in design, not shipped, and is labeled accordingly. Talk to us about early technical collaboration.
Where to go next
See a complete run
A finished governed software change with verification, bounded repair, and the receipt preserved.
Browse the workflow catalogue
Workflow classes with maturity labels: live, demonstrated, preview, and planned.
Build against the developer surface
Schema-valid-or-fail structured completions under deterministic controls.
Test a control
We build cases designed to defeat your controls, run them, and report how many got through.