DEV Community: Sakura Sky

GATE v1.4: Output Validation, a Rust Companion, and the Conceptual Layer as OKF

Andrew Stevens — Tue, 18 Aug 2026 19:16:56 +0000

GATE v1.4 ships today. It adds one control, three standard mappings, and three repositories, taking the Governed Agent Trust Environment from 19 controls to 20 across the same four layers: Identity and Integrity, Runtime Enforcement, Observability and Forensics, and Orchestration and Ecosystem. It is the largest release since I first published the framework in April. Existing C01 through C19 implementations remain compatible.

The release lives at github.com/deterministic-agents/gate/releases/tag/v1.4 (Stevens, 2026), with the artifacts bundle, SHA256SUMS, a single-file markdown export of the paper, and the 141-page PDF. The paper source is now public at gate-framework-paper. The framework home is deterministicagents.ai and the components sit under open licences at github.com/deterministic-agents. For the architectural rationale, "GATE: The Missing Infrastructure Layer for Agentic AI" remains the canonical introduction, and the v1.4 roadmap post from June sets out what I said this release would contain.

C20 Agent-to-Human Output Validation

GATE governed what an agent could execute at the tool boundary and what it could retrieve at the memory boundary. It said nothing about what the agent delivered at the end. C20 closes that.

The control sits in Layer 3, Observability and Forensics, alongside C13 intent telemetry and C19 drift monitoring. It performs per-response classification at the delivery boundary. Each final response carries a sensitivity tier, any regulated content categories it touches, a confidence score, and the obligations that follow: redact_fields, hitl_review, hold_for_review. At the high_privilege tier the control fails closed: a response whose classification matches no explicit pass-through entry in the signed action matrix is held, not delivered, enforced by the bundle schema and a policy guardrail rule. An output classification event is emitted per response, which gives the delivery boundary the same evidence coverage that tool envelopes give the tool boundary.

That is the fourth boundary in the model: identity at instantiation, policy at execution, observation throughout, classification at delivery. For most deployments the output gap is tolerable. For healthcare, legal advice, financial guidance, and HR decision support, obligations about what may be delivered, to whom, and under what review conditions are as real as obligations about what may be executed.

Break-glass becomes a contract

C09 has always required a signed record and dual approval for an invariant-halt override. What it lacked was a machine-verifiable format, so the record lived as a narrative document tied to a ledger event by convention.

v1.4 adds break_glass_record.schema.json to gate-contracts, with dual approval, scope binding, and expiry enforced by the schema. The invariant-halt ledger event now carries a break_glass_record_id referencing a valid record whenever an override was authorised, so a conformance runner can verify that each halt either resolves to one or was never overridden. That distinction previously required manual audit. This is a tightening rather than a new control. C09 stays C09 and the semantics do not change.

Two other controls tighten alongside it. C17 gains an automated enrolment fast-path backed by a signed policy contract, so discovered workloads can be enrolled without a human in the path when the policy says they qualify. C18 provenance now chains back to a registered source or an approved external feed through two normative URI schemes, which removes the ambiguity in what counted as an acceptable provenance claim.

OWASP AISVS, MITRE ATLAS, and NIST SSDF

The paper's standard mappings previously covered NIST AI RMF and ISO/IEC 42001, with EU AI Act alignment carried in the control text. v1.4 adds three more: OWASP AISVS, which reached 1.0 on 24 June and states testable security requirements across the AI system lifecycle (OWASP, 2026); MITRE ATLAS, the technique taxonomy for adversarial attacks on AI systems, whose tactics and techniques the mapping ties to the specific test scenarios C16 requires, so an adversarial validation harness has a threat model behind it rather than a list of categories (MITRE, 2026); and NIST SSDF, the secure development practice set issued under US Executive Order 14028 (Souppaya, Scarfone and Dodson, 2022), mapped as a deliberately narrow intersection: GATE touches SSDF at the artifact-integrity and tool-gateway surfaces (C03, C05) and marks everything else out of scope.

The mappings are pinned to upstream snapshots (AISVS v1.0, ATLAS content 2026.05) and machine-validated by a validator that ships in the repo: every referenced requirement and technique identifier must resolve against the pinned upstream with a matching title. Identifiers drift between revisions of a standard, and a mapping that has fallen out of date against its upstream is worse than no mapping, because it invites a reader to trust a claim nobody has rechecked.

The gaps are documented rather than papered over. Training data quality, model lifecycle management, and AI supply chain security sit outside GATE's scope, and the AISVS mapping says so. The June roadmap named these gaps as model evaluation, training data quality, and AI supply chain security; AISVS 1.0 organises the model-evaluation territory under model lifecycle management, and the mapping follows the published chapter names. The ATLAS mapping lists the techniques the framework does not address: the model interior is not a control-plane problem, and mapping to ATLAS does not make it one.

These mappings are informative. Passing GATE conformance does not imply conformance with AISVS, coverage of ATLAS, or certification against ISO/IEC 42001 or any other standard. They exist so an implementation team can trace a control to the requirement a reviewer will ask about. That is the whole purpose.

gate-rust v1.0.0

The Python library is the reference implementation and the right tool for prototyping gateways and building compliance tooling. It is the wrong tool for a high-throughput Tool Gateway written in Rust, where allocation patterns matter and Python interop adds latency.

gate-rust covers the primitives that have to be fast: canonical JSON, envelope construction, the hash-chained ledger, and ES256 signing and verification. The hash compatibility guarantee is the primary contract. gate-rust and gate-python must produce identical hashes for identical inputs, enforced by shared test vectors and a CI digest lockstep in both repositories. A single failing vector means the implementations disagree and both are wrong until one is fixed.

