The v1.4 roadmap named six things: C20 output validation, break-glass formalisation, the OWASP AISVS and MITRE ATLAS mappings, gate-rust, gate-fuzz, and gate-knowledge. Five shipped in full, although C20 shipped with a streaming constraint I come back to below. gate-fuzz shipped one of its three deliverables, the Python-to-Rust differential harness. The bundle-derived strategy generator and the HTTP-level protocol fuzzer moved to v1.5, and the v1.4 release post named the deferral on the day. v1.5 delivers them.
v1.4 completed the boundary model: identity at instantiation, policy at execution, observation throughout, classification at delivery. v1.5 is about depth. Certification alignment, streaming, a reference implementation someone can actually run, and paying down the debt v1.4 named.
Here is what is coming.
ISO/IEC 42001, mapped with the asymmetry written down
GATE has claimed alignment with ISO/IEC 42001 since the first release, on the strength of a high-level theme table in the Standard Mappings appendix. A theme table is enough to start a conversation with an auditor and not enough to survive one.
v1.5 replaces it with a per-control mapping from C01 through C20 to 42001 clauses and Annex A controls, researched against the published standard (ISO/IEC, 2023) rather than against secondary summaries. It ships as gate-knowledge documents plus a machine-readable gate-conformance/mappings/iso-42001.yaml, in the same shape as the AISVS and ATLAS mappings but not with the same guarantee behind it. Those two validate against pinned open upstreams that the repository can carry a snapshot of. 42001 is a paywalled standard, so the yaml pins the edition and carries clause and Annex A identifiers, and the validator checks internal consistency rather than resolving each title against a shipped copy. That is a weaker check and the mapping header will say so.
The asymmetry document is the part that matters. 42001 is a management system standard: it asks for leadership commitment, a documented AI policy, competence and communication, supplier governance, and lifecycle planning that extends well past runtime. GATE addresses none of that, and it should not pretend to. The document lists each requirement 42001 makes that GATE does not touch, so a team reading the mapping can see the shape of the gap instead of inferring it. GATE conformance does not imply 42001 conformance, and after v1.5 the mapping will say exactly where the difference lies.
Sakura Sky plans a companion technical note alongside it, for CISOs reading the mapping in a 42001 certification context. It addresses the question the asymmetry document raises, which is what an auditor will still ask for once GATE is in place.
Streaming-aware C20
v1.4 ships output validation with a named constraint: streaming is disabled at the high_privilege tier for any agent whose action matrix can produce a hold or review obligation. You cannot classify a response you have not finished generating, and you cannot un-send a token. Rather than hide that, v1.4 wrote it into the spec as a limitation.
v1.5 closes it. Chunk-level classification with a sentence-boundary default, buffer-then-deliver semantics per chunk, per-tier classifier latency budgets so the buffering cost is bounded and stated, and a partial-classification event contract so the evidence trail covers a streamed response as well as it covers a single one.
Buffer-then-deliver is the design decision underneath all of that. A chunk is classified before it reaches the user, so there is nothing to take back. Token-level delivery with retroactive retraction stays out of scope. Once a user has read a token, withdrawing it does not undo the disclosure.
This one touches every repository. The contract in gate-contracts, the guardrail in gate-policies, a runner sub-check in gate-conformance, and the classification path in both gate-python and gate-rust.
gate-fuzz: converting PARTIAL to PASS
The runner reports 9 AUTOMATED and 11 PARTIAL by default, 11 and 9 when bundle stores are configured. Several of those PARTIAL results are not manual by nature; they are PARTIAL because closing them requires executing test scenarios a query tool cannot perform. gate-fuzz was scoped in June to close them, and v1.4 shipped the harness without the closure work. v1.5 ships the two deferred deliverables.
The first is Hypothesis strategies generated from the signed C09 invariant bundle, so invariants in the bundle produce property tests without anyone writing them by hand, for the invariant types the generator covers. That changes what a passing suite means: it becomes evidence about your bundle rather than evidence about the harness that tests it. The second is the HTTP-level protocol fuzzer, which sends mutation variants at a running Tool Gateway and treats any response that is not a schema rejection or a policy denial as a finding.
The framing that matters is the one the June roadmap set out and v1.4 did not deliver. With the README mapping each test to the conformance check it closes, running gate-fuzz alongside the runner converts PARTIAL results into verifiable PASS results, leaving in PARTIAL only the checks that need human judgement: controlled drills, process inspections, runbook sign-offs. v1.5 completes that scope, and the runner counts change accordingly.
The gate-rust conformance bridge
gate-rust can produce canonical JSON, envelopes, ledger events and signatures that match gate-python byte for byte, but it cannot hand the conformance runner evidence directly. A team running a Rust gateway still needs Python in the evidence path. That is its own commitment in v1.5, and one of the five known issues v1.4 named.
The bridge goes through either PyO3 or a subprocess boundary, so a single test suite runs over both implementations and produces byte-level proofs at the envelope, ledger, and signing layers. That is what unlocks the envelope-hash and ledger-event-hash byte-parity properties, which account for the four tests currently skipped in the gate-fuzz suite. A Rust gateway then produces runner-compatible evidence without a Python sidecar in the path.
gate-adk-reference: show me the code
The most common response to the framework paper is some version of "show me the code". The repositories answer it in pieces: a schema here, a policy bundle there, a library that implements the hashing. Nobody has published the thing those pieces add up to.
gate-adk-reference is an end-to-end GATE-governed data analyst agent built on Google's Agent Development Kit (Google, 2026), with sql-guard as the deterministic policy engine at the SQL tool boundary. Eight controls wired across all four layers. A BigQuery public dataset is the headline scenario, and a documented SQLite path covers air-gapped contexts where a cloud warehouse is not available.
The scope statement is part of the deliverable. This demonstrates a single integration pattern on one agent framework. It is not hardened, and copying it verbatim into production would be unsafe. That goes in the first screen of the README rather than the last.
A public playground
Reading about a policy denial is not the same as watching one happen. v1.5 plans a hosted, sandboxed instance of the reference agent where you can issue a prompt and watch the GATE event stream next to the chat: the policy decision, the quality gate on retrieval, the output classification, each appearing as the agent works.
Details are still being finalised, so I am not naming a hosting platform, a model, a domain, or a cost envelope here. Those land with the release.
AI Catalog and ARD interop
Scoped for v1.5, gated on the ARD specification stabilising. The final in-or-out call is not made.
When C17 discovers an unenrolled workload, GATE has no way to read an assurance claim the publisher has already made about it. Everything GATE knows about that workload, it has to establish itself.
Google and a set of industry partners published Agentic Resource Discovery in June, an open specification for publishing, discovering, and verifying AI capabilities across the web, covering MCP servers, A2A agents and OpenAPI tools, built on the Linux Foundation AI Catalog data model (Bu and Krishnan, 2026). Its trust manifest is the cryptographic layer, carrying identity and attestations for a published capability.
The work is small and bounded: an optional catalog_refs field on the ABOM and enrolment contracts, a verification helper in gate-policies, a signal recorded on the C17 enrolment decision when a reference verifies, and a conformance check on the integrity of catalog references where they are present. What a verified reference proves is that the publisher controls the domain the catalog is served from, not that the capability is safe to run, so it is recorded as provenance rather than treated as a substitute for the checks C17 already makes.
The boundary is explicit and I want it stated before the code exists. GATE consumes catalog entries. It does not publish them, and it does not extend the ai-catalog schema. Keeping the discovery layer and the governance layer separable means a change in one does not force a change in the other.
Contract debt, named and paid
Three items from the v1.4 known issues, each scoped for closure in v1.5.
The unified exception register: one exception_record contract covering the exception surface that C09 break-glass and the C17, C18, and C19 policies all consume, instead of adjacent shapes added one control at a time.
The multi-approver HITL Decision Record: approvals needing two or more approvers carried by the HITL record itself rather than borrowed from the break-glass path.
gate-python publication to PyPI, so the reference library installs the way a Python library is expected to install.
Together with streaming C20, the fuzz completion, and the conformance bridge, that accounts for every item the v1.4 release post listed under "What v1.5 picks up". None of them has been dropped without saying so.
The HTML edition becomes canonical
One meta change, and the gap it closes is a maintenance one. The cloud quickstarts and the day-2 runbooks currently live inside the paper, so correcting a quickstart means cutting a release. Page-number citations rot every time the paper is re-laid out.
From v1.5 the HTML edition at deterministicagents.ai is canonical and the PDF is an automated export of it. The quickstarts and runbooks move to live surfaces, cutting roughly thirty pages from the normative core. Citations point at section anchors rather than page numbers, which stop being stable between builds.
Timeline
No dates. Sequencing, which is the part I can actually commit to.
The framework paper update comes first, then the contracts, then the repositories that consume them, in dependency order. The ISO 42001 mapping is the substantive content workstream and runs alongside the paper rather than behind it. The reference implementation lands before the playground, and the playground goes last because it depends on everything above it.
Two open questions get settled at kickoff rather than in a later release. The AISVS candidate triage may produce new conformance checks, and if the triage confirms them they join the suite in v1.5. And the canonical-JSON float restriction documented in v1.4 is either the end state or it is not; the alternative is a shared float emitter across the Python and Rust implementations, and that call gets made before the contracts are cut.
If you are building agentic AI infrastructure and any of the above addresses a gap you have hit in practice, the issues and discussions at github.com/deterministic-agents are the right place to say so before the spec is locked.
GATE is published at deterministicagents.ai under CC BY 4.0 for the documentation and MIT for the code. The strategic companion to this framework is the Trustworthy Agentic AI Blueprint, co-authored with Sakura Sky.
Disclosure: GATE is authored and maintained by me personally rather than by Sakura Sky, and there is no paid tier, hosted version, or commercial product built on it. Agent governance is also my day job at Sakura Sky, which is a commercial interest worth stating. Two Sakura Sky items appear above: sql-guard, the policy engine named in the reference implementation, which is developed by Sakura Sky and released under Apache-2.0, and the planned companion technical note on 42001. Everything described in this post is planned work. None of it has shipped, and scope can change before it does.
References
Bu, J. and Krishnan, S. (2026) Announcing the Agentic Resource Discovery specification, Google Developers Blog, 17 June. Available at: https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/ (Accessed: 19 August 2026).
Google (2026) Agent Development Kit (ADK). Available at: https://adk.dev/ (Accessed: 19 August 2026).
ISO/IEC (2023) ISO/IEC 42001:2023 Information technology - Artificial intelligence - Management system. International Organization for Standardization. Available at: https://www.iso.org/standard/42001 (Accessed: 19 August 2026).
Stevens, A. (2026) Governed Agent Trust Environment (GATE) v1.4. Available at: https://github.com/deterministic-agents/gate/releases/tag/v1.4 (Accessed: 19 August 2026).
