[SCHEMA] Add telemetry to evidence_basis_engines

[narko4u]

---

name: Schema change proposal
about: Propose a change to ave-record-1.1.0.schema.json
title: "[SCHEMA] Add telemetry to evidence_basis_engines"
labels: schema
assignees: ''

Change type

• Additive, new enum member on an existing field. No existing record changes, no new required field. Follows the precedent set by the v1.1.0 external_authority member.

Proposed change

Add one member to the evidence_basis_engines enum in ave-record-1.1.0.schema.json:

telemetry: observation recorded by the hosting platform or control plane, such as execution logs, audit records, or flow data, captured outside the artifact's write path.

Rationale

detection_layer already distinguishes runtime and transport observation, but no evidence_basis_engines member names that evidence source. A record whose finding rests on platform-recorded observation currently has no honest vocabulary: pattern and yara read content the artifact produced, sandbox is a containment statement, and external_authority names a queried outside party. The closest fit is sandbox, which mis-states what happened: telemetry is observation, not containment.

This is a live gap, not a hypothetical. Control-plane telemetry as an evidence source is an active discussion in the AAIF observability and traceability working group, and agent security tooling already emits this class of evidence. AVE vocabulary should be able to name it.

Semantically, platform telemetry is written outside the artifact's control, so like sandbox and external_authority it can reach a substrate vantage. The derivation in scripts/write_verification_basis.py would treat it as a substrate-reaching member.

Migration path for existing records

None required. Adding a member widens the enum; existing records remain valid unchanged, and the new member is opt-in for future records.

Impact on consumers

• validate_records.py: unaffected. The wider enum accepts more and rejects nothing currently valid.
• Confidence check: the enum-gap note mechanism extends naturally, so producers whose evidence is platform observation stop hitting the gap note once they declare the member.
• Crosswalk files: one mapping row for the new member.
• Tests: one unit test asserting the member reaches a substrate vantage, mirroring the external_authority test.

[chaksaray]

The gap here is real, and the precedent framing is right, telemetry genuinely isn't a containment claim the way sandbox is, and forcing it into the nearest existing value repeats the exact shape of problem external_authority was added to solve.

One thing worth pinning down before the substrate classification is settled, though. external_authority reaches substrate specifically because the artifact cannot forge or suppress an outside party's answer, that's the actual test write_verification_basis.py applies, not just "recorded outside the artifact's write path." Execution logs and audit records clearly clear that bar, the platform's record of what ran is not something the artifact can rewrite.

Flow data is less clean. Network flow observation can be partially shaped by the artifact itself, timing, destination, volume are all things an artifact retains some influence over even when the recording happens externally. That's a real difference from RDAP or a registry lookup, where the artifact has zero ability to affect the answer.

Worth deciding explicitly: is telemetry scoped to only the observation types the artifact structurally cannot influence, in which case substrate holds cleanly and this is as tight as external_authority was, or does it also cover partially-artifact-influenced sources like flow data, in which case either the definition needs narrowing or this member ends up coarser than its own precedent. Not a reason to hold the proposal, just worth resolving before the derivation logic treats every telemetry-tagged record identically.

[narko4u]

The gap framing is right, and I agree on the scoping: telemetry should be limited to observation types where the artifact structurally cannot influence the record, which is what makes substrate classification hold.

One sharpening on the test, because the wording matters for the precedent. "The artifact retains some influence" is true of sandbox too, the artifact chooses what commands to run inside it, so influence alone is not the discriminator. The precise test is: no influence over the observation's content or its capture scope. Execution logs and audit records pass both, the platform records what ran on a path the artifact cannot route around. Flow data fails on scope, a sensor on the network path is something the artifact can evade or route around, and it shapes what the sensor sees. Timing, destination, and volume are all things the artifact can move before the recording happens.

Proposed definition: telemetry covers observation types where the artifact has no influence over content or capture scope, matching external_authority. Flow data stays out of this member; if it earns a home later, it gets its own value with an explicit partial-scope caveat rather than riding on a clean substrate claim.

[chaksaray]

That correction is right and worth conceding directly: "the artifact retains some influence" doesn't discriminate, because sandbox fails that test too. The artifact chooses what runs inside a sandbox and thereby shapes what it observes, yet sandbox is unambiguously substrate-reaching. My framing would have ruled out an existing member if applied consistently, which means it was the wrong test.

Content or capture scope is the right discriminator. Sandbox passes both: the artifact influences what happens, but can't alter what the sandbox records about it or move outside its observation boundary. Flow data fails specifically on scope, and that's the precise reason, an artifact routing around a sensor is a different failure from influencing what a sensor at a fixed point sees.

Agreed on the proposed definition and on keeping flow data out. Giving it its own member later with an explicit partial-scope caveat, rather than letting it ride on a clean substrate claim, is the right call, that's the same instinct that made external_authority worth adding separately instead of stretching sandbox to cover it.

This looks settled to me. Worth writing the content-or-capture-scope test into the member's schema description itself, not just leaving it in this thread, since it's now the actual precedent for evaluating the next member somebody proposes.

[narko4u]

Settled, and the test belongs in the schema description so the precedent survives the thread. We will fold the content-or-capture-scope wording in with the member definition, and future member proposals will be evaluated against it.

[chaksaray]

Agreed. Worth one sharpening on the wording itself, since it's about to become the precedent test: state it as a requirement on the member ("a member reaches substrate only where the artifact has no influence over the observation's content or its capture scope") rather than as a description of telemetry specifically. That way the next proposal gets evaluated against a rule, not against an analogy to this one.