gate-rust covers the fast primitives only. Replay recording, schema validation, and the higher-level orchestration stay in Python where they make more sense. Neither library is on a package registry yet. v1.4 defers crates.io publication, so gate-rust installs from a tagged git ref (cargo add gate-rust --git https://github.com/deterministic-agents/gate-rust --tag v1.0.0), and gate-python publication to PyPI is a v1.5 item. Minimum supported Rust version is 1.78.

gate-fuzz v1.0.0

The v1.4 release ships one of three gate-fuzz deliverables originally scoped for the release. What lands is the Python-to-Rust differential harness that enforces byte equivalence between the two implementations at canonical-JSON, signing, and schema-validation layers. The other two deliverables - the bundle-derived Hypothesis strategy generator and the HTTP-level protocol fuzzer against a running Tool Gateway - move to v1.5. Naming the deferred items in the same release where the differential harness ships keeps the roadmap honest against what practitioners find when they clone the repo.

gate-knowledge v1.0.0

Google Cloud published Open Knowledge Format v0.1 in June, an open specification for representing curated knowledge as a directory of markdown files with YAML frontmatter, where concepts link to each other with ordinary markdown links and the only required field is type (McVeety and Hormati, 2026). It defines a file layout and nothing else. There is no SDK to install and nothing to run as a service.

GATE has the problem OKF was designed for. The control catalogue, the threat model, and the ABOM are all structured knowledge, and until now they lived as YAML, PDF, and HTML. An agent building a GATE-conformant system had to fetch several documents from several sources and assemble the picture itself.

gate-knowledge publishes the conceptual layer as an OKF v0.1 bundle: 20 control documents, the threat model, the adoption path, an ABOM template a team can fork and populate, typed relationship links between concepts, and a custom validator. The relationship links are the point. C17 links to C04 because discovery feeds the commission lifecycle. C09 links to C05 because invariants evaluate after policy. C19 links to C16 because they address different failure modes at the same tier and must not be merged. An agent navigating the bundle can understand a control's dependency surface before implementing it, without reading the full paper.

The bundle is the conceptual layer only. gate-contracts remains the normative schema source and gate-conformance remains the check source; nothing in gate-knowledge is authoritative over either.

Conformance runner v1.3.0

Check20 joins the suite for the new control. Check17 and Check18 move from PARTIAL to AUTOMATED when bundle stores are configured. A default configuration now returns 9 AUTOMATED and 11 PARTIAL results; a configured one returns 11 and 9. PARTIAL remains a statement about what the runner can see, not a failure: the report names the specific artefact each PARTIAL check still needs from the operator.

What is published in v1.4

gate-contracts v1.2.0 carries the normative JSON Schema definitions, extended with the C20 output classification event, the break-glass record, the auto-enrolment policy, and the approved feed registry.

gate-policies v1.2.0 carries the OPA/Rego policy and invariant bundles, adding C20 output classification with a fail-closed guardrail, C09 break-glass verification, the C17 auto-enrolment fast-path, and an explicit bundle manifest.

gate-python v1.2.0 remains the reference implementation, adding the C20 output module, break-glass verification, strict canonical-JSON hashing, and the cross-language test vectors gate-rust builds against.

gate-conformance v1.3.0 carries the twenty checks, the report template, the runbooks, the runner, and the three new machine-validated mappings.

gate-rust v1.0.0, gate-fuzz v1.0.0, and gate-knowledge v1.0.0 are the three new repositories, described above.

The framework paper source is public at gate-framework-paper, so the Quarto sources, control specifications, and diagram sources are now readable and forkable alongside the published PDF.

What v1.5 picks up

The June roadmap scoped gate-fuzz around PARTIAL closure: a README mapping each test to the conformance check it closes, and a suite that converts PARTIAL results into verifiable PASS results. That mapping arrives with the two deferred deliverables in v1.5, so the runner counts above stand until that mapping lands.

Alongside them, the paper's known issues section names five more: streaming-aware C20 classification, where a response is classified before it is fully formed; a unified exception register, meaning one exception_record contract for the exception surface that C09 break-glass and the C17, C18, and C19 policies all consume; a multi-approver HITL record, so approvals that need more than one approver are carried by the HITL record itself rather than borrowed from the break-glass path; gate-python publication to PyPI; and a gate-rust conformance bridge so the crate can produce runner-compatible evidence directly.

That is what v1.5 is scoped around, written down now for the same reason the June roadmap was. If you are building agentic AI infrastructure, deploying agents in a regulated environment, or advising organisations on AI governance, the issues and discussions on each repository are open. A bug report from someone who tried to implement a control is worth more to me than a comment on the paper.

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. The standard mappings described here are informative and were validated against pinned upstream snapshots rather than assessed by a third party.

References

McVeety, S. and Hormati, A. (2026) Introducing the Open Knowledge Format, Google Cloud Blog, 12 June. Available at: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing (Accessed: 18 August 2026).

MITRE (2026) MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems. Available at: https://atlas.mitre.org/ (Accessed: 18 August 2026).

OWASP (2026) Artificial Intelligence Security Verification Standard (AISVS) 1.0, released 24 June. OWASP Foundation. Available at: https://owasp.org/www-project-artificial-intelligence-security-verification-standard-aisvs-docs/ (Accessed: 18 August 2026).

Souppaya, M., Scarfone, K. and Dodson, D. (2022) Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST SP 800-218. National Institute of Standards and Technology. Available at: https://csrc.nist.gov/pubs/sp/800/218/final (Accessed: 18 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: 18 August 2026).

Protecting the IP in a Generative World

Andrew Stevens — Tue, 18 Aug 2026 11:40:02 +0000

A studio found its own back catalogue inside the training data of a public model. Someone had run a handful of its older titles through a detection tool, and the tool reported, with reasonable confidence, that the model had seen them. The legal team moved quickly, because a decades-old library is the company's principal asset and defending it is the job. The engineering team was asked a simpler question and could not answer it. From the studio's own systems, could it prove when each of those works was created, what it was derived from, and whether anyone had ever been licensed to ingest it. The plain answer was no. The studio owned the content and could not produce the provenance.

That gap is the subject of this post. The studio's real exposure went well beyond a model having trained on its work. Nothing in its own architecture could establish the origin, ownership, and rights history of the things it makes, on demand and in a form an outside party would accept. The wider series argued that trust is something a system produces rather than asserts (see Trust Is an Engineering Output). For a media business, provenance is the specific shape that takes, and generative models are the forcing function that has finally made its absence expensive. This post works backwards from the discovery: what the old protections were built to do, what protection now demands, and the layer that closes the gap.

The back-catalogue discovery

Start with what the studio did have, because it was not nothing. Its digital rights management was intact. Streams were encrypted, playback was licensed, access to the finished assets was controlled, and outbound video carried watermarks. By the standard of the threat that DRM was built for, the studio was well defended. None of it touched the problem in the room.

What the studio lacked was a record, attached to each asset and maintained by its systems, of when the work was made, who contributed to it, what source material it drew on, and what rights sat over it. That information existed, scattered across contracts in a document store, production notes, and the memories of people who had moved on. It did not exist as data the studio could query. So when the question became "prove this is yours and prove what happened to it," the studio was reduced to reconstructing its own history by hand, which is exactly the position the earlier posts in this programme described as evidence that was never engineered.

This is the shape most media businesses are in, and it is worth being precise about why it is uncomfortable. Without that record, the studio could not prove ingestion had happened, could not cheaply assert ownership, and could not act on the opt-out mechanisms the law now provides, because it had no machine-readable way to express its rights across a library built over decades. The content was owned. The provenance was not producible. Those are different properties, and only the second one was being tested.

What DRM used to mean

Work backwards to how the protections were built, because they were built well for a threat that has changed. Digital rights management was designed to stop one thing: the unauthorised copying and redistribution of a finished asset. Encryption at rest and in transit, licence servers that decide who may play what, access controls, and watermarks that trace a leak back to its source. The protected object was the copy, and the moment of risk was consumption. For piracy, this was the right design, and for piracy it still largely works.

It was silent, though, on the things that now matter most. Encryption protects the delivery path, so it does block a crawler from ingesting that path, but the training-data problem mostly lives elsewhere: in the trailers, clips, and released titles that circulate in the clear, and in the studio's ability to express its rights and prove its own lineage. DRM protects the outbound stream. It says nothing about how a work may be used for training, nor about the origin story of the work behind the stream.

This is why DRM modernisation is not a matter of stronger encryption or tighter licence enforcement. The object that now needs protecting is not only the outbound stream. It is the provenance of the work itself, the verifiable account of what it is, when it was made, and what may lawfully be done with it. That account is data, and it has to be engineered as data.

What model-era IP protection requires

Once the threat moves from copying to ingestion, content IP protection needs three capabilities that traditional media rights management never had to provide, and the law on both sides of the Atlantic is moving toward them, even as the central US question, whether training counts as fair use, stays unresolved in the courts.

The first is machine-readable rights reservation. European copyright law gives rightsholders a text-and-data-mining opt-out, but it only functions if the reservation is expressed in a machine-readable form that a crawler can detect (European Parliament and Council, 2019). The AI Act then obliges providers of general-purpose models to put in place a policy to comply with that reservation and to publish a sufficiently detailed summary of the content used to train the model (European Parliament and Council, 2024). An opt-out a studio cannot express at scale, across a whole catalogue, is a right it cannot actually exercise.

The second is provable ownership. The United States arrives at a related point from the other direction: in a pre-publication report, the US Copyright Office takes the view that assembling a training dataset from copyrighted works implicates the reproduction right, because it involves downloading, storing, and copying those works (U.S. Copyright Office, 2025). Registration and a clean chain of title remain the legal instruments that let a studio sue and recover, so the provenance layer does not replace them. It feeds them, giving the studio a queryable evidence base for what it owned and when, which is the thing a claim or a defence eventually turns on.

The third is content provenance. The industry has converged on a standard for this, the C2PA content credentials specification, which attaches tamper-evident provenance and edit history to a media asset so its origin travels with it rather than living in a separate database (C2PA, 2026). Generative AI copyright disputes are often, underneath the legal language, arguments about who can prove what about a file, and content credentials are an attempt to make that provable at the level of the asset.

This is not hypothetical, and music is where it has been tested first. In July 2026 the Munich Regional Court found the AI music service Suno liable for copyright infringement in a case brought by the German collecting society GEMA, holding that specific protected works remained reproducible inside the models and that the outputs reproduced them, and that training carried out in the United States did not place it beyond German law (Music Business Worldwide, 2026). The decision is first-instance and under appeal, but it turns on exactly the question a provenance layer exists to answer: can a rightsholder show that a particular work was used, and that a particular output reproduced it. The studios watching that case are asking whether they could prove the same thing about their own catalogues, and most cannot.

The provenance layer

Move forward from the diagnosis and the resolution is an IP-aware data layer, engineered before the dispute rather than assembled during it.

It does three things, and they are the implementations of the capabilities above. First, it makes provenance a property of every asset: content credentials are attached at the point of creation, and the studio keeps an internal record of each work's creation date, contributors, source and derivation, and attached rights. That record is made tamper-evident through cryptographic signing and hash-linking, so a later alteration is detectable, which is what turns a database into evidence. Second, it expresses machine-readable rights reservation consistently across the whole library, so a model training opt-out is something the studio asserts at scale rather than in principle. Third, it adds monitoring that checks whether the studio's works surface in public datasets or model outputs. That monitoring is probabilistic, the same reasonable-confidence signal the studio started with, so it works as an early-warning system rather than as proof, and describing it that way keeps the claim accurate. Building that layer out of a media company's scattered production and rights data is IP architecture, and it is a large part of what Sakura's Data & AI practice does for content businesses.

This is where the argument connects back to the rest of the programme. A provenance layer is the media form of evidence as an engineered property: the studio can answer, for any asset, where it came from and what may be done with it, on demand and with the signed record attached. That is data provenance doing the same job in a studio that a hash-linked transaction chain does in a bank, and it turns content provenance from a compliance aspiration into a running feature of the platform.

What happens when this is not engineered

The cost of skipping this is not only the litigation the studio is now in. It is broader, and some of it is opportunity rather than risk.

Without the layer, a media company cannot readily prove ingestion happened, cannot enforce an opt-out it has no way to express, and cannot assert ownership without a manual reconstruction every time. Each of those is a live exposure as the use of copyrighted works for AI training data becomes contested. The part most businesses miss is on the other side of the ledger. A market for licensing catalogues to model builders is forming: in the same music-industry fight, Warner Music settled its US infringement suit against Suno in late 2025 and signed a licensing partnership, even as Universal and Sony kept litigating (Music Business Worldwide, 2026). Those deals still close on corporate ownership and contractual warranties rather than on asset-level provenance alone, but a content owner that can show clean provenance diligences faster, carries less risk, and negotiates from a stronger position. The same missing layer that leaves the company exposed also leaves value on the table in the market its own content is helping to create.

The evidence that lets a media business defend its rights or license its catalogue is engineering output produced before the dispute, not a legal artefact produced after it. Building the record that lets a studio prove what it owns, express how it may be used, and show when a boundary was crossed is a media security and evidence problem before it is a legal one, and it is the ground Sakura's Security practice works on with a media company's data and rights teams.

References

Coalition for Content Provenance and Authenticity (C2PA), 2026. C2PA Technical Specification, Version 2.4. Available at: https://spec.c2pa.org/ [Accessed 18 August 2026].

Music Business Worldwide, 2026. Suno infringed copyright in GEMA case, German court rules. Reporting the Munich Regional Court first-instance judgment in GEMA v Suno, Case 42 O 763/25, 31 July 2026 (under appeal). Available at: https://www.musicbusinessworldwide.com/suno-infringed-copyright-in-gema-case-german-court-rules/ [Accessed 18 August 2026].

European Parliament and Council, 2019. Directive (EU) 2019/790 of the European Parliament and of the Council of 17 April 2019 on copyright and related rights in the Digital Single Market and amending Directives 96/9/EC and 2001/29/EC. Official Journal of the European Union, L 130, 17 May, pp. 92-125. Available at: https://eur-lex.europa.eu/eli/dir/2019/790/oj [Accessed 18 August 2026].

European Parliament and Council, 2024. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689, 12 July. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [Accessed 18 August 2026].

U.S. Copyright Office, 2025. Copyright and Artificial Intelligence, Part 3: Generative AI Training (Pre-Publication Version). United States Copyright Office, Washington, DC, 9 May. Available at: https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-3-Generative-AI-Training-Report-Pre-Publication-Version.pdf [Accessed 18 August 2026].

Your System Prompt Is Not a Trust Boundary

Andrew Stevens — Tue, 18 Aug 2026 09:28:15 +0000

A text-to-SQL agent is one of the easiest AI features to demo and one of the more awkward ones to get through a security review. A non-technical user asks a question in English, a model writes SQL, the warehouse runs it, and a table comes back. The demo takes an afternoon. The review tends to stall on a harder question: what actually stops the agent returning data the person asking is not entitled to see?

In the reviews I sit in, the first answer is usually a sentence in the system prompt. Never return customer email addresses. Only query the orders table. Do not run anything expensive. Those sentences are worth writing, and OWASP's own first mitigation for prompt injection is to constrain model behaviour in exactly that way, with specific instructions about the model's role and limits (OWASP, 2025). My argument is not that the sentences are useless. It is that they are the wrong artefact to point at when somebody asks you to demonstrate that the rule holds, because an instruction sitting in the context window is subject to the same forces as every other token in that window.

Willison, who coined the term prompt injection by analogy with SQL injection, puts the mechanism plainly: LLMs follow instructions in content, and they cannot reliably distinguish the importance of instructions based on where those instructions came from (Willison, 2025). OWASP ranks prompt injection first in its Top 10 for LLM applications and is unusually direct about the outlook, noting that given the stochastic influence at the heart of the way models work, it is unclear whether any fool-proof method of prevention exists (OWASP, 2025).

In a text-to-SQL agent the injection surface is wider than the user's question. Tool results reach the context, as do column descriptions pulled from the information schema, and a returned row with instructions written into a free-text field. Any of those can carry the argument that talks the model past the rule you wrote.

My working assumption, and I would not claim it as more than an assumption, is that a rule an LLM enforces is a rule an LLM can be argued out of. If you need to show an auditor that a rule holds, the rule has to live somewhere you can test it and be proven wrong.

OWASP's own mitigation list says as much further down, recommending deterministic code to validate adherence to expected output, and handling privileged functions in code rather than handing them to the model (OWASP, 2025). That is the design this post is about.

What a second model buys you, and what it does not

The reflex fix, once a team accepts that the system prompt is porous, is to add a judge: a smaller LLM that looks at the generated SQL and rules on whether it is safe.

I think that makes a reasonable detective control and a poor floor. It costs tokens on every query and adds a network round trip to a path users experience as latency, which are the boring objections. The one I care about is that a judge is a probabilistic classifier, and the figure these systems tend to advertise sits somewhere around 95 percent. Willison's line on the guardrail vendor category is that in web application security 95 percent is a failing grade (Willison, 2025), and I would apply the same standard here. A control that is right most of the time can sit above your floor, and I would not build a floor out of one.

Where a judge does earn its place is on the classes a parser structurally cannot see, and I will get to those below: re-identification through innocuous columns, PII addressed by a string literal inside a JSON payload, aggregations that are each individually fine and jointly identifying. Those are semantic questions, and a grammar has no opinion on them. My preference is to run a judge above a deterministic layer where the budget allows, rather than in place of one.

Move the rule to where the SQL is

The SQL an agent produces is a string. Before it reaches the warehouse it is inert, fully inspectable, and, unlike natural language, has a grammar. That is the moment where a rule can be enforced by something that does not take arguments.

sql-guard is our attempt at that control. It is a policy engine that sits between the model's output and the warehouse client: it parses the SQL, runs an ordered list of rules against the syntax tree, and returns allow, confirm or deny. There is no LLM in the guard path. It is Apache-2.0, pure Python, and depends on sqlglot and nothing else. Install agent-sql-guard, import sql_guard, Python 3.11 or later (Sakura Sky Engineering, 2026).

from sql_guard import PiiDenylist, SqlGuard, SqlGuardConfig

guard = SqlGuard(SqlGuardConfig.from_settings(
    pii_denylist=PiiDenylist.from_mapping({
        "columns": ["email", "phone_number", "ssn"],
        "substrings": ["address"],
    }),
    allowed_tables=["my-project.analytics.orders"],
    dialect="bigquery",
))

decision = guard.evaluate_static(
    "SELECT customer_id, COUNT(*) FROM `my-project.analytics.orders` GROUP BY 1"
)
if decision.denied:
    return decision.reason

Six rules ship by default. Single SELECT only, so DML, DDL and multi-statement payloads are refused even when buried in a subquery. A PII column denylist. No SELECT * in any scope. Nothing whose columns the guard cannot enumerate. A table allowlist of fully-qualified names. And a cost cap with three thresholds: auto-execute below $0.10, ask for confirmation between, refuse above a $20.00 hard cap or a 10 GiB bytes-billed ceiling, all of them defaults you can move.

Parsing rather than pattern-matching is the load-bearing choice. Regex over SQL is famously brittle, and most of the bypasses described below would have been trivial against a regex while still being reachable against an AST walk that was not careful enough. sqlglot handles the dialect surface (Mao, 2026). BigQuery is the default and the one under heaviest real use. Snowflake, Postgres, Trino, DuckDB, ClickHouse and MySQL have test coverage, and Presto shares Trino's parser. The remainder of sqlglot's thirty-plus dialects should work without being battle-worn.

One caveat belongs here rather than in the limitations section at the end, because it decides whether any of this is a boundary at all. A library the caller has to remember to call is a convention. The host process's warehouse identity is the same whether the guard ran or not, so if another code path in the same process can reach the client directly, the guard is closer to a lint than a control. Putting the credential behind the guarded client, in a separate service account or a proxy the agent process cannot reach around, is what turns the convention into enforcement.

A parser will not be talked out of a rule. It can still be wrong about what the rule covers, and most of the rest of this post is eight examples of exactly that.

Eight ways the PII denylist was bypassed

v0.2.0 exists because an internal adversarial review of a deployed agent found two ways to get denylisted columns past the guard. Fixing those two surfaced six more. The release closes eight, each confirmed against 0.1.1 with a reproducing query before anyone touched a fix, each with a regression test that fails on the old code (Sakura Sky Engineering, 2026). The changelog itemises the work across ten entries, because two of the classes needed separate fixes.

Alias laundering. Rename a denied column inside a common table expression (CTE), the named subquery a WITH clause introduces, then project the alias from the outer query. Each CTE gets its own scope, and the rule called a helper that only read the outermost projection list, so the outer select named city and looked clean.

WITH c AS (SELECT billing_city AS city FROM `p.d.orders`)
SELECT city FROM c

Derived tables, UNION ALL arms and multi-hop alias chains through two CTEs all worked the same way.

Inner-scope stars. The star rule also ran against the outermost select only, so a SELECT * inside a CTE body or derived table went through untouched.

Stars inside a wrapping construct. A separate bug with the same effect. The check inspected the projection's root node, which meant OBJECT_CONSTRUCT(*) in Snowflake, COLUMNS(*) in DuckDB, * APPLY(f) in ClickHouse and ROW(c.*) in Trino all passed. It is now a deep walk, with COUNT(*) as the explicit carve-out.

Qualified t.*. In sqlglot a qualified star parses as a Column node wrapping a Star, not as a bare Star. An isinstance(projection, exp.Star) check walks straight past it, at the top level as well as anywhere else.

ClickHouse COLUMNS('regex'). Expands to an arbitrary set of columns and parses with no Star node anywhere in the tree to match on.

NATURAL JOIN. Joins on whichever columns the two tables happen to share. Without schema introspection the guard cannot rule out a denied column among them.

Column names that never become a Column node. sqlglot parses several positions as a bare Identifier, so a sweep collecting Column nodes missed them entirely: JOIN ... USING (email), column aliases of the AS g(email) form, and STRUCT('x' AS email) field names. The USING case was a working single-query value oracle.

Aggregates as a blanket exemption. Every aggregate function counted as PII-neutralising, so MAX(email), MIN(email), ARRAY_AGG(email), STRING_AGG(email) and ANY_VALUE(email) all returned real values. Only aggregates that reduce to a derived statistic qualify now.

Whole-row alias references. This one was not in the original report. It was found while fixing the others, and it was the most severe of the eight.

SELECT c FROM `p.d.orders` AS c

That parses as an ordinary column named c. The denylist had no denied name to match against, the star check found no star, and the guard auto-executed it. Strictly more powerful than the SELECT * it had been blocking since day one, and syntactically indistinguishable from selecting a column that happens to be called c. The fix also covers TO_JSON_STRING(c), ARRAY_AGG(c), STRUCT(c), the unaliased SELECT tbl FROM tbl form, CTE and derived-table names, and VALUES and PIVOT aliases.

Getting that rule to be usable took more care than getting it to be strict. Denying on a bare name collision would have broken WITH revenue AS (SELECT ..., SUM(x) AS revenue ...) SELECT revenue FROM revenue, which is a mainstream idiom, so the rule resolves the ambiguity from the AST instead: a table contributes only the name it is addressable by, and a CTE publishes its own output names.

The bypasses returned the success state

Most of the eight did not return deny. They returned confirm, and confirm is what static evaluation returns when no rule fires at all.

    for rule in self._rules:
        decision = rule.evaluate(ctx)
        if decision is not None:
            return decision

    return GuardDecision(
        outcome=GuardOutcome.CONFIRM,
        reason="Static checks passed; awaiting cost evaluation.",
        referenced_tables=tuple(sorted(tables)),
    )

So there was no near-miss and nothing to instrument. Eight queries reached denied columns, and the guard reported that static checks had passed, in the same words it uses for a query that is entirely fine. The whole-row alias went on through the cost gate and executed.

One thing worth knowing if you are building telemetry on this: GuardOutcome is shared across the two evaluation phases and carries a different meaning in each. In evaluate_static, confirm is the pass. In evaluate_cost it means ask the user before running this, and sits between the auto threshold and the hard cap.

A guardrail that fails closed tends to generate a support ticket and get fixed that afternoon. One that fails open often generates very little, which leaves going and looking as the main way anybody finds out. That asymmetry is my argument for treating adversarial review of this class of component as routine work, and it is why every fixed bypass now carries a test that fails against the version before it. A good share of the tests across those five files exist to keep the eight closed.

The fix broke our own demo

Tightening a guardrail means queries that used to work now do not, and 0.2.0 contains breaking behaviour changes on purpose.

The clearest casualty was the identity-resolution query bundled with the project as a worked example. It normalises email and mobile inside a CTE and projects only COUNTIF aggregates, an ordinary pattern in analytics that looks careful. It is now denied in both PII modes: the CTE scope projects the denied columns, and COUNTIF(email_norm = 'target') is itself a value oracle.

A WHERE clause is an oracle

sql-guard has two PII modes. "reference", the default, denies any mention of a denied column anywhere in the query. "project" denies only projections, checked across every scope.

Projection-only checking is the intuitive design and it does not hold, because a denied column in a predicate never appears in the output while still answering a question about itself.

SELECT COUNT(*) FROM `p.d.orders` WHERE billing_city = 'Columbus'

Run it again with LIKE 'a%', then > 'm', and you are doing binary search against a value you were never allowed to read. Depending on the cardinality, a handful of queries recovers it. GROUP BY, HAVING and ORDER BY leak the same way. The row count is the channel, and a rule that only inspects projections cannot see it.

Hence the strict default. If a deployment genuinely needs predicate access to a denied column, pii_mode="project" is there and the trade-off is stated in the docs. Narrowing the denylist, or pointing the agent at a pre-masked view the denylist does not cover, is usually the better move.

One nuance is easy to get backwards, and a careful reader of the changelog did: aggregation is not a safe harbour. COUNT, SUM, AVG and their relatives are treated as PII-neutralising only under pii_mode="project". Under the default mode no aggregate is exempt, because the whole point of the default is that the agent must not learn the values at all, and COUNT(*) ... WHERE email = ... learns them.

Limits of a parse-level SQL guard

These limits are structural. I would sooner publish them than have somebody discover them.

PII inside JSON, VARIANT or STRUCT payloads is not covered. JSON_VALUE(payload, '$.email') names only payload; the field name is a string literal the engine resolves at runtime. Denylist the containing column.

Two whole-row reads remain open by design. Selecting a STRUCT column whole, and an UNNEST alias over an array of structs, both return every field without naming one. Neither is distinguishable at parse time from the scalar-array form that is idiomatic and has to stay allowed. Same remedy: denylist the containing column.

Re-identification through non-PII columns is out of scope. If uid maps one-to-one to a person, blocking email does not stop correlation against an outside dataset.

Side channels remain. Row counts, dry-run byte figures and error messages all carry bits about denied values even when every direct reference is refused. The oracle above is the version we closed, and the family is larger than the fix.

There is no schema introspection. If you say a table is allowed, the guard takes your word for it. That constraint is the reason SELECT * is rejected everywhere instead of reasoned about.

The cost cap bounds a query, not a spend. evaluate_cost is per-call by construction. An agent in a retry loop issuing two thousand queries at nine cents each trips nothing. Cumulative exposure needs warehouse-side maximum-bytes-billed and a budget alert.

It is not an authorisation layer. Identity, IAM and row-level security sit outside it. It can approve a query that a correctly configured warehouse would have refused on identity grounds.

It is a boundary only where it is the only path to the credentials. Covered above, and in my experience the most common way this control gets downgraded to a suggestion.

The changelog also carries two known issues we have not fixed and one inconsistency: a top-level EXCEPT DISTINCT or INTERSECT is currently rejected as a non-SELECT, which fails closed and is an availability bug rather than a security one; allowlist breaches are under-reported in telemetry built on decision.reason because that rule runs last; and two spellings of hashed PII are handled inconsistently, in the direction of denial. Anyone evaluating this would do well to read that section alongside the README.

Defence in depth, and what the depth sits on

Warehouse-side column-level and row-level security are the durable answer to most of this. Policy tags on sensitive columns, masking policies, row access policies scoped to the calling principal: enforcement that lives with the data, applies to every client, and does not care whether the query came from an agent, a BI tool or somebody's notebook. Where a team can get there, I would push them to.

The gap sql-guard fills is between deciding that and having it. Warehouse-side controls need coordinated schema work, a data classification exercise that is usually half-finished, and sign-off from teams who own tables you do not. In the programmes I have watched, that runs to quarters rather than weeks. A denylist and an allowlist in a config file is an afternoon, it gives you a cost cap that column security does not, and it keeps working as a second layer once the warehouse work lands.

Message-boundary guardrails such as NeMo Guardrails or LangChain's belong in the same picture. They watch intent in the conversation, this watches the query at execution, and the failure modes look different enough to me that running both is usually worth the tokens.

Where it is

v0.2.0 is on PyPI as agent-sql-guard and the source, changelog and security policy are on GitHub. Two naming notes, because both have caught people. The import is sql_guard while the distribution is agent-sql-guard, and the unqualified name sql-guard on PyPI is an unrelated data-quality package by a different author. 0.2.0 is also the first release published to PyPI at all, because the name collision meant 0.1.x never shipped there.

The package classifiers say Development Status 4, Beta, which is the accurate description. The whole thing is roughly 1,400 lines across three modules, small enough to read end to end in an afternoon. For a component sitting on a security boundary I would treat that as a feature rather than an apology, and I would rather people read it than take this post's word for anything.

If you are running an agent that writes SQL against anything sensitive, an hour spent trying to beat your own guard, whatever form it takes, is likely to pay for itself. The eight above are a starting list. If you find something in sql-guard, please use the disclosure route in SECURITY.md instead of a public issue: security@sakurasky.com or a draft advisory, with the SQL, the config, and the decision you expected against the one you got. Everything that is not a bypass is very welcome in the issue tracker.

Disclosure: sql-guard is developed and maintained by Sakura Sky and released under Apache-2.0. Sakura Sky uses it in client-facing agent work. There is no paid tier, hosted version or commercial product built on it. The findings described here come from an internal adversarial review of a deployment rather than a third-party security audit.

References

OWASP (2025) LLM01:2025 Prompt Injection, OWASP Top 10 for LLM Applications. OWASP Gen AI Security Project. Available at: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (Accessed: 18 August 2026).

Sakura Sky Engineering (2026) sql-guard: deterministic policy engine for LLM-generated SQL, v0.2.0. Available at: https://github.com/sakura-sky/sql-guard (Accessed: 18 August 2026).

Mao, T. (2026) SQLGlot: no-dependency SQL parser, transpiler, optimizer and engine. Available at: https://sqlglot.com/sqlglot.html (Accessed: 18 August 2026).

Willison, S. (2025) The lethal trifecta for AI agents: private data, untrusted content, and external communication, 16 June. Available at: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ (Accessed: 18 August 2026).

Arkhe: An Ontology Language for AI Systems

Andrew Stevens — Thu, 23 Jul 2026 10:25:57 +0000

Two weeks ago I argued that the ontology layer is where the recurring agentic failures get retired, and that the artifact doing the retiring should live in your repository rather than a vendor's console (Stevens, 2026a). I closed that piece with a demand: insist on a neutral, versioned, reviewable form for your entities, relationships, and permitted actions. The obvious follow-up question: neutral form in what language, exactly?

So I spent my evenings since building one.

Arkhe v0.2.0 shipped today: a small, open-source ontology language for AI systems. Arkhe is my personal project, written on my own time, Apache-2.0 licensed, free forever, with no CLA. It is a Sakura Sky product in no sense at all. I am writing about it here because the argument started here.

One file, three registers

An Arkhe module is a YAML file in git. It declares the three registers from the previous post: what exists, how it connects, and what may be done, by whom, with what trace.

entities:
  FinancialModel:
    keys: [model_id]
    properties:
      status: {type: state, values: [draft, in_validation, validated, production, retired], initial: draft}
      last_validated: {type: date, optional: true}

links:
  owned_by:
    from: FinancialModel
    to: TradingDesk
    cardinality: many_to_one
    reverse: models

actions:
  grant_production_use:
    target: FinancialModel
    guard: target.status == "validated" && months_since(target.last_validated) <= 12
    authority: head_of_model_risk
    audit: mandatory
    effects:
      - target.status: production

A head of model risk can read that file and object to line eleven. That property, reviewability by the person who owns the business concept rather than the pipeline, drives most of the design. Guards are written in CEL, Google's Common Expression Language, because it is small, side-effect free, and already the policy expression language of half the cloud estate (Google, n.d.). The world is closed: entities and actions that are absent from the file are absent from the system, and no inference engine conjures new ones. The philosophical tradition behind the word ontology is acknowledged and then firmly set aside; Gruber's definition, an explicit specification of a conceptualisation, is the whole ambition (Gruber, 1993).

The other load-bearing decision: the spec is a contract, never a runtime. Arkhe compiles your module into a neutral intermediate form, one tool contract per action, and emitters generate what your systems consume from there. Nothing of Arkhe executes in your serving path. If the project vanished tomorrow, everything it generated for you would keep working, and the YAML would still be yours to compile with something else.

What compilation buys you

The compiler pipeline is deliberately dull. Validate the module (structural rules from a published JSON schema, then semantic rules: key references, link endpoints, guard names, effect types). Generate contracts. Emit.

Two emitters exist today:

The first produces a native Python library of guarded functions: call grant_production_use on a model that was validated fourteen months ago and you get a refusal that names the failing clause, months_since(target.last_validated) <= 12, rather than an exception or, worse, a success. An agent wired to those functions inherits the refusal semantics without any prompt engineering.
The second emitter, new in v0.2, produces an Open Knowledge Format bundle: one markdown concept document per entity, link, and action, generated from the module's annotations, for LLM consumption.

I think of the pair as complementary halves: the contracts declare what an agent may do, and the OKF bundle declares what it should know. Both are regenerated from the same file, so they cannot drift apart.

v0.2 also added synonyms as first-class annotations, so grounding can match the vocabulary people actually use ("desk" for TradingDesk, "sign-off" for grant_production_use) while the canonical names stay stable, and resolved types inline on effects, so downstream consumers stop re-deriving what a write will do.

The release I am most pleased with, though, is the one users will never invoke: a second implementation. The Rust port of the validator now passes the same frozen golden fixtures as the Python reference. Porting surfaced three behaviours the spec had never actually decided, all inherited silently from Python's YAML library, including the venerable Norway problem, where no parses as a boolean. All three are now pinned strictly in a public ADR. My conclusion from that exercise is worth its own post: a language with one implementation has a spec by accident.

Who it is for

I wrote persona guides for the three audiences I keep meeting in this work, and they map onto the registers:

GRC professionals get controls as structure. authority: head_of_model_risk and audit: mandatory are enforced properties with a trace, and a refusal that cites its failing clause is audit evidence in a way that a prompt instruction never will be. The reviewable YAML is the control library; the git history is the change record your auditor keeps asking for.
Data engineers get the semantic layer as code, sitting in the same repository as the schema it describes, validated in CI with finding codes and line numbers like any other artifact. If you have ever maintained business definitions in a wiki while the warehouse drifted underneath them, the appeal of arkhe validate failing your pipeline should be immediate.
Architects get protocol independence. The tool-contract IR sits at the centre; MCP, OpenAI function schemas, and Google ADK tool definitions are all planned as thin emitters from it, which means the protocol churn of the past two years stops being a rewrite trigger. Choosing Arkhe commits you to a file format, and deliberately to nothing else.

The use case I most want to see built, and intend to build as the flagship module, is an ontology of the AI estate itself: models, agents, tools, datasets, evals, guardrails, and incidents, with actions like promote-to-production guarded on eval results. The industry currently manages its most consequential systems with less structural rigour than it applies to a customer table. That seems worth fixing with the same medicine.

What it refuses to be

Arkhe is a language and a compiler. There is no workspace, no operational database, no query engine, no agent runtime. Palantir productised the three registers inside a platform a decade ago (Palantir Technologies, 2026), and several open projects are now circling the same territory with runtimes attached; the prior-art section of the README names them rather than pretending the idea arrived from nowhere. The bet Arkhe makes is narrower than any of them: the durable artifact is the reviewable file and its compiled contracts, and everything stateful belongs to systems you already run. If that bet is wrong, the cost of having tried it is one YAML file you can still parse with anything.

v0.2.0 is on PyPI (pip install arkhelang), crates.io (cargo install arkhe), and GitHub, with the spec sketch, nine ADRs, the golden fixtures, and the persona guides. It is deliberately small. If the previous post convinced you the neutral form should exist, this one is an invitation to argue with a concrete candidate, ideally in the form of an issue with a failing fixture attached.

Disclosure: Arkhe is the author's personal open-source project and is unaffiliated with Sakura Sky; Sakura Sky has no commercial interest in it. The author also maintains GATE, an open framework for governed agent runtimes, with which Arkhe aims to interoperate on equal terms with any other runtime.

References

Google (n.d.) Common Expression Language specification. Available at: https://github.com/google/cel-spec (Accessed: 23 July 2026).

Gruber, T.R. (1993) 'A translation approach to portable ontology specifications', Knowledge Acquisition, 5(2), pp. 199-220.

Palantir Technologies (2026) Ontology overview, Foundry documentation. Available at: https://www.palantir.com/docs/foundry/ontology/overview (Accessed: 23 July 2026).

Stevens, A. (2026a) Your ontology is the asset. Stop renting it back. Sakura Sky, 10 July. Available at: https://www.sakurasky.com/blog/own-your-ontology/ (Accessed: 23 July 2026).

Stevens, A. (2026b) Arkhe: an ontology language for AI systems. Available at: https://github.com/arkhelang/arkhelang (Accessed: 23 July 2026).

Identity Is the Bank Now

Andrew Stevens — Wed, 15 Jul 2026 09:56:08 +0000

A customer who has banked with the same institution for years is known to it in a number of different ways:

To the onboarding system that ran the identity checks, the customer is a passport, an address, and a date on which verification was completed.
To the fraud engine, the same customer is a pattern of devices, locations, and spending that it scores in real time.
To the anti-money-laundering system, a risk rating and a stack of alerts, most of them cleared long ago.
To the app and the contact centre, a name, a photograph, and a service history.

Four example systems, four versions of one person, and they do not agree with one another. When that customer moves house, the bank often hears about it three times, because three of the four systems have no idea the other two have already been updated. The customer notices the seams. So, in a different way, do the people who defraud banks for a living.

Every retail bank has some version of this customer, and the fragmentation is not the failing of one institution. Fraud, financial crime, KYC, and customer experience grew up as separate disciplines, with separate teams, separate budgets, and separate systems, and for a long time that separation held up fine. It holds up much less well now, because the four have collapsed into a single engineering question, and banking identity is the name for the answer.

Does the bank hold one reliable, current, shared understanding of who its customer is, and can every function that needs it read from and write to that understanding in close to real time? The wider series framed identity as the point where trust stops being a claim and becomes an engineering output (see Trust Is an Engineering Output).

Inside a bank, identity is turning into the thing the whole institution runs on.

The seamed customer

Look first at what the seams cost, because they are expensive on both sides at once. For the customer, they show up as friction. A repeat verification for a transaction the fraud engine did not recognise, a wait while a legitimate payment is held, a request to re-confirm details the bank already holds, an address updated in one channel while another channel keeps posting to the old one. None of this is catastrophic. All of it, accumulated across millions of customers, is the texture of a bank that feels harder to deal with than it should.

The other side is where it gets serious.

The same seams are an attack surface, and financial crime lives in the gaps between the four systems. A synthetic identity, assembled from real and fabricated fragments, can pass onboarding because the KYC system checks documents rather than coherence, and then behave well enough that the fraud engine, which never saw the onboarding anomaly, has no reason to look twice. An account takeover exploits the fact that the fraud engine sees a device change the AML system will never hear about, while the AML system sees a transaction pattern the fraud engine treats as somebody else's problem. No single system holds the whole picture of the customer, so no single system can see the whole picture of the attack. The criminal's real advantage is not sophistication. It is that the bank's view of the customer is split four ways and the criminal's view of that same customer is whole.

How identity got fragmented

The fragmentation was built one sensible decision at a time. The KYC system arrived to satisfy onboarding obligations, and those obligations are real: the global standard requires a bank to identify and verify the customer, identify beneficial owners, understand the relationship, and monitor it on an ongoing basis (FATF, 2012). The AML monitoring system was bought separately, often from a different vendor, and keyed on accounts and transactions rather than on people. The fraud engine came in for real-time scoring, keyed on sessions and devices. The customer relationship system was built for service, keyed on a contact record. Each was the right tool for its job, procured by the team that owned that job, on its own timeline.

What none of them shared was a canonical idea of the customer. Each held its own identifier for the same human being, and nothing tied those identifiers together into one durable customer identity. So the bank ended up able to answer four narrow questions well and the one broad question, who is this customer and what do we currently know about them, not at all. This is the state most KYC architecture is in: strong at the point check, silent on the whole.

The regulatory current now runs the other way on both sides of the Atlantic, which is worth noticing. In the United States, FinCEN's customer due diligence rule already requires banks to identify and verify the beneficial owners behind their legal-entity customers and to keep that understanding current, and a February 2026 order recast the refresh obligation on a risk basis rather than as a mechanical repeat at every new account (FinCEN, 2016; FinCEN, 2026). In the European Union, the 2024 anti-money-laundering reform moves the bloc onto a single rulebook and stands up a central authority to supervise it, with directly applicable rules on customer due diligence and beneficial ownership designed to make that data consistent across institutions rather than bespoke to each (European Parliament and Council, 2024). Different regimes, one direction of travel, toward shared and coherent identity. A bank whose own AML data cannot be reconciled across its four internal systems is starting that journey a long way back.

What a unified identity layer looks like

The fix is a unified identity layer, and it is worth being precise about what that means, because it is not another copy of the data in a warehouse. It is one canonical, current, authoritative record of each customer, built by resolving the fragments the four systems already hold into a single entity. Entity resolution, the work of deciding that this passport, that device pattern, and that contact record all refer to the same real person, is the hard technical core of it, and it is never perfectly clean, which is exactly why it has to be engineered rather than assumed.

The layer holds the durable answer to who the customer is, and links out to the signals each function produces: the KYC status and its evidence, the AML risk rating and its alerts, the live fraud signals, the service history. The point is not that one team now owns everything. The point is that any function can see the whole customer without having to own all of the customer. The fraud engine can factor in that onboarding flagged something odd. The AML system can see that the fraud engine just watched the customer's device and location change. Onboarding can stop asking for what the bank already holds. The identity layer becomes the shared, low-latency, authoritative view that every other system reads from and contributes to, and building that view out of messy source data is a serious piece of identity engineering rather than a reporting exercise.

The security architecture that supports it

Here is the part that a bank has to take seriously before it builds any of this, because getting it wrong turns an asset into a liability. A unified identity layer concentrates the most sensitive data in the entire institution into one place. That is precisely what makes it valuable, and precisely what makes it the highest-value target the bank owns. Unify identity without hardening it and the result is a better-organised honeypot.

So the unification and the protection are the same project, and banking security has to be designed into the layer from the first day rather than added once it works. That means access that is fine-grained and purpose-limited, so the fraud engine reads the fields it needs for fraud prevention and nothing more, and the contact centre sees a service view that does not expose the full financial-crime picture. It means strong identity for the workloads and the people reaching the layer, not just for the customers described in it. It means tokenising the most sensitive attributes, so that a breach of one consumer does not spill raw identity data. And it means a complete, tamper-evident record of every read and write, both because a supervisor will eventually ask who saw what, and because the bank itself needs to know. Get this right and the concentration of identity is a strength. Get it wrong and it is the worst single point of failure a bank could design. This seam between unifying data and defending it is the ground Sakura's Security practice works on with a bank's identity teams.

What changes once it exists

Come back to that customer, and follow what a working identity layer changes for them and for the bank at the same time. The address update lands once and every channel reflects it. The legitimate payment clears because the fraud engine can see the customer is exactly who the rest of the bank already knows them to be. Onboarding to a new product takes minutes because the bank reuses what it verified years ago instead of starting over. The friction that made the bank feel hard to deal with mostly disappears, and it disappears for the same reason the bank gets safer.

Because the criminal loses the seams. Synthetic identities are harder to sustain when onboarding, fraud, and financial-crime signals resolve to one view that has to stay coherent over time. Account takeover is harder when the device change the fraud engine sees and the transaction pattern the AML system sees are looking at the same customer record rather than two strangers. Fraud prevention and financial-crime detection stop being separate contests the bank fights with half the picture each.

And the bank gains the property the whole series has been circling. It can answer, for any customer, what it knows and how it knows it, on demand and with the evidence attached. That is trust as an output of the architecture rather than an assertion in a policy, and it turns out to run on a clean identity foundation. A bank that builds one is not a slow bank: Xapo Bank reached production on a tightly governed stack in weeks rather than quarters, because the foundations were engineered once and everything else inherited them.

The unified identity layer that all four functions read from and write to has to be built out of the fragmented systems a bank already runs, and constructing that resolved, current, authoritative view of the customer is the work Sakura's Data & AI practice does inside financial institutions.

References

European Parliament and Council, 2024. Regulation (EU) 2024/1624 of the European Parliament and of the Council of 31 May 2024 on the prevention of the use of the financial system for the purposes of money laundering or terrorist financing (Anti-Money Laundering Regulation). Official Journal of the European Union, L, 19 June. Available at: https://eur-lex.europa.eu/eli/reg/2024/1624/oj [Accessed 10 July 2026].

Financial Action Task Force, 2012. International Standards on Combating Money Laundering and the Financing of Terrorism and Proliferation: The FATF Recommendations (updated). Financial Action Task Force, Paris. Available at: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html [Accessed 10 July 2026].

Financial Crimes Enforcement Network (FinCEN), 2016. Customer Due Diligence Requirements for Financial Institutions, Final Rule. 31 CFR Parts 1010, 1020, 1023, 1024 and 1026. US Department of the Treasury. Available at: https://www.federalregister.gov/documents/2016/05/11/2016-10567/customer-due-diligence-requirements-for-financial-institutions [Accessed 10 July 2026].

Financial Crimes Enforcement Network (FinCEN), 2026. Order Granting Exceptive Relief from the Beneficial Ownership Requirements for Legal Entity Customers. US Department of the Treasury, 13 February. Available at: https://www.fincen.gov/system/files/2026-02/FinCEN-Order-CCDExceptiveRelief.pdf [Accessed 10 July 2026].

Migrating a Live Real-Time Communications Platform from AWS to Google Cloud

Andrew Stevens — Tue, 14 Jul 2026 11:15:08 +0000

11Sight operates a real-time voice and video engagement platform, the communications backbone behind its AI agents for automotive and hospitality businesses. Calls are the product. An infrastructure migration that takes the platform offline for a weekend was never an option. Sakura Sky's Cloud practice moved the platform from AWS to Google Cloud with a phased hybrid strategy that kept it serving live traffic throughout, and held user-facing downtime at the final cutover to under five minutes.

The Challenge

11Sight's production environment had grown up on EC2 and RDS: a monolithic web application on VMs, a Jitsi-based conferencing stack with video bridges and recorders, and a PostgreSQL database holding the customer data that every call depends on. Three constraints shaped the engagement:

Live traffic, all the time. A real-time communications platform has no quiet maintenance window long enough for a big-bang cutover, so the migration had to run while customers kept making calls.
Prove everything before production. Cutover timing, VPN latency, and application behaviour on GKE all had to be validated against production-grade infrastructure before any customer traffic depended on them, which made a full rehearsal environment a first-class deliverable of the migration plan.
Modernization over relocation. The goal was to land on a cloud-native footing, with Kubernetes where it earned its keep and managed services for state, rather than reproduce the VM-centric estate on new hardware.

The Engineering

We designed a compute-first, three-phase hybrid migration that decoupled the application move from the database move, so each could be validated independently. Four engineering decisions carried the project:

Landing zone before workloads. The first deliverable was a Google Cloud foundation built from Sakura Sky's Enclave Terraform blueprint: organization structure, IAM groups, centralized logging and monitoring, a Shared VPC, and a Cloud HA VPN linking the AWS and GCP networks. Every subsequent resource was defined in Terraform, in repositories created inside 11Sight's environment from day one.
Rehearse the whole migration in staging first. We provisioned a complete staging environment (GKE for the containerized web application, Cloud SQL for PostgreSQL 16, Memorystore with the Valkey engine, Compute Engine instances behind autoscaling groups for the conferencing workloads) and used it to rehearse the entire migration. That rehearsal validated that VPN latency between the GCP application tier and the AWS database was within production thresholds, and produced a measured downtime estimate of 45 to 90 minutes for the final cutover.
Compute first, data second. In production, Phase 1 shifted live traffic from the AWS VMs to the GKE load balancer via DNS while all reads and writes continued against AWS RDS over the VPN. Phase 2 enabled logical replication on RDS and ran a continuous Database Migration Service job into Cloud SQL, keeping the two databases in near-real-time sync.
A rehearsed cold cutover. Phase 3 was a stop-and-go cutover inside the planned window: drain traffic at the GKE ingress, quiesce the source database, promote the Cloud SQL replica once DMS reported no lag, repoint GKE configuration and secrets, and redeploy. A war room voice bridge kept migration, DevOps, development, and QA leads on one channel, and traffic reopened only after internal health checks passed against the new database.

The Results

Under 5 minutes of downtime. Against a planned 45 to 90 minute maintenance window, actual user-facing downtime at the production cutover was less than five minutes.
Zero data loss. Continuous DMS replication and the no-lag promotion gate meant the cutover moved the database without losing a single write.
A cloud-native production platform. The web application now runs containerized on GKE, state lives in managed services, and the conferencing fleet scales behind autoscaling groups instead of hand-tended VMs.
A proving ground that outlives the project. The rehearsal environment was built to outlast the migration: a permanent, Terraform-defined staging environment where future releases, upgrades, and scaling decisions get validated before they reach customers.
Everything as code, owned by the client. All infrastructure is defined in Terraform in 11Sight-owned repositories, so there was nothing to hand over at close-out that 11Sight did not already control.

This is the type of work our Accelerate solution delivers on, with foundations laid by Enclave: production capability built inside the client's environment, jointly with their team. Contact us to scope a similar migration.

Regulatory Evidence at Machine Speed

Andrew Stevens — Mon, 13 Jul 2026 09:38:21 +0000

The request arrived on a Tuesday and gave the compliance team twenty-four hours. The regulator wanted to know why the bank's transaction monitoring system had cleared a particular payment eleven months earlier: which rules fired and which did not, what customer risk score applied at that moment, who reviewed the resulting alert, and what that reviewer actually saw. The system that made the decision was still running, unchanged, and working correctly. The evidence about that one decision was somewhere else entirely. It sat in a queue, behind a request to rebuild a dataset, behind a restore from backup, behind a data engineer who had other work booked. The bank was not being accused of anything. It was being asked to show its working, and it had twenty-four hours to discover whether it could.

Banks have always been asked for evidence. What has changed is the nature of the request. The old rhythm was periodic, predictable, and aggregate: a return filed on schedule, a report at quarter end, a sample pulled for an inspection booked weeks in advance. The new rhythm is specific, unscheduled, and granular: this decision, this customer, this moment, and show me now. Most banks built their evidence systems for the first rhythm and are now being asked to serve the second. This is the banking form of a tension that runs through most regulated industries, which the wider series has set out as the gap between evidence and speed (see Evidence Versus Speed). Inside a bank it takes a particular shape, and it has a particular fix.

The twenty-four-hour request

What the compliance team actually had to do, in those twenty-four hours, is the most revealing part of the story. The decision they needed to explain was not recorded anywhere as a decision. It had to be reassembled from three systems that had never been designed to be read together.

The monitoring engine's logs held which rules had evaluated the payment, but those logs rotated after ninety days, so the relevant window had to be restored from backup. The customer risk score was worse. It was recomputed nightly and overwritten each time, so the score that actually applied eleven months ago no longer existed anywhere; it had to be rebuilt by rerunning the scoring logic against archived inputs and hoping the logic had not changed in the meantime. The analyst's review sat in a case management tool with its own retention policy and no link back to the payment except a reference number typed in by hand.

The team got there, barely, and the answer was correct. The payment had been cleared for good reasons and the bank had done nothing wrong. The cost was two engineers for the better part of a week and an uncomfortable realisation in the room afterwards: nobody was confident they could do it again. The decision itself had been sound. What the bank could not do was demonstrate it on demand, and that is a different kind of risk from getting the decision wrong. Under MAS Notice 626, records must be retained and be retrievable in a usable form (Monetary Authority of Singapore, 2022). Retention that exists in principle but cannot be produced when the regulator asks is not really retention at all.

What regulators used to ask for

The reason banks are in this position is that their evidence systems were built, quite rationally, for the requests that used to arrive. Regulatory reporting was a calendar activity. Returns were filed monthly, quarterly, or annually. Inspections were scheduled. The unit of evidence was the aggregate: a capital position, an exposure summary, a count of alerts raised and cleared. Banks built reporting factories to serve that model, with data warehouses, reconciliation processes, sign-off workflows, and a small industry of controls wrapped around the production of the report.

Even the regulation that pushed hardest on data quality assumed this shape. The Basel Committee's principles for effective risk data aggregation and risk reporting, published in 2013, told banks to be able to aggregate risk data accurately and to trace it, and it remains the reference point for banking data lineage (Basel Committee on Banking Supervision, 2013). But the output it had in mind was still a report, produced on a cycle, for a supervisor who would read it later.

Under that model, assembling evidence retrospectively was a perfectly sensible strategy, because the ask was predictable and the deadline was known. Banking compliance became organised around producing documents on a schedule. Evidence was a product of the reporting cycle rather than a property of the transaction, and for a long time nobody had reason to notice the difference.

What they ask for now

The difference is now impossible to miss, because supervisors have stopped confining themselves to the aggregate. They ask about individual decisions, at short notice, and they expect the bank to trace one end to end.

The pressure is visible in the supervisors' own output. More than a decade after the Basel principles, the European Central Bank found it necessary to issue a guide pressing banks on effective risk data aggregation and reporting, precisely because so many still cannot demonstrate complete, end-to-end lineage across their data estate (European Central Bank, 2024). The Digital Operational Resilience Act, in application since January 2025, requires financial entities to maintain registers of their ICT arrangements and to evidence their operational resilience continuously rather than annually (European Parliament and Council, 2022). And the five-year retrievability standard in MAS Notice 626 is not satisfied by a backup tape that takes a week to read.

Put together, these describe a single shift. The deliverable has become the reconstructable chain behind any single decision the bank made, available on request, at something close to the speed the bank operates. The report still gets filed, but it is no longer the thing the supervisor is really testing. Real-time compliance is a slightly misleading phrase, because nobody expects the answer instantly. What is expected is that producing the answer is a query rather than an excavation. A financial services audit is becoming a series of specific questions with specific answers, and regulatory reporting, while it continues, is no longer the whole of the job.

Engineering evidence into the flow

Meeting that expectation is an engineering problem, and it has an engineering answer. The evidence has to be emitted by the system as it runs.

Look again at what those twenty-four hours actually required. Engineers excavated rotated logs from a backup and hoped the restore was complete. They reran scoring logic against archived inputs and hoped the logic had not drifted in eleven months. They tied a case file to a payment through a reference number somebody had typed in by hand. Every step was archaeology. Every step introduced a guess. What the bank finally handed the regulator was a well-argued account of the decision, assembled under deadline by people reconstructing their own system from its debris.

Engineer the evidence into the flow and the same request lands very differently. At the moment the decision is made, the system writes it down. It records the inputs that fed the rule, the version of the rule and the model that evaluated them, the score they produced, the identity of anyone who touched the alert, and the time it happened, all bound together by a single identifier. It preserves the risk score as it stood that day instead of overwriting it at midnight. It hash-links the record, so any later alteration shows. It makes the record addressable, so one payment resolves to one chain. One approach excavates. The other retrieves.

This is what engineered compliance means in a bank. The evidence becomes a by-product of operating the system, produced continuously whether or not anyone asks for it. It costs something to build. It costs considerably less than paying for reconstruction every time and never being certain the reconstruction will hold.

None of that capability lives in the monitoring engine. It lives one layer down, in the data foundation that carries lineage and preserved history underneath every transaction the bank processes, and that layer is precisely what Sakura's Data & AI practice builds inside regulated institutions. A bank standing on that foundation can move quickly: Xapo Bank reached production on a tightly governed stack in weeks rather than quarters, because the controls were engineered into the platform instead of being negotiated afresh for every release.

The audit cycle that disappears

The payoff goes well beyond surviving the next twenty-four-hour request. The audit cycle stops being an event in the bank's calendar at all.

When evidence is a running output, the request that consumed two engineers for a week becomes a query answered in minutes by someone in compliance who does not need to open a ticket. Audit-ready banking means the bank answers without a change freeze, without pulling engineers off delivery, and without the background dread that the answer might not be reproducible. Everything else the bank is trying to build keeps moving while the question is answered.

The banks that bolt evidence on afterwards pay for it twice. They pay once in reconstruction, and again in the drag on everything else, because a system whose evidence cannot be produced on demand cannot safely be changed quickly. Every release carries an unpriced risk of breaking a chain nobody can currently see. There is a further dividend, too: a bank that can prove exactly what its transaction monitoring did, and why, can afford to tune it more aggressively, because it can demonstrate the effect of the change rather than argue about it. Evidence engineered into the flow is what lets a bank keep moving while it answers.

The work does not end when the architecture is built. The chain has to hold through every release, every model change, and every new rule, and someone has to be able to prove it still does. Running that discipline inside a bank is what Sakura's GRC service is for.

References

Basel Committee on Banking Supervision, 2013. Principles for effective risk data aggregation and risk reporting. Bank for International Settlements, Basel. Available at: https://www.bis.org/publ/bcbs239.htm [Accessed 10 July 2026].

European Central Bank, 2024. Guide on effective risk data aggregation and risk reporting. ECB Banking Supervision, Frankfurt. Available at: https://www.bankingsupervision.europa.eu/ecb/pub/pdf/ssm.supervisory_guides240503_riskreporting.en.pdf [Accessed 10 July 2026].

European Parliament and Council, 2022. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 27 December, pp. 1-79. Available at: https://eur-lex.europa.eu/eli/reg/2022/2554/oj [Accessed 10 July 2026].

Monetary Authority of Singapore, 2022. MAS Notice 626: Notice to Banks on Prevention of Money Laundering and Countering the Financing of Terrorism. Monetary Authority of Singapore. Available at: https://www.mas.gov.sg/regulation/notices/notice-626 [Accessed 10 July 2026].

Your Ontology Is the Asset. Stop Renting It Back.

Andrew Stevens — Fri, 10 Jul 2026 13:12:11 +0000

Enterprise AI post-mortems have changed character. The older ones read like RAND's catalogue of failure causes, misunderstood problems and data that could not carry the weight, feeding a failure rate the researchers put above 80 percent (Ryseff, De Bruhl and Newberry, 2024). The ones crossing my desk in 2026 name a different trio, over and over. The agent behaved differently today than it did yesterday, same inputs. The model asserted a purchase order, a clause, a valuation model that does not exist. And when the auditor asked why the system did what it did, nobody could produce an answer that survived scrutiny.

Determinism failures.
Hallucinations.
Compliance gaps.

Three symptoms, one defect. A model invents entities when nothing machine-readable tells it what exists. Runs diverge when nothing pins down which actions are permitted, under what conditions, against which objects.

Compliance evidence cannot be produced when authority and auditability were never encoded anywhere a system could enforce them. The older definitional fights still contribute: nobody could agree on what a "customer" was, or whether a work order and a maintenance event were the same thing. A real factor, but no longer the largest. That ambiguity is the human-speed version of the disease that now presents as invented valuation models and unreproducible runs. Each failure is a failure of meaning, and the artifact that fixes all of them has an old name from knowledge engineering: an ontology, an explicit specification of a conceptualisation (Gruber, 1993). Strip the philosophy and it is three registers. What things exist in our business. How they connect. What actions are allowed against them, by whom, with what trace. One register grounds the model, one constrains the behaviour, one produces the evidence.

Everyone rediscovers this eventually. The interesting question in 2026 is not whether you need one. It is who ends up owning it.

The market has already priced this

You do not have to take my word for the value of the thing. Watch where the money went.

Palantir spent roughly two decades as a bespoke integration house before posting its first GAAP-profitable full year in 2023 (Palantir Technologies, 2024). The product that emerged from those years is not a database and not a model. Palantir's own documentation describes the Foundry Ontology as the layer that sits on top of datasets and models and binds them to their real-world counterparts, with object types, link types, and action types as the primitives (Palantir Technologies, 2026). Entities, relationships, permitted actions. The three registers, productised.

Founder-facing commentary has caught up. A recent essay in a series on durable moats holds Palantir up as the template, casting the ontology, accumulated through years of on-site engineering, as the defensible asset that AI-era startups should now race to build inside their own customers (FounderCoHo, 2026). As advice to vendors, I think it is broadly correct, and that is exactly why it should stop enterprise architects mid-coffee.

Read the same claim from the other side of the table. The moat is not the vendor's algorithms. The moat is a machine-readable description of your operations, extracted from your subject-matter experts, refined against your edge cases, on your payroll's time. When a platform's defensibility is defined by how much of your meaning it has captured, the polite word for that is partnership. The accurate word is leverage.

Workflow lock-in is dying, semantic lock-in is replacing it

For twenty years, SaaS retention rested on two things: workflow habit and migration pain. Both are collapsing at once. Coding agents have gutted the cost of the unglamorous work that used to make replatforming a two-year programme, the schema translation, the connector rewrites, the dual-running reconciliation that nobody budgets for and everybody pays for. And data portability has hardened from courtesy into law. Regimes such as the EU Data Act oblige providers to remove obstacles to switching and to hand over exportable data in a structured, machine-readable format (European Parliament and Council, 2023).

So the tables come with you. Here is what does not, unless you engineered for it: the object model that says a rebuild and an overhaul are different events with different warranty consequences. The link that ties a specific invoice line to a specific contract rate table. The action definition that says who may write off a variance and above what threshold a second approval kicks in. The validation logic encoding ten years of hard-won exceptions. None of that is "your data" in the export-a-parquet-file sense. It is your meaning, and in most platforms it is expressed in proprietary configuration that has no life outside the walls.

That is the substitution under way in the AI era. Vendors can no longer hold your rows hostage, so the compounding asset moves up a layer. Every workshop where your maintenance planners explain the difference between a failure and a defect to a vendor's deployed engineers, every bespoke pipeline that encodes a rule your own wiki never captured, deepens a semantic dependency that a data export will never discharge. You can leave with your tables and still be unable to leave, because the map of what the tables mean stays behind.

The stakes compound from here. That same map is what grounds your agents, pins their behaviour, and generates your compliance evidence. Surrender it and you have not just made switching expensive. You have made someone else the landlord of your determinism, your accuracy, and your auditability.

Notice what actually trapped you in that scenario. Not the platform. The location of the definitions. Meaning that exists only as someone else's configuration is meaning you have already surrendered. Which points directly at the counter-move: put the definitions somewhere you control, in a form any platform can consume.

What owning it actually looks like

This is not an argument for refusing the platforms. Ontology-driven platforms are productive precisely because the pattern works, and I will not pretend otherwise. The argument is about what you bring to them. Author the ontology yourself. Version it, govern it, and let platforms compile it. Never accept it as a by-product of a deployment, recoverable only by re-running the workshops.

Concretely: the master copy of your semantic layer lives in a repository you control, in a neutral, boring format, reviewed like code. It does not need to be clever. It needs to be explicit. For a model risk domain in a bank, the skeleton fits on one screen.

entities:
  FinancialModel:
    keys: [model_id]
    properties: [purpose, tier, owner_desk, last_validated]   # tier: 1 | 2 | 3 by materiality
  ValidationReview:
    keys: [review_id]
    properties: [outcome, review_date, open_findings]
  ModelChange:
    keys: [change_id]
    properties: [category, submitted_date, status]   # category: recalibration | methodology | data_source
  MarketDataFeed:
    keys: [feed_id]
    properties: [provider, asset_class, snapshot_frequency]

relationships:
  - FinancialModel owned_by TradingDesk
  - ValidationReview assesses FinancialModel
  - ModelChange applied_to FinancialModel
  - FinancialModel consumes MarketDataFeed

actions:
  approve_model_change:
    target: ModelChange
    guard: latest_validation_outcome == approved && open_findings == 0
    authority: model_risk_officer
  grant_production_use:
    target: FinancialModel
    guard: months_since(last_validated) <= 12
    authority: head_of_model_risk
    audit: mandatory

Nothing in that fragment is sophisticated. That is the point. A head of model validation can read it and object to it, which is the property that matters most. From a file like this you can generate platform configuration, warehouse semantic models, API contracts, agent tool definitions, and access policies. When you change vendors, the file comes with you and the regeneration is mechanical. The workshops do not have to be re-run, because their output was never trapped in a console.

Now run the three failure modes against it. An agent whose tools are compiled from this file cannot hallucinate a fifth entity type; it can approve a model change that exists or fail loudly, because the entity register bounds what it may talk about. Its behaviour stops drifting between runs, because the guard on approve_model_change is a versioned expression, not a paragraph of prompt the model interprets differently on Tuesday; the judgment lives in the file, and the model's job shrinks to invoking it. And when the auditor arrives, authority: head_of_model_risk and audit: mandatory are not aspirations in a policy document. They are enforced properties of the system, with the trace to prove it. Grounding, determinism, evidence: one artifact, three failure modes retired.

Three disciplines follow from treating the ontology this way. First, the neutral form is written before the platform is configured, not reverse-engineered afterwards; if a definition exists only inside a vendor tool, it does not exist. Second, changes go through review by the people who own the business concept, not just the people who own the pipeline, because an ontology nobody disputes is an ontology nobody read. Third, exportability of semantics becomes a procurement gate: ask the vendor to demonstrate, before signature, how object types, links, action definitions, and their guards leave the platform in a documented format. The demonstration is more informative than the answer.

The important bit

Enterprises do not drift into renting their ontology out of stupidity. They drift into it because extracting a real ontology is slow, contested, and politically expensive. It means adjudicating between the plant's definition of downtime and finance's definition of downtime in a meeting neither side enjoys, with a decision at the end that one of them will resent. A vendor's deployed engineers solve a problem your org chart cannot: they are paid outsiders with the standing to sit in that argument until it resolves, and no career at stake in the outcome. Look past the software and that is a large part of what the invoice buys. Arbitration, packaged as engineering.

Buy it if you need it. It is often worth every dollar. But contract for the output, not just the relief. The resolved definitions, the entity registers, the action guards, the exception logic: name them as deliverables, in the neutral form, landing in your repository as they are produced. The vendor keeps the generalisable patterns, as vendors always will. You keep the specific asset your people's time created. That is the difference between hiring a facilitator and donating your institutional knowledge to someone else's balance sheet.

The founder-side essays are right about the destination. Durable advantage now accumulates in meaning, not storage, and whoever holds the authoritative description of an operation holds pricing power over everyone who needs it. Those essays simply address the party that hopes to hold it. I am addressing the other party. Your organisation has spent decades learning how it actually works, and most of that knowledge still sits in the heads of people who are very good at their jobs and very close to retirement. Turning it into explicit, versioned, portable form is the most valuable data engineering your team can do this decade. It is the same artifact, remember, that retires the three failures filling your post-mortems: it grounds what your agents may assert, fixes what they may do, and proves both to anyone who asks. Where that artifact lives when the work is done decides who banks the value.

Build the map. Let the platforms render it. Never let them own it.

References

European Parliament and Council (2023) Regulation (EU) 2023/2854 of the European Parliament and of the Council of 13 December 2023 on harmonised rules on fair access to and use of data (Data Act). Official Journal of the European Union. Available at: https://eur-lex.europa.eu/eli/reg/2023/2854/oj (Accessed: 10 July 2026).

FounderCoHo (2026) How ontology became a moat: Palantir's FDE model, demystified. Substack, 8 July. Available at: https://foundercoho.substack.com/p/how-ontology-became-a-moat-palantirs (Accessed: 10 July 2026).

Gruber, T.R. (1993) 'A translation approach to portable ontology specifications', Knowledge Acquisition, 5(2), pp. 199-220.

Palantir Technologies (2024) Palantir reports its fifth consecutive quarter of GAAP profitability; fourth quarter GAAP EPS of $0.04. Business Wire, 5 February. Available at: https://www.businesswire.com/news/home/20240203047330/en/ (Accessed: 10 July 2026).

Palantir Technologies (2026) Ontology overview, Foundry documentation. Available at: https://www.palantir.com/docs/foundry/ontology/overview (Accessed: 10 July 2026).

Ryseff, J., De Bruhl, B.F. and Newberry, S.J. (2024) The root causes of failure for artificial intelligence projects and how they can succeed: avoiding the anti-patterns of AI. RAND Corporation, RR-A2680-1. Available at: https://www.rand.org/pubs/research_reports/RRA2680-1.html (Accessed: 10 July 2026).

Trust Is an Engineering Output

Andrew Stevens — Fri, 10 Jul 2026 09:21:55 +0000

A players' union arrived at the athlete-data platform to investigate how its members' data was being handled. The platform had nothing to hide, its access controls were sound, its data accurate, its sharing rules strictly enforced, and its deletion process reliable. By every internal measure, it ran well.

None of that matters, when the customer had not come to be told the system was correct, it had come to be shown. Trust turned out to be the one thing the engineering team could not produce on demand.

The union meeting

What follows is a composite, but anyone who has sat on the engineering side of a meeting like it will recognise the pattern.

The union's representative opened with a simple question. The platform held biometric and performance data on every player he represented, and he wanted to know who could see it. The engineering lead had a good answer, access was role-based and enforced in the system rather than written in a policy and hoped for: medical staff saw medical data, coaching staff saw performance data, and nobody reached anything they were not entitled to. He said he believed her, and then he asked her to show him. For one named player, on one date, who had accessed his data, and why.

That was where the good answers ran out.

The records existed, but they lived across several systems, and assembling them into a single account would take the team a day or two. He moved on. Could she prove the player's data had never been shared with a betting partner, or with a club he was about to be transferred to? It would not have been, she said, because that sharing was not permitted. Not permitted, he pointed out, is a policy and not a proof, and he was asking whether she could demonstrate it had not happened. She would have to go and check.

The last question was about deletion. The player had asked for last season's data to be removed, and it had been, in the primary database. What about the backups, the analytics copies, and the model that had already been trained on it? Those were separate systems. She would have to come back to him.

The representative was not hostile, and he was careful to say he was not accusing anyone of anything. His point was narrower and harder to answer. If the platform could not show him what it had done, then from where he sat, the inability to prove it was indistinguishable from the thing he had come worried about. That was the part that had to change.

The engineering lead was almost certainly telling the truth throughout. The controls existed, the sharing had not happened, and the deletion had been actioned. What she could not do, in the room, with the person who had standing to ask, was produce a verifiable account of any of it. She was not being tested on whether the platform was well run. She was being tested on whether it could demonstrate its integrity on demand, to an outsider. The gap between being correct and being able to prove it is the whole of the problem, and it is where the trust the platform assumed it had quietly disappeared.

Correct but unprovable was good enough for a long time, because nobody with the standing to demand proof was likely to show up. That assumption has failed, and the meeting is what its failure looks like in a room. Closing that gap is the engineering work that the previous five posts in this series each described one face of.

What trust used to mean operationally

For most of the history of enterprise technology, trust was a relationship backed by a document. An organisation was trusted because it had the certifications on the wall, a signed data-processing agreement in the drawer, and an audit sign-off from last year. Trust was a static artefact. It was produced occasionally, by people, for a named audience, describing a state of affairs at a single point in time. A SOC report or an ISO certificate said, in effect, this was true when we looked. Everyone quietly agreed to treat the snapshot as though it still described the present.

That worked because of two assumptions. The first was that the party asking would accept a description in place of the underlying facts. The second was that checking the description against reality was expensive enough that almost nobody did. Trust could rest on reputation and a binder because verification was rare and costly. Those are the same conditions that let evidence be assembled after the fact rather than emitted continuously (see Part 3).

Both assumptions are gone. Individuals now hold enforceable rights to know exactly how their personal data is processed, and to have it corrected or erased, exercisable by them or by their representatives (European Parliament and Council, 2016). A union, a regulator, or a customer no longer has to accept "that is not permitted" as an answer. They can ask to see, and increasingly they have the legal standing to insist. The binder still exists. It is simply no longer sufficient. The question is no longer whether you can describe your controls. It is whether you can prove they held for a specific case.

What it has to mean now

Trust must now be a property the system produces on demand. It has to be verifiable by whoever has standing to ask, without them taking the organisation's word for it. That is the difference between two moves. One is saying, here is our access policy. The other is handing over an intact, tamper-evident record of every access to a player's data, in seconds. That second move is what data trust means once the people asking can insist on proof. It is an output of the system, not a claim about it.

This is what it means to treat trust as an engineering output. Audit-ready systems do not scramble to assemble a defence when the union or the regulator arrives. They answer the question as a query, because the evidence is a running product of how they operate. System trust becomes a matter of whether the architecture can render an account of itself. Transparent systems are simply the ones that can do so without a two-day reconstruction project.

The standards are moving the same way. Demonstrable, certifiable governance of AI systems now has its own management-system standard, ISO/IEC 42001, built around continuous, evidenced control rather than a point-in-time attestation (ISO/IEC, 2023). The demand arrives from every direction at once. Regulators and auditors ask for proof. So do customers, boards, commercial partners, unions, and governments, each with its own standing and its own version of the same two words: show me. The direction is unmistakable. We are moving from asserting trust to producing it.

The engineering disciplines that produce it

Trust is not a single control that can be bought and switched on. It is the sum of the five tensions this series has worked through, each engineered correctly, which is why trust architecture is really an aggregate of the other five rather than a discipline of its own.

Sovereignty engineered into placement lets an organisation show exactly where a given data point lives, and under whose jurisdiction (see Part 1). Load handled so that peak is the steady state means the system holds precisely when scrutiny arrives, which is usually its worst day (see Part 2). Evidence emitted as a runtime property means the record exists before anyone asks for it (see Part 3). Telemetry governed as a data product means the operational truth is captured, owned, and reachable, rather than trapped in the system that produced it (see Part 4). Coherence across clouds means the account is single and complete, not three partial logs no one can reconcile (see Part 5).

Put together, those are the components of engineered trust: portable identity, immutable and hash-linked evidence, first-class lineage, policy enforced as code, and a control plane that spans the estate. None of them is exotic on its own. The difficulty, and the discipline, is engineering them together, so that identity, evidence, lineage, policy, and control reinforce one another instead of sitting in five separate systems that have to be reconciled by hand the moment someone asks.

That is evidence engineering and accountability engineering in the same motion, and it is why a durable governance architecture cannot be bolted on at the end. It is assembled from the data foundation up, which is the work Sakura's Data & AI practice exists to do, and it is secured at the identity and control layer, which is where Sakura's Security practice works. The platform in the meeting did not lack good intentions or competent engineering. It lacked these disciplines wired together, so that an account of itself was always one query away.

How this goes deeper inside each industry

While this series has argued the general case, a set of industry deep-dives is coming next, each taking the argument inside one of the sectors where Sakura Sky works and studying how trust is engineered under its particular pressures:

The financial services set will examine producing regulatory evidence at machine speed, the sovereign-cloud question inside a bank, and identity as the thing the bank now runs on.
The media set will look at launch-day scale as a permanent condition, protecting intellectual property in a generative world, and audience telemetry as a strategic asset.
The government set will treat sovereign cloud as an architecture rather than a procurement, alongside API governance done properly and legacy modernisation that meets the audit bar.
The pharma and healthcare set will cover trial data that survives the inspector, the lab notebook as a data product, and patient data across boundaries.
The QSR and retail set will work through the loyalty backend as a data-engineering problem, thousands of sites on one pipeline, and multi-cloud retail without the mess.

Each brings this same argument down to the ground of a single industry: trust is not claimed, it is built.

Across every one of those industries, the cross-industry trust question reduces to the same thing. Can the organisation produce, on demand, a verifiable account of what its systems did? Turning that capability from an aspiration into a standing output is what Sakura's GRC service is built to deliver.

References

European Parliament and Council, 2016. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May, pp. 1-88. Available at: https://eur-lex.europa.eu/eli/reg/2016/679/oj [Accessed 10 July 2026].

ISO/IEC, 2023. ISO/IEC 42001:2023 Information technology, Artificial intelligence, Management system. International Organization for Standardization and International Electrotechnical Commission. Available at: https://www.iso.org/standard/81230.html [Accessed 10 July 2026].

Multi-Cloud Versus Consolidation

Andrew Stevens — Thu, 09 Jul 2026 08:29:51 +0000

A government agency committed to multi-cloud for resilience. The logic was sound in the business case: spread critical services across more than one provider so that no single outage, and no single commercial relationship, could take the whole thing down. Two years later the agency was running three clouds, each with its own team, its own pipelines, and its own way of doing identity, and none of the three could fail over to either of the others because they had never been built to talk. The resilience was theoretical, the cost was real and recurring, and the commitment was politically unbreakable because it had been announced as strategy.

Nobody could say the multi-cloud plan had failed. Nobody could say what it was actually delivering either.

This is the shape the multi-cloud-versus-consolidation debate takes in practice, and both sides of it have been corrupted by procurement narratives. One camp sells multi-cloud as resilience and leverage; the other sells consolidation as simplicity and savings, meanwhile the ground truth is that most enterprises already run several clouds whether they meant to or not, using an average of well over two public providers and, in most cases, private infrastructure alongside them in a hybrid cloud estate (Flexera, 2025). The cloud consolidation instinct is not wrong, but it usually arrives too late to be the real question, because by the time anyone drafts a consolidation slide the cloud strategy has already been settled in a hundred small delivery decisions that nobody went back to revisit.

The real question is how to engineer coherence across what an organisation already has.

This post lays out five things multi-cloud actually demands once it is treated as an architectural fact rather than a strategic choice, and the earlier argument that placement belongs in the data and identity layers rather than at the procurement desk runs straight through all five (see Part 1).

The three-cloud government

Look more closely at how the agency ended up where it did, because the mechanism is general, the resilience mandate was real and reasonable. What turned it into three islands was that it was discharged as a procurement exercise rather than an architectural one. Each cloud was stood up as its own programme, with its own delivery team, its own landing zone, its own identity model, and its own security posture, because that was the fastest way for each team to ship. Standardising inside each cloud was achievable and each estate, taken alone, was competently run. The problem lived entirely in the gaps between them.

Resilience was the first casualty.

You cannot fail a workload onto a platform it has never been integrated with, and three environments that share no identity, no data plane, and no common control cannot actually take over from one another. The failover existed on a diagram and nowhere else. Cost was the second. Three platforms meant roughly three times the engineering surface, triplicated tooling, and three teams solving the same problems in parallel, none of which the original business case had priced. And because the commitment was public, none of it could be unwound; the only way out was forward, through coherence.

That is the useful reframing. Multi-cloud stopped being a decision the moment it became a fact on the ground, and the same is true for most enterprises reading this. Coherence is engineered across clouds, not chosen between them. Government does have working models for this, where shared standards and a common governance layer let independently built systems interoperate, as Singapore's whole-of-government approach to platform and API governance shows (Singapore Government API Governance case study). The rest of this post is about what that coherence actually requires.

The five things multi-cloud actually demands

Coherence is not a single feature you buy. It is five distinct properties an architecture has to hold at once, and the organisations winning at multi-cloud have engineered all five rather than any one of them in isolation.

1. A control plane that spans clouds

The first demand is the one everything else hangs off: a control plane that spans clouds.

A control plane is the layer that makes decisions about the estate, who is allowed to do what, where a workload may run, which policy applies, and whether an action is permitted, as distinct from the data plane that does the actual work. In a single cloud, the provider gives you one for free. Across three, you either build one that spans them or you have none, and three well-run estates with no common control are still three islands.

This is the move that separates coherent multi-cloud architecture from expensive sprawl. Standardising inside each cloud, making each landing zone tidy, feels like progress but does not close the gaps, because the gaps are between the clouds, not inside them. A spanning control plane authenticates, authorises, places, and governs uniformly regardless of which provider executes the workload: a policy engine, an identity broker, a placement layer, and an evidence aggregator that sit above the providers rather than inside any one of them. That is where cloud governance actually comes to live in a multi-provider estate, and the four demands that follow are the things this layer has to carry. Building that layer, attested and provider-neutral, is the core of what Sakura's Cloud practice does. The first thing that control plane has to carry, before anything else, is identity.

2. Identity that does not fragment

The second demand is that identity must not fragment along cloud boundaries.

Left to defaults, each provider's native access management becomes its own identity island: a workload in one cloud and a workload in another authenticate by different mechanisms, hold different credentials, and cannot verify each other without falling back to shared secrets passed across the gap. Every one of those secrets is a liability, and the security posture forks the instant the second cloud appears.

The resolution is portable workload identity, a way of giving every workload, service, and agent an identity that is the same regardless of which cloud it runs in. The open standard here is SPIFFE, implemented by SPIRE, a graduated project of the Cloud Native Computing Foundation whose federation model exists precisely to establish trust across organisational and cloud boundaries (CNCF, 2022). With cross-cloud identity in place, a call from a workload in one provider to a workload in another is authenticated the same way as a local one, short-lived credentials replace the long-lived secrets that used to bridge the gap, and the security model stops forking per environment. Uniform identity is also what makes the next demand safe, because once workloads can reach each other securely across clouds, there is far less reason to copy data into all of them.

3. Data products that do not duplicate

The third demand is that data has to be exposed across clouds as products, not copied into each of them.

The default failure mode is duplication: a dataset that a workload in another cloud needs gets replicated into that cloud, and then into the next, until the same data exists in three places, drifting apart and each carrying its own governance and its own copy of the risk. The cross-cloud data problem is not that data cannot move; it is that duplicating it multiplies cost, staleness, and exposure at once, with egress charges the visible tax and governance drift the hidden one. A dataset copied nightly into two other clouds is three datasets to secure and three to keep current, plus two recurring egress bills, and by the second week the three copies have already begun to disagree.

The alternative is to treat data as a product with a clear owner, contract, and access path, reachable across the cloud boundary rather than replicated across it, which is the same discipline the previous post argued operational telemetry now needs. A well-defined data product exposed through the control plane lets a consumer in one cloud use data that lives in another without a copy landing locally. Duplication becomes the exception you justify, not the default you inherit. That discipline also happens to be where a large share of multi-cloud cost quietly hides, which is the fourth demand.

4. Cost discipline that survives autonomy

The fourth demand is cost discipline that survives team autonomy.

Multi-cloud multiplies spend by construction, and organisations already find single-cloud spend hard to control: a large majority report struggling to manage their cloud costs even before a second and third provider enter the picture (Flexera, 2025). Give three autonomous teams three providers with three billing models and cost visibility fragments completely, which is how multi-cloud cost overruns become invisible until the invoice arrives.

The answer is not to remove the autonomy that lets teams move quickly; it is to make cost a property the control plane enforces rather than a report someone assembles after the fact. Consistent tagging and allocation across providers, budget guardrails expressed as policy that can halt a runaway workload before the month closes, and showback that makes each team see its own spend, turn the practice of cloud financial management, now widely called FinOps, from a monthly reconciliation into a live control. Autonomy without visibility is just untracked spend, and multi-cloud makes the gap between the two expensive fast. The last property the control plane has to carry closes the loop the agency opened, which is proof.

5. Operational evidence that holds up across providers

The fifth demand is operational evidence that holds up across providers.

When a workload fails, or an auditor asks how a decision was reached, an organisation needs one coherent account of what happened, not three partial logs in three formats that no one can reconcile under pressure. Multi-cloud makes this harder because every provider emits its own telemetry, its own audit trail, and its own idea of an event, and left alone they never add up to a single chain.

This is where the argument in the third post of this series, that evidence has to be an engineered property rather than a retrospective reconstruction, meets multi-cloud head on (see Part 3). Coherent evidence across clouds means normalising those disparate signals into one verifiable record at the control-plane level, so a question about any workload resolves against a single account regardless of which provider ran it. Without it, the resilience and compliance claims that justified going multi-cloud in the first place cannot actually be demonstrated across the estate, which returns the agency to exactly where it started: a strategy nobody could fault and nobody could prove.

The organisations that win at multi-cloud stop trying to standardise inside each provider and instead engineer these five properties as one coherent layer across all of them, which is the coherence Sakura's Managed Services team builds and runs once the architecture is in place.

References

CNCF, 2022. SPIFFE and SPIRE Projects Graduate from Cloud Native Computing Foundation Incubator. Cloud Native Computing Foundation. Available at: https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/ [Accessed 9 July 2026].

Flexera, 2025. Flexera 2025 State of the Cloud Report. Flexera. Available at: https://info.flexera.com/cm-report-state-of-the-cloud [Accessed 9 July 2026].

Telemetry Is Becoming the Business

Andrew Stevens — Wed, 08 Jul 2026 10:38:29 +0000

It started, the way these things usually do, with a maintenance problem. A quick-service restaurant chain with a few thousand sites began pulling data off the equipment in its kitchens: fridge and freezer temperatures, fryer and grill status, oven cycles, drive-thru timers, and the order and payment stream from every till, all reporting continuously from each restaurant. The first goal was narrow and sensible, to stop losing stock to a fridge that failed overnight and to stop losing lunch service to a fryer that went down at noon. It worked, so the same feeds were turned toward speed of service, which found real money in the drive-thru, and then toward labour scheduling and demand forecasting, which found more. Somewhere in that sequence the data stopped being a maintenance tool and turned into something else. By the time anyone gave it a name, the telemetry coming off the estate was arguably the most strategically valuable asset the company owned, and the finance team first learned this from a single line in a board paper. Nobody had set out to build a strategic asset. They had built a monitoring feed, and it had grown into one while no one was managing it as such.

That progression, from by-product to primary asset, is now playing out across quick-service restaurants, retail, media, financial services, and increasingly healthcare. The signal a business throws off while doing its actual work, its operational telemetry, is becoming one of the things the business is most valuable for knowing. The trouble is that almost nobody's data infrastructure was built for that. It was built for telemetry as exhaust: cheap to store, quick to sample, safe to discard. This post follows the restaurant chain's estate through each stage of the shift, because the architecture that has to change is easiest to see through the thing that changed it.

The telemetry moment

Go back to the moment the data changed jobs. For the first years of the programme, the restaurant telemetry lived where operational signals always live, in the hands of the people who keep the sites running. It fed equipment-monitoring portals and a facilities dashboard, it was watched by store operations and maintenance teams, and it answered exactly one kind of question, which was whether a given restaurant was operating normally right now. That was the job, and the setup did it well.

The moment arrived when a different kind of question needed the same data. Someone at the centre wanted to lower cost per order and lift speed of service across the whole estate, which meant understanding how equipment health, prep times, drive-thru flow, and staffing interacted across thousands of restaurants over months, not one site over one shift. The data to answer that existed. It had been flowing for years. But it was trapped in systems built to alarm on a single failing appliance, not to be queried across time or joined with rosters, weather, promotions, and sales. The question was strategic and the data was operational, and the gap between them was pure architecture. Answering it took a one-off extraction that nobody owned: store operations had no remit to serve analytics, the analytics team had never been granted access to the equipment systems, and the data had to be lifted out by hand, cleaned, and stitched to context that lived in four other places. The answer, when it eventually came, was good enough to prove the point and slow enough to prove the problem.

This is the general shape of the telemetry moment, and it recurs in every business that runs on instrumented operations. It is the first time an operational feed is asked a question its owners never anticipated, and the data turns out to be present but unusable in the form it was kept. The signal was always valuable. It was simply filed under maintenance.

How telemetry got demoted

To understand why the architecture is wrong, look at how operational telemetry came to be treated as exhaust in the first place, because the demotion was deliberate and, at the time, correct. For years the entire purpose of this data was to answer one question in the present tense: is this site behaving normally. Everything about how it was handled followed from that. It was captured at high frequency, kept for a short window, downsampled or discarded once the window passed, and stored in store controllers and equipment-vendor portals tuned for live monitoring rather than historical analysis.

It was also walled off. The equipment feeds lived on the operational side of each restaurant, owned by facilities and store operations, deliberately kept apart from the corporate systems for sound reliability and payment-security reasons. This was industrial IoT in a commercial-kitchen setting, connected refrigeration, cooking equipment, and point-of-sale hardware, and it was governed as site infrastructure, not as information. The data engineering teams who build analytical platforms mostly never saw it, and had no reason to expect to.

None of that was a mistake. It was the right design for the question being asked. Storing every reading forever, at full fidelity, in a warehouse an analyst could reach, would have been waste when the only consumer was a technician checking whether a freezer was holding temperature. The demotion of telemetry to a disposable by-product was a rational response to its narrow use. It stopped being rational the moment the use widened, and the architecture did not notice the moment had come.

What it is now

What the chain discovered is that the same feed, unchanged at the sensor, had become several different things at once. It was training data for the models that forecast demand and optimise labour. It was the evidence base for menu, pricing, and new-site selection. It fed supply-chain replenishment and gave the food-safety team continuous proof that the cold chain had held, rather than a clipboard checked twice a day. The restaurants were doing the same job they always had. The telemetry had become the raw material of data-driven operations across the business.

The precise word for what it had become is a data product: a dataset deliberately built to be consumed by people and systems beyond the team that produced it, with the discoverability, quality, and reliability that implies. The idea that data should be treated as a product with real consumers, rather than as a by-product of the system that emits it, is one of the load-bearing principles of the data mesh approach (Dehghani, 2022), and operational telemetry is where it now bites hardest. The shift is from operational data as a means to an operational end, to operational data as an asset with its own standing, its own consumers, and, in a growing number of cases, its own external market. Some chains now benchmark across franchisees or sell insight derived from their estates, and the years of history behind those numbers are a moat a competitor cannot replicate quickly. The exhaust became inventory.

The data architecture this actually requires

Once telemetry is a strategic asset, the infrastructure built for exhaust starts failing in specific, predictable ways, and the fixes define the telemetry architecture the asset actually needs. The first is retention and fidelity. A system that downsamples readings to death because storage was once precious destroys exactly the history a model needs. The asset requires purpose-built time-series data storage that keeps long, high-resolution history and supports both real-time analytics on the live stream and retrospective analysis across years. The elastic capacity for that, without overbuilding a private estate for a load that spikes at every lunch rush and subsides, is one of the reasons this work tends to land on cloud foundations, which is a large part of what Sakura's Cloud practice builds underneath it.

The second is movement and contract. The data has to flow off tens of thousands of devices across the estate into an IoT data platform that can absorb millions of events without dropping them, and it has to arrive with a schema, an owner, and a quality guarantee. Treating each telemetry stream as a data product means giving it a contract and an owner responsible for it, so the analysts and models downstream can find it and trust it rather than reverse-engineering it every time. It also means separating the two clocks the asset runs on: a streaming path that carries the live signal for real-time analytics and alerting within seconds, and a batch path that lands the full-fidelity history the models and long-range analysis depend on. Systems built only for monitoring tend to have the first and not the second, which is why the historical asset, when someone finally reaches for it, so often turns out to be full of holes. This is where telemetry crosses back into the ground the earlier posts in this series covered, because a data product without governed provenance is not one you can build decisions on (see Part 3).

The third is security, and it is the one most often underestimated. The instant operational telemetry leaves the store network to feed corporate analytics, the separation that protected the restaurant environment, where connected kitchen equipment sits alongside payment terminals, is breached, and the attack surface widens in both directions. Piping equipment and till data into a lake without rebuilding that boundary is how an analytics convenience becomes a path into store systems. The discipline for doing it properly is well established in the operational-technology security standards (ISA/IEC, n.d.), and getting the segmentation, identity, and monitoring right is exactly the kind of work Sakura's Security practice does at the seam between operations and IT.

Who is doing it well

The organisations getting this right look similar across very different industries. The leading quick-service and retail chains treat their store and equipment telemetry as products with owners and service levels rather than as monitoring feeds, and keep the long, high-fidelity history that demand forecasting and cold-chain assurance need. Grocers do the same with shelf, refrigeration, and supply-chain signals. The pattern extends well beyond the shop floor: media businesses treat playback and engagement telemetry as a governed audience asset, and financial services firms treat platform and transaction telemetry the same way. The common thread is not the industry or the tooling. It is that the telemetry was given an owner, kept at fidelity, secured across the operations-to-IT boundary, and made discoverable across the business.

The tell of doing it badly is just as consistent. The data still lives only where it was produced, every strategic question that needs it becomes a fresh extraction project, and the value everyone can see in the signal never quite becomes value anyone can use. In each case where it goes right, the change was organisational as much as technical: someone was made accountable for the telemetry as a product, with a budget and a service level, instead of leaving it as a shared cost that nobody owned and everybody assumed. The chain in this story eventually got there too, but only after the board paper, which is a more expensive way to find out than deciding it in advance.

The organisations pulling ahead engineer the signal their operations throw off with intent, giving it an owner, a contract, and a deliberate place in the architecture, which is the work Sakura's Data & AI practice does when it turns raw operational telemetry into data products the whole business can rely on.

References

Dehghani, Z., 2022. Data Mesh: Delivering Data-Driven Value at Scale. Sebastopol, CA: O'Reilly Media. Available at: https://www.oreilly.com/library/view/data-mesh/9781492092384/ [Accessed 8 July 2026].

ISA/IEC, n.d. ISA/IEC 62443 Series of Standards: Security for Industrial Automation and Control Systems. International Society of Automation and International Electrotechnical Commission. Available at: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards [Accessed 8 July 2026].

Evidence Versus Speed

Andrew Stevens — Tue, 07 Jul 2026 13:55:50 +0000

The question that stopped the room was not a difficult one. Halfway through a routine inspection, the regulator pointed to a single figure in a phase three submission and asked, reasonably enough, where it had come from. Which instrument had measured it, what had happened to it on the way into the dossier, whose sign-off sat behind each step. Everyone around the table knew the number was right, and knew the system that produced it had done its job. What they could not do, with the inspector waiting, was pull that figure back through every hop and show, on the spot, that someone else could arrive at it the same way. The company had the answer, but producing the proof was another matter entirely.

This is a lineage gap, and it is not only a pharma problem. It is the visible symptom of a long-standing assumption that has finally stopped being true: that speed and evidence are separable, that an organisation can move fast now and assemble the regulatory evidence later when someone asks. That assumption held for a long time, through generations of audit regimes, because someone rarely asked, and when they did, reconstructing the proof by hand was tedious but possible. Both halves of that are now false.

This post works backwards from the symptom, through how evidence used to be produced and what regulators are now asking for, to the architecture that closes the gap and the reason closing it makes an organisation faster rather than slower. Earlier posts in this series argued that sovereignty and load are engineering questions before they are anything else (see Part 1). Evidence is the same kind of question.

The lineage gap

Start with what the inspector was actually asking for. Data lineage, sometimes called data provenance, is the traceable history of a data point: the origin it came from, every transformation applied to it, and the identity and authority behind each step. The pharma company had all of the underlying events somewhere. The instrument wrote to a log. The transformation ran in a pipeline that emitted its own log. The approval sat in a workflow tool. What it did not have was those events linked to each other, fixed against later alteration, and addressable by the one thing the inspector cared about, the data point itself.

That is the anatomy of the gap. The system was built to produce outputs, and it recorded its outputs well. It was not built to record the provenance of those outputs as a connected, verifiable object. Reconstruction was therefore a human task: an analyst stitching timestamps across three systems, inferring the links, and producing a narrative that was plausible rather than proven. Plausible is no longer the bar.

The same gap appears wherever a consequential decision has to be defended after the fact. A bank asked to show why a specific credit decision was made can usually show the decision but not the full lineage of the inputs that drove it. A government department asked who accessed a citizen record, under what authority, and whether that authority was still valid at the moment of access, often finds the access logged but the authority unlinked. In every case the events exist and the connective tissue does not. The gap is not a missing log. It is a missing architecture for turning logs into evidence.

What evidence used to look like

Work backwards, and the reason the gap exists is historical. For most of the compliance era, evidence meant artefacts assembled for a point in time. A team knew an audit or an inspection was coming, and it spent the weeks before assembling the binder: printed logs, screenshots of configuration, signed PDFs, a spreadsheet of controls mapped to a framework, a sample of records pulled and annotated. The evidence was manufactured for the occasion and then set aside until the next one.

This worked for two reasons, and both have expired. The first was cadence. Audits were periodic, so producing evidence a few times a year was survivable, even if each round consumed a quarter of somebody's life. The second was the cost of verification. Checking that the binder matched reality was expensive and slow, so verifiers sampled lightly and trusted the description. The controlling assumption underneath both was that the document was the artefact and reality was something you checked rarely.

Regulated industries did build genuine data-integrity discipline in this period. The FDA's electronic-records rules established that records had to be attributable, legible, contemporaneous, original, and accurate, backed by secure, computer-generated, time-stamped audit trails (U.S. Food and Drug Administration, n.d.). That was real and it mattered. But it was still framed around records as things you keep and produce, not around evidence as a property the running system emits continuously. The binder got thicker and better governed. It remained a binder.

What regulators are actually asking for now

The bar has moved, and it has moved in the same direction across every regulated sector at once: from "can you describe your controls" to "can you produce verifiable evidence, for this specific item, on demand." In clinical research, the revised good clinical practice guideline reached final adoption in January 2025, went live across the major regulators in mid-2025, and gains its second annex during 2026. It expands the old integrity principles to ALCOA++, adding complete, consistent, enduring, and available, and reframes data governance as a lifecycle property rather than a filing obligation (ICH, 2025). The expectation is no longer a well-kept archive. It is the ability to trace a data point through its whole life at inspection speed.

The audit profession is rewriting its own foundations around the same shift, and the pace has picked up through 2026. Having issued a catalog of the specific issues that automated tools and machine-generated evidence create for its standards (IAASB, 2025), the international standard-setter is now redrafting the core audit-evidence standard itself: the first full draft of the revised ISA 500 was considered in March 2026 and is moving into public consultation, explicitly to clarify how evidence obtained through automated tools should be treated (IAASB, 2026). In parallel, the internal-control guidance issued in February 2026 for organisations running generative systems in financially material processes is blunt that set-and-forget assurance is inadequate for probabilistic models, and that any output affecting a material figure must be supported by appropriate, traceable evidence (COSO, 2026).

Regulation of AI systems codifies the same expectation directly. The EU AI Act requires high-risk systems to keep automatic logs over their lifetime, obliges deployers to retain those logs for at least six months, and sustains post-market monitoring, which is to say it requires evidence to be a running output of the system rather than a retrospective reconstruction (European Parliament and Council, 2024, Articles 12, 26 and 72). The 2026 Digital Omnibus package rescheduled when the high-risk obligations begin to bite, but not their shape: the logging and monitoring duties are intact, and the direction is settled (European Commission, 2026). Read together, these are not separate compliance projects. They are one signal. The reconstructable, machine-verifiable chain is now the deliverable, and the binder is a record of a world that no longer sets the terms.

The architecture of audit-readiness

Move forward from the diagnosis and the resolution is an audit-ready architecture, not a procedural fix. This compliance architecture becomes achievable when evidence is engineered into two layers of the system rather than assembled on top of it.

The first is the data layer. Lineage has to be captured at write time as first-class metadata, not reconstructed at audit time from scattered logs. Every dataset and every transformation records, as it runs, the inputs it consumed, the version of the code that touched them, the identity that authorised the step, and the time it happened, all linked by shared identifiers. When that is in place, the inspector's question stops being an archaeology project and becomes a query: give me the lineage of this data point, and the system returns it. Building the data layer so that provenance travels with the data, rather than being inferred afterwards, is the core of the work Sakura's Data & AI practice does under a regulated architecture.

The second is the execution layer. Every consequential action, a tool call, a policy decision, an access to a protected record, emits an immutable, tamper-evident record as an ordinary byproduct of running. Hash-linking those records means any later alteration is detectable, which is the difference between a log you keep and evidence someone else can trust. Policy decisions are themselves recorded as decision objects: what was requested, what rule applied, what was permitted or denied, and why. An evidence pipeline then makes all of it addressable, so a request for a given control, data point, or period resolves against a real chain rather than a narrative. The defining property is simple to state and demanding to build: evidence is produced as a side effect of operating the system, whether or not anyone ever asks for it. That property, engineered once, is what turns audit readiness from a recurring scramble into a standing capability. It is engineered compliance in the literal sense, and it is the outcome Sakura's GRC service is organised around.

The speed dividend

The counterintuitive part is that this makes regulated organisations faster, not slower. When evidence is emitted continuously, the audit cycle stops being a project and becomes a machine-speed audit: a query against a live chain rather than a quarter of reconstruction. There is no change freeze while the binder is assembled, no team pulled off delivery to reconstruct history, and regulated workloads carry their own proof as they run. The proof travels with the work, so a release does not have to pause to prove itself.

The organisations that bolt evidence on afterwards pay for it twice. They pay once in the reconstruction, the analyst-weeks spent stitching logs into a defensible story. They pay again in the drag on everything else while that reconstruction is under way, because a system whose evidence cannot be produced on demand cannot safely change quickly. Every deployment carries the unpriced risk that it breaks a chain nobody can currently see. Evidence-first operations remove that risk by making the chain explicit and continuous, which is precisely what lets a regulated business move at close to the speed of an unregulated one without surrendering its right to operate.

This is the resolution of the tension the post opened with. Evidence and speed look opposed only while evidence is a thing you produce on request. Engineer it into the data and execution layers and the opposition dissolves, because the same architecture that makes the system fast to change is the one that makes it ready to prove. The pharma company at the start did not have a speed problem or an evidence problem. It had an architecture that treated the two as separate, and paid for both.

The organisations turning a regulator's request into a query rather than a quarter are the ones engineering evidence into the layer beneath the strategy, and building that capability as a running property of the platform is what Sakura's Praxis compliance solution exists to do.

References

COSO, 2026. Achieving Effective Internal Control Over Generative AI. Committee of Sponsoring Organizations of the Treadway Commission. Available at: https://www.coso.org/ [Accessed 7 July 2026].

European Commission, 2026. Timeline for the implementation of the EU AI Act. AI Act Service Desk, European Commission. Available at: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act [Accessed 7 July 2026].

ICH, 2025. ICH E6(R3) Guideline for Good Clinical Practice, Step 4. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. Available at: https://www.ich.org/page/efficacy-guidelines [Accessed 7 July 2026].

International Auditing and Assurance Standards Board (IAASB), 2025. Technology Position: Catalog of Issues and Possible Actions. International Federation of Accountants. Available at: https://ifacweb.blob.core.windows.net/publicfiles/2025-11/IAASB-Technology-Catalog-of-Issues-Proposed-Actions.pdf [Accessed 7 July 2026].

International Auditing and Assurance Standards Board (IAASB), 2026. Proposed International Standard on Auditing 500 (Revised), Audit Evidence. International Federation of Accountants. Available at: https://www.iaasb.org/consultations-projects/isa-500-series [Accessed 7 July 2026].

U.S. Food and Drug Administration, n.d. 21 CFR Part 11: Electronic Records; Electronic Signatures. Code of Federal Regulations, Title 21, Chapter I, Subchapter A, Part 11. Available at: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 [Accessed 7 July 2026].