Re:DAG-TOML as a potential evidence layer for ADACG

Werner,



Thanks for the proposal. The structural distinction you draw between a declaration layer (pre-flight) and an evidence layer (post-facto tracking) is a logical separation of concerns. To evaluate how DAG-TOML can integrate with the Agent Declaration and Assurance Community Group, we need to address a few operational friction points.



Please consider the following architectural questions as we review the specification:



* **Serialization and Interoperability:** ADACG’s baseline work is leaning toward JSON-LD to maintain compatibility with the broader W3C decentralized identity (DID/VC) ecosystem. TOML is highly efficient for developers managing file systems and Git workflows, but less suited for semantic graph verification or credential exchange. How do you propose handling the translation layer between the TOML evidence files and a graph-oriented ledger without introducing unnecessary serialization overhead or breaking data integrity? Maybe it won't be an issue, or TOML has vital features suited for this purpose.

* **Generalizability Beyond Software Production:** The draft spec is optimized for software engineering agents (focusing on diffs, source hashes, and review gates). How do your closure-root rules scale when applied to agents performing non-deterministic, runtime operations -- such as executing financial transactions, modifying live database states, or orchestrating web API chains where a clean source-to-artifact pipeline does not exist? Eg. a REST.GET quote price from an external endpoint may drift over time. Or maybe we content with using a snapshot.

* **Operational Tamper-Resistance:** An evidence layer is only useful if it is verifiable. If an agent is running outside of a secure enclave, what prevents a compromised or malicious agent from falsifying its own post-action DAG-TOML log? TEE may solve it, but maybe a naive good-will assumption will aid in adoption.



Your suggestion to provide a short mapping document is the correct next step to test this integration. When you draft it, please focus specifically on how a KYA conformance profile would programmatically ingest, parse, and verify a DAG-TOML artifact to enforce policy at runtime.


It would be great if we could integrate them, however the magnitude of coupling, and advance a comprehensive standard! 

Thanks again Werner, I think this really cuts to the chase of operational (as in input, process, output) assurance.

---

The best,

LKL, Agent Declaration and  Community Group

Engineering Excellence.

Creative Renaissance.

Hyper Optimization.









From: Werner Kasselman <werner@kasselman.com.au>
To: "public-adacg@w3.org"<public-adacg@w3.org>
Date: Thu, 04 Jun 2026 14:35:36 +0200
Subject: DAG-TOML as a potential evidence layer for ADACG




Hello ADACG members,

 

I’d like to propose DAG-TOML (from agent-assurance.dev) as a practical evidence and traceability specification that can complement the excellent work planned for the Open KYA Manifest and Agent Assurance mechanisms.

 

What is DAG-TOML?

It is a lightweight, human- and machine-readable TOML-based format focused on post-action evidence. It records:

Agent intent and claimed actions

Dependency graphs and closure roots (traceability)

Human review gates for high-impact or self-modifying work

Selective disclosure / redaction controls


 

How it relates to ADACG deliverables:

 

It can serve as one concrete mechanism for Agent Assurance, providing verifiable proof of what an agent actually did versus what it declared in a KYA Manifest.

Strong fit for Graduated Conformance Profiles and Runtime Integrity use cases.

Especially useful for governance frameworks like OpenAI’s Frontier Governance Framework, EU AI Act, and NIST-style risk management.

 

Affiliation Disclosure:

I am currently employed by ServiceNow in [Snr Staff Systems Architect, Gold Coast, Australia]. However, the DAG-TOML specification and https://agent-assurance.dev  work was created completely independently of my employment. I am contributing to this Community Group in my personal capacity only and do not represent my employer’s views or positions.

 

verivus-oss/agent-assurance is licensed under the Apache License 2.0 | A permissive license whose main conditions require preservation of copyright and license notices. Contributors provide an express grant of patent rights. Licensed works, modifications, and larger works may be distributed under different terms and without
 source code.

 

I’m would love to share the spec, examples, and discuss how it could integrate with the JSON-LD KYA manifest approach.

Contribute a short mapping document

 

Looking forward to your thoughts.

 

Best regards,

Werner Kasselman

(Independent contributor – https://agent-assurance.dev  | https://github.com/verivus-oss/agent-assurance )

X: @wernerk_au