Network Working Group B. Zambo
Internet-Draft Zambo
Intended status: Informational 1 November 2026
Expires: 5 May 2027
The AER-1 Execution Receipt as an Audit Data Model for Agent
Interactions
draft-zambo-aer1-audit-data-model-00
Abstract
The proposed AUDIT working group is scoped to define interoperable
mechanisms for auditing the observable behavior of agents across
trust boundaries, and its draft charter names Audit Data Models and
Semantics as a Standards Track deliverable. This document presents
one candidate for that deliverable: the AER-1 execution receipt,
specified in draft-zambo-aer1-26, read as an audit data model. It
summarizes the receipt record by reference to the AER-1
specification, shows how the record covers the audit scope the draft
charter describes (tool interactions, invoked and declined actions,
subagent and tool calls across domains, and records verifiable by a
party that trusts neither the agent nor its operator), records the
conformance corpus and independent implementation status behind the
model, and states the limits of the model plainly. This document
defines no new format and changes no AER-1 field, digest
construction, or verification rule.
Implementation Status
This section records implementation status following RFC 7942. It
will be removed before publication as an RFC.
Zambo Expires 5 May 2027 [Page 1]
Internet-Draft AER-1 as an Audit Data Model November 2026
The data model presented here is the receipt vocabulary of draft-
zambo-aer1-26, with a published conformance corpus of 126 vectors and
129 checks (kit v1.5.7) at https://zambo.dev/aer1/corpus.json. A
reference implementation is deployed at https://zambo.dev/mcp and
issues a receipt for every tool call it receives, including calls it
rejects before execution. Independent implementations built from the
draft text alone include Node.js, Java, and Perl verifiers, each
conformant against the corpus, and an independent production
validator is operated by WhiteMagic Labs at
https://api.whitemagic.dev/aer1/verify. On 2026-10-31, the
independent implementer who reported the metadata binding gap
described in Section 7 re-ran his verifier against the kit commit
carrying the fix and confirmed full agreement: 119 of 119 on the base
vector set, with every metadata mutation probe failing on the
metadata mismatch alone. A companion document, draft-zambo-aer1-
wimse-mapping-01, maps the same vocabulary onto the audit
requirements of the WIMSE AIMS framework.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 May 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zambo Expires 5 May 2027 [Page 2]
Internet-Draft AER-1 as an Audit Data Model November 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The AER-1 Record, by Reference . . . . . . . . . . . . . . . 4
4. Fit to the AUDIT Problem Space . . . . . . . . . . . . . . . 6
5. Relationship to the WIMSE AIMS Audit Requirements . . . . . . 7
6. Relationship to Other Work . . . . . . . . . . . . . . . . . 8
7. Conformance and Implementation Status . . . . . . . . . . . . 9
8. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 10
9. What This Model Does Not Do . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 12
13.2. Informative References . . . . . . . . . . . . . . . . . 12
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The AUDIT BoF ("Agent Use of Delegation and Interaction
Traceability"), approved for IETF 127, proposes a working group for
interoperable auditing of agent behavior across domains. Its draft
charter [AUDIT-CHARTER] scopes the work to "the observable behavior
of agents, including user intent declarations, agent or tool
interactions, invoked or declined actions, exchanged data, and
resulting outcomes across trust boundaries, but not the auditing of
the underlying AI model, training data, or inference mechanisms."
The draft charter's second deliverable, Audit Data Models and
Semantics, calls for one or more Standards Track RFCs that "identify
and reuse existing or specify new IETF data models that can represent
audit information about agents and delegated systems".
This document answers that deliverable's "identify and reuse
existing" branch with a data model that already exists, is deployed,
and carries independent implementations: the AER-1 execution receipt
[AER1]. AER-1 specifies a JSON record of one agent tool call
(Section 3 of [AER1]), a SHA-256 output commitment over the canonical
bytes of the recorded result (Section 4 of [AER1]), and a
verification procedure any third party can run without an account
with the producer (Section 6 of [AER1]). Receipts compose into hash-
chained job timelines (Section 7 of [AER1]) and workflow receipts
that bind an ordered sequence of step receipts, which may originate
from different services, under one Merkle root (Section 8 of [AER1]).
Zambo Expires 5 May 2027 [Page 3]
Internet-Draft AER-1 as an Audit Data Model November 2026
This document is a presentation and scoping document, not a new
specification. Section 3 summarizes the AER-1 record by reference;
the normative definition of every member, construction, and procedure
is [AER1] itself, and nothing here revises it. Section 4 walks the
draft charter's scope items against the model. Section 5 records the
mapping to the WIMSE AIMS audit requirements, which is specified in
full in the companion document [WIMSE-MAPPING]. Section 6 positions
the model against the other work the AUDIT effort composes or has
before it. Section 7 records conformance and implementation status.
Section 9 states what the model does not do.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. Statements about [AER1] in this document
describe that specification; the conformance requirements themselves
are stated in [AER1].
Terms from [AER1] (receipt, execution, canonical bytes, observed
result, output commitment, provenance class, execution context) are
used with the meanings that document gives them. "Audit record" in
this document means a record of agent behavior kept for later
examination by a party other than the producer, in the sense of the
AUDIT draft charter.
3. The AER-1 Record, by Reference
An AER-1 receipt is a JSON object recording one execution: one
invocation of one tool by or on behalf of an agent, with its inputs,
observed result, and timing (Section 2 of [AER1]). The core members
(Section 3 and Table 1 of [AER1]) are:
Zambo Expires 5 May 2027 [Page 4]
Internet-Draft AER-1 as an Audit Data Model November 2026
+------------------------+-------------------------------------------+
| Member | Content |
+========================+===========================================+
| id | Stable UUID identifying the receipt; the |
| | correlation identifier for the record. |
+------------------------+-------------------------------------------+
| receipt_schema_version | Schema version of the record. |
+------------------------+-------------------------------------------+
| created_at | Timestamp of record creation (RFC 3339). |
+------------------------+-------------------------------------------+
| tool | Object naming the tool: name, version, |
| | and caller scope. |
+------------------------+-------------------------------------------+
| provenance_class | One of the provenance classes of Section |
| | 5 of [AER1], stating who ran or reported |
| | the action. |
+------------------------+-------------------------------------------+
| canonical_bytes | Base64 encoding of the exact UTF-8 bytes |
| | of the recorded result. |
+------------------------+-------------------------------------------+
| output_hash | "sha256:" plus the lowercase hex digest |
| | of the decoded canonical bytes (Section |
| | 4 of [AER1]). |
+------------------------+-------------------------------------------+
| metadata_hash | Conditional; digest of the canonical |
| | metadata block (Section 3.1 of [AER1]). |
| | Required when the schema version is |
| | "0.4" or later. |
+------------------------+-------------------------------------------+
| verification_status | Outcome of the verification procedure of |
| | Section 6 of [AER1]. |
+------------------------+-------------------------------------------+
Three properties of the record matter most for audit use, and each is
normative in [AER1]:
Issuance is independent of execution. A producer MUST issue a
receipt for every tool call it receives, including a call it rejects
before execution; the rejection receipt records the requested tool,
the arguments as received, and the error returned, and "a call that
leaves no receipt is a conformance failure: the absence of a record
MUST NOT be allowed to hide an attempted call" (Section 3 of [AER1]).
Declined actions are therefore first-class records, not gaps.
The record separates observation from claims. A receipt reports the
observed result the system recorded; per the abstract of [AER1], the
format "separates what the system observed from claims about the
outside world, and it separates provenance (who ran or reported the
Zambo Expires 5 May 2027 [Page 5]
Internet-Draft AER-1 as an Audit Data Model November 2026
action) from the record itself." The execution_context member
(Section 3.2 of [AER1]) records context such as the framework and
model that issued the call and the source system acted upon, and it
sits outside the hashed core: context members record what the
producer reported and MUST NOT change the meaning of the core
members.
Verification is third-party and outcome-explicit. The procedure of
Section 6 of [AER1] recomputes the output commitment and the metadata
binding and compares; a record altered after issuance fails the
comparison. Where a receipt is externally anchored (Section 10 of
[AER1]), the verifier reports each anchor's outcome in a fixed
vocabulary (verified, verification failed, rejected: unresolvable
record, not checked, or absent), and an unevaluated anchor MUST NOT
be reported with an evaluated outcome. Every receipt resolves at a
stable public URL without an account, wallet, or token (Section 9 of
[AER1]), so an auditor needs no relationship with the producer to
check a record.
Composition across calls and domains comes from two constructions.
Hash-chained job timelines (Section 7 of [AER1]) order the receipts
of one job so that removal or reordering within the timeline is
detectable. Workflow receipts (Section 8 of [AER1]) bind an ordered
sequence of step receipts to a single goal under a Merkle root over
the step sequence (Section 8.1 of [AER1]), with bidirectional links
between the workflow and each step (Section 8.3 of [AER1]); the steps
may originate from different services, which is the cross-domain
action chain the AUDIT scope describes. Section 8.4 and Section 7.3
of [AER1] state what these constructions do not prove, and those
limits carry into any audit use.
4. Fit to the AUDIT Problem Space
The draft charter [AUDIT-CHARTER] names the scope items below. Each
is answered against the model as specified in [AER1]; nothing in this
section adds requirements.
Agent and tool interactions. The receipt is the interaction record:
one tool call, its inputs as received, its observed result, its
timing, and the identity of the tool and the caller scope under which
it ran (Sections 2 and 3 of [AER1]).
Invoked and declined actions. Both are recorded under the same
issuance rule (Section 3 of [AER1]). A declined action produces a
rejection receipt whose canonical bytes are the request-and-error
record; the attempt is part of the checkable record rather than an
absence in it.
Zambo Expires 5 May 2027 [Page 6]
Internet-Draft AER-1 as an Audit Data Model November 2026
Subagents and tool calls in other domains. A task that fans out
across services produces step receipts at each service; a workflow
receipt (Section 8 of [AER1]) binds the ordered steps, wherever they
were produced, to one goal, and an auditor can enumerate the steps,
resolve each at its public URL, and verify each one and the whole
without the cooperation of any producing service.
A common identifier linking intent to actions. The receipt id is the
record's stable identifier; chain linkage (Section 7 of [AER1]) and
workflow membership (Section 8 of [AER1]) carry correlation across
calls and services, which is the linking role the draft charter
assigns to record identifiers.
Verifiable by a party that trusts neither the agent nor its operator.
The draft charter states this property is "what separates audit
records from most existing log mechanisms." AER-1's commitments are
over bytes any holder of the record can recompute (Sections 4 and 6
of [AER1]); verification needs no account with, or trust in, the
producer, and receipts can additionally be anchored to independently
operated media (Section 10 of [AER1]) so that existence and content
at a point in time are witnessed outside the producer's own systems.
Authorization state over time and action provenance. The record
carries the caller scope and provenance class of each call, the
authorization decision itself where the decision is a rejection
(recorded as above), and ordering across a job or workflow, so a
sequence of decisions and actions can be read in order. Delegation
context beyond the caller scope is carried in execution_context
(Section 3.2 of [AER1]) as producer-reported context; binding that
context to a deployment's subject identifiers is deployment policy,
as Section 5 notes for the AIMS mapping.
Out of scope, as the charter fences it. AER-1 records executions,
not models. It says nothing about training data or inference
mechanisms, and this document claims no coverage of them, matching
the draft charter's exclusion.
5. Relationship to the WIMSE AIMS Audit Requirements
Section 11 of the WIMSE AIMS framework [AIMS] requires deployments to
produce durable audit logs covering authorization decisions and
subsequent remediations, requires the records to be retained under
deployment policy, enumerates seven minimum fields for an audit
event, and calls for reconstruction of complete execution chains
across service boundaries. AIMS deliberately specifies no audit
record format. The companion document [WIMSE-MAPPING] maps each AIMS
Section 11 requirement onto the AER-1 constructs that satisfy it,
field by field, including the delegated-subject binding a deployment
Zambo Expires 5 May 2027 [Page 7]
Internet-Draft AER-1 as an Audit Data Model November 2026
must supply and the optional carriage of receipts as SCITT
statements. That mapping is incorporated here by reference rather
than restated, so the two documents cannot drift apart; the load-
bearing points are the rejection-receipt rule (a denied authorization
decision is recorded, not lost), the chain and workflow constructions
(execution chain reconstruction), and the statement of limits in
Section 9 of this document, which mirrors Section 6 of [WIMSE-
MAPPING].
6. Relationship to Other Work
The AUDIT draft charter composes existing building blocks rather than
replacing them, and this model is written to sit in that composition.
The architecture work before the BoF, [AUDIT-ARCH], describes roles
and data flows for auditing agent delegation and interactions; a data
model candidate answers the record-format question that an
architecture leaves open. Verifiable Agent Conversation Records
[VACR] record conversations and are being profiled for audit use in
the vCon context; conversation records and execution receipts cover
different parts of an interaction, and an audit trail may need both.
SCITT [SCITT] provides transparency services to which records can be
anchored; [AER1] already permits SCITT anchoring (Section 10 of
[AER1]) and [WIMSE-MAPPING] fixes the carriage. RATS provides
attestation evidence about system state; a receipt is a record of an
observed action, not an attestation, and the two are complementary
inputs to an auditor. WIMSE supplies the identity layer whose audit
requirements the companion mapping addresses (Section 5).
Two other individual drafts propose audit record formats in the same
problem space. [GILDA] defines an audit record format for AI agent
authorization decisions and carries the seven minimum audit fields of
the AIMS framework. [SHARIF] defines a logging format for autonomous
AI systems, with hash-chained JSON records. Both are named here
because the BoF's charter discussion should weigh the candidate data
models against each other on their records; the differences that
matter for that discussion are what each format records
(authorization decisions, general system logs, or per-execution
receipts with third-party verification), what verification procedure
each defines, and what implementation and conformance evidence each
carries. This document makes the case for AER-1 on exactly those
three axes and disparages no alternative.
Zambo Expires 5 May 2027 [Page 8]
Internet-Draft AER-1 as an Audit Data Model November 2026
7. Conformance and Implementation Status
Conformance to AER-1 is determined against a published corpus, not
against this document or any summary of it. An implementation is
conformant when it produces byte-identical verdicts to the reference
runners across the full vector corpus (Implementation Status of
[AER1]). The corpus is published at https://zambo.dev/aer1/
corpus.json and, at the time of writing, carries 126 vectors and 129
checks (kit v1.5.7), with evaluated-set digest
sha256:ccaff18a...00ce8 as recorded in the corpus record itself. The
frozen text of [AER1] states 124 vectors and 127 checks; the corpus
grew after that text froze, and [AER1] itself provides that the
published corpus record governs in that case. The counts in this
section are the live published record.
The implementation picture, as recorded in the Implementation Status
of [AER1] (kept in the style of [RFC7942]) and updated below, is:
Reference implementation. Zambo (https://zambo.dev), operated by the
author of [AER1], is a deployed implementation of Sections 3 through
10 of [AER1]. It issues a receipt for every tool call it receives,
including rejected calls, and its receipts resolve publicly as
Section 9 of [AER1] describes. At the time of writing the
deployment's public counters report over 88,000 public receipts.
Independent implementations from the text alone. ARION's Node.js and
Java verifiers and ColonistOne's Perl verifier were each built from
the draft text alone, without access to kit internals, and each is
conformant against the corpus. These are independent implementations
in the sense an adoption discussion cares about: separate authors,
separate codebases, agreement measured against a shared corpus.
Independent production validator. WhiteMagic Labs operates a
production validator for [AER1] at https://api.whitemagic.dev/aer1/
verify, publicly accessible without a key. On 2026-10-17 its
operator exercised it against the reference implementation and the
corpus; the two implementations initially disagreed on cases in both
directions, each disagreement was resolved against the draft text the
same day, and the implementations now agree across the exercised case
matrix.
Scoping of the kit. The conformance kit ships seven bundled runners
(Rust, Go, TypeScript, Python, Java, C#, and Swift). As [AER1]
states, these runners are the kit's own test runners, not independent
implementations, and no claim in this document counts them as such.
Zambo Expires 5 May 2027 [Page 9]
Internet-Draft AER-1 as an Audit Data Model November 2026
Post-freeze re-validation. After [AER1] froze at revision 26, an
independent implementer reported that the kit runners did not
implement the metadata recomputation that Section 6 of [AER1]
requires for schema 0.4 receipts carrying a metadata_hash, so mutated
metadata could pass the kit. The recomputation was implemented in
the kit runners in a commit crediting the finder. On 2026-10-31 the
finder re-pinned his environment to that commit and re-validated from
his side: his verifier, built from the text alone, still agrees with
the kit at 119 of 119 on the base vector set, and every one of his
metadata mutation probes now fails on the metadata mismatch alone, as
the kit documentation states. The episode is recorded here because
it is the conformance process working as intended: an outsider found
a divergence between text and code, the code was brought to the text,
and the finder verified the fix independently.
8. Discussion Venue
Discussion of this document takes place on the AUDIT mailing list,
audit@ietf.org, whose archive is at
https://mailarchive.ietf.org/arch/browse/audit/. The document is
offered as candidate input to the Audit Data Models and Semantics
deliverable in the AUDIT draft charter. Discussion of the underlying
vocabulary remains anchored in [AER1] and its companion mapping
[WIMSE-MAPPING].
9. What This Model Does Not Do
A receipt proves a narrow thing, and audit use inherits the
narrowness. Verification under [AER1] establishes that the saved
record was not changed after it was saved. It does not establish
that the recorded action was correct, that it was authorized, or that
the outcome it reports is true of the outside world. An auditor MUST
NOT treat the presence of a valid receipt as evidence that an action
was permitted; the receipt is the record of the decision and the
action, and policy evaluation remains the relying party's own
function.
The base format does not authenticate the issuer of a receipt; [AER1]
discloses this normatively in its own text. Provenance classes
(Section 5 of [AER1]) state who ran or reported an action, but a
class label is a claim, not a proof. Deployments whose threat model
requires issuer authentication use an authenticated anchoring path,
such as the SCITT carriage defined in [WIMSE-MAPPING], where the
transparency service authenticates issuers, or another anchor medium
permitted by Section 10 of [AER1]. Section 10.2 of [AER1] applies
throughout: binding a receipt to an external record does not transfer
the claims of one to the other. Clock trust and equivocation limits
for chained timelines are as stated in Section 13 of [AER1].
Zambo Expires 5 May 2027 [Page 10]
Internet-Draft AER-1 as an Audit Data Model November 2026
10. Security Considerations
The security considerations of [AER1] (its Section 13) apply in full
to records used as audit records, including the receipt-id binding
rule, the id-substitution case, and the limits on chained timelines.
Three considerations are specific to audit use. First, an audit
record is only as complete as the producer's issuance discipline: the
every-call rule of Section 3 of [AER1] is what makes an absence
meaningful, so an auditor evaluating a deployment should test
rejection behavior, not only successful calls. Second, context is
not evidence: execution_context members, including posture and risk
state, sit outside the hashed core and record what the producer
reported; a relying party that needs posture it can rely on must
obtain it from its own policy components. Third, records accumulate
sensitive operational detail over time; retention and access control
for stored receipts are deployment responsibilities, and the digest
commitments make alteration of a retained copy detectable in any
store, which addresses integrity of the archive, not its
confidentiality.
11. Privacy Considerations
The AUDIT draft charter treats privacy, confidentiality, selective
disclosure, and retention as core design considerations and expects
mechanisms to support auditability without requiring indiscriminate
disclosure of prompts, user content, or personal data. Against that
bar, the AER-1 core record is deliberately small: it records that a
call happened, what tool it named, under what scope, what the system
observed as its result, and when. It does not require prompts or
user content as core members. Two honest limits follow. The
canonical bytes carry the recorded result itself, so a deployment
whose tool results contain sensitive content must decide what its
tools record, and public resolution (Section 9 of [AER1]) is a
property of the reference deployment's public receipts, not a
requirement an audit deployment must copy: the format's commitments
verify identically over records held in a private store, and
anchoring (Section 10 of [AER1]) lets a deployment publish a digest
witnessed externally while the record itself stays access-controlled.
Selective disclosure profiles are exactly the kind of scoping the
draft charter's data-model deliverable contemplates, and they are
future work for a working group, not something this document defines.
12. IANA Considerations
This document has no IANA actions.
13. References
Zambo Expires 5 May 2027 [Page 11]
Internet-Draft AER-1 as an Audit Data Model November 2026
13.1. Normative References
[AER1] Zambo, B., "AER-1: A Portable Execution Receipt for AI Agent
Tool Calls", Internet-Draft draft-zambo-aer1-26, October 2026,
.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997, .
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, May 2017, .
13.2. Informative References
[AIMS] Kasselman, P., et al., "AI Identity Management System",
Internet-Draft draft-ietf-wimse-aims-00, September 2026,
.
[AUDIT-ARCH] Kuehlewind, M., et al., "An Architecture for Auditing
Agent Delegation and Interactions", Internet-Draft draft-kuehlewind-
audit-architecture-01, September 2026,
.
[AUDIT-CHARTER] Kuehlewind, M., Birkholz, H., and P. Dingle, "Agent
Use of Delegation and Interaction Traceability (AUDIT) Working Group
Charter", draft charter accompanying the approved AUDIT BoF request,
October 2026, .
[GILDA] Gilda, S., "An Audit Record Format for AI Agent Authorization
Decisions", Internet-Draft draft-gilda-audit-agent-audit-record-03,
October 2026, .
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, RFC 7942, July
2016, .
[SCITT] Birkholz, H., et al., "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Internet-Draft draft-ietf-scitt-
architecture-22, .
Zambo Expires 5 May 2027 [Page 12]
Internet-Draft AER-1 as an Audit Data Model November 2026
[SHARIF] Sharif, et al., "Agent Audit Trail: A Standard Logging
Format for Autonomous AI Systems", Internet-Draft draft-sharif-agent-
audit-trail-09, October 2026, .
[VACR] Birkholz, H., et al., "Verifiable Agent Conversation Records",
Internet-Draft draft-birkholz-verifiable-agent-conversations-01,
August 2026, .
[WIMSE-MAPPING] Zambo, B., "AER-1 Receipts as Audit Records for WIMSE
AIMS", Internet-Draft draft-zambo-aer1-wimse-mapping-01, October
2026, .
14. Acknowledgments
The independent implementers whose verifiers and validators are
recorded in Section 7 produced the interoperability evidence this
document rests on, including the metadata binding finding and its
independent re-validation. The AUDIT BoF proponents' draft charter,
in particular its decision to scope a data-model deliverable that
first looks for existing models to reuse, is what makes a
presentation document like this one possible.
Author's Address
Brennan Zambo
Zambo
Email: brennanzambo@zambo.dev
URI: https://zambo.dev/aer-1
Zambo Expires 5 May 2027 [Page 13]