Skip to content

Where should execution evidence fit in the evolving FDO architecture and conformance model? #2

@joy7758

Description

@joy7758

I am raising this as a narrow discussion proposal, not as a full agent object proposal.

In local work, the most stable and reviewable slice is a small execution evidence layer with:

  • bounded evidence artifacts
  • provenance and integrity references
  • validation-oriented fixtures
  • conformance-style checks

Because the current architecture work is still evolving, this seems like the right stage to ask a narrower placement question before discussing any broader agent-related model.

Why this seems like an architectural/conformance gap

Execution evidence for AI runtime actions appears to sit between several concerns:

  • object identity and metadata
  • provenance and integrity
  • policy decision artifacts
  • conformance evaluation

That evidence layer is concrete enough to validate, but its architectural placement is still unclear.

The question is not how to define a full agent object.
The narrower question is:

How should execution evidence be named and scoped so it can fit cleanly into the evolving FDO architecture and conformance model?

Narrow proposal scope

I am exploring whether this should be discussed first as a narrow execution evidence profile, with a minimal boundary such as:

  • subject reference
  • integrity binding
  • provenance reference
  • optional policy decision reference
  • optional execution trace reference
  • conformance statement

This is intentionally smaller than a full agent model. It avoids pulling in persona, memory, permissions, workflow, or full runtime semantics.

Existing local registration signals

Public registry handles observed under 21.T11966 include:

  • AROAUDIT_PROFILE_V1
  • aro-audit-demo-do-1
  • ARO_AUDIT_DEMO_OBJ_V1
  • ARO_AUDIT_MANIFEST_V1

I also have local discussion and validation materials for a narrow execution evidence profile. I am not proposing those materials as a finished standard. I am using them only to show that this is already a concrete, testable problem.

Questions for maintainers / WG

  1. Does execution evidence look like something that should first be discussed as a profile question rather than as a new top-level object family?
  2. In the current architecture work, would execution evidence fit better as a profile attached to digital objects, or as a separately referenceable evidence object?
  3. Are conformance targets, conformance classes, and conditions for conformance the right first framing for this topic?
  4. What is the minimum acceptable boundary for such a narrow execution evidence profile?
  5. Would a short working note be the preferred next artifact before any architecture-spec PR text is attempted?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions