Priority
P1 architecture/trust issue: the common result envelope identifies the capability and outcome, but it does not return a canonical binding to the exact request that produced it. Agents and hosts therefore rely on transient call ordering or domain-specific fields to associate a result with its input.
Area
CapabilityRequest, CapabilityResult, invocation identity, canonical input digests, parallel calls, retries, artifacts, verification binding, telemetry.
Summary
CapabilityResult currently includes:
capability_id
capability_version
execution
output
scope
completeness
relationships
obligations
diagnostics
assurance
artifact_uris
provider
provider_digest
There is no canonical request digest or invocation identity. When an agent makes parallel math.run calls to the same or different capabilities, or retries a call after a timeout, it must rely on call ordering or domain-specific echo fields to associate each result with its input. That is fragile and becomes worse under batch dispatch (#896) and idempotent retry (#1131).
Static audit baseline: current main at 7d277e169c809455d1a171b3a96aaa0d915471b7. Updated 2026-08-10: removed mode from the field list after #1143/#1158.
Current defects
Parallel calls cannot be reliably associated
An agent issuing two math.run calls to matrix.determinant.compute with different inputs receives two results with the same capability_id. Without a canonical request digest, the agent cannot programmatically determine which result corresponds to which input without copying domain-specific echo fields.
Retries can attach to the wrong invocation
A timed-out call may be retried. If the original call eventually completes, the agent may receive two results for what it considers one invocation. Without a canonical invocation identity, the agent cannot detect the duplicate or bind the correct result.
Verification binding needs request identity
Checker tools that replay a producer result need to bind to the exact request that produced it. Without a canonical request digest in the result, the checker must reconstruct the binding from domain-specific fields or artifact lineage alone.
Proposed architecture
1. Add a canonical request digest and invocation identity to CapabilityResult
class CapabilityResult:
...
request_digest: Sha256Digest # canonical digest of the validated request
invocation_id: str # stable identifier for this specific callThe request digest is computed from the canonical JSON encoding of the validated request input. The invocation ID is a stable, bounded identifier (e.g., UUID or content-addressed hash) that uniquely identifies this specific invocation within the tenant/session.
2. Bind the identity before execution
The identity is constructed from the validated request, before execution. This ensures:
- a failed execution still returns a result with the correct identity;
- parallel calls have distinct identities;
- retries can detect duplicates by comparing identities.
3. Use the identity for verification binding
Checker tools that replay a producer result can bind to the request digest, ensuring the checker is replaying the exact input that produced the original result.
4. Include the identity in telemetry
Telemetry records the invocation identity alongside capability ID, enabling reliable correlation of execution metrics, errors, and verification records.
Acceptance criteria
Non-goals
- Exposing full request input in the result (use a digest).
- Encoding mathematical workflow strategy.
- Replacing artifact lineage with request digests (both are needed).
Related
Priority
P1 architecture/trust issue: the common result envelope identifies the capability and outcome, but it does not return a canonical binding to the exact request that produced it. Agents and hosts therefore rely on transient call ordering or domain-specific fields to associate a result with its input.
Area
CapabilityRequest,CapabilityResult, invocation identity, canonical input digests, parallel calls, retries, artifacts, verification binding, telemetry.Summary
CapabilityResultcurrently includes:There is no canonical request digest or invocation identity. When an agent makes parallel
math.runcalls to the same or different capabilities, or retries a call after a timeout, it must rely on call ordering or domain-specific echo fields to associate each result with its input. That is fragile and becomes worse under batch dispatch (#896) and idempotent retry (#1131).Static audit baseline: current
mainat7d277e169c809455d1a171b3a96aaa0d915471b7. Updated 2026-08-10: removedmodefrom the field list after #1143/#1158.Current defects
Parallel calls cannot be reliably associated
An agent issuing two
math.runcalls tomatrix.determinant.computewith different inputs receives two results with the samecapability_id. Without a canonical request digest, the agent cannot programmatically determine which result corresponds to which input without copying domain-specific echo fields.Retries can attach to the wrong invocation
A timed-out call may be retried. If the original call eventually completes, the agent may receive two results for what it considers one invocation. Without a canonical invocation identity, the agent cannot detect the duplicate or bind the correct result.
Verification binding needs request identity
Checker tools that replay a producer result need to bind to the exact request that produced it. Without a canonical request digest in the result, the checker must reconstruct the binding from domain-specific fields or artifact lineage alone.
Proposed architecture
1. Add a canonical request digest and invocation identity to CapabilityResult
The request digest is computed from the canonical JSON encoding of the validated request input. The invocation ID is a stable, bounded identifier (e.g., UUID or content-addressed hash) that uniquely identifies this specific invocation within the tenant/session.
2. Bind the identity before execution
The identity is constructed from the validated request, before execution. This ensures:
3. Use the identity for verification binding
Checker tools that replay a producer result can bind to the request digest, ensuring the checker is replaying the exact input that produced the original result.
4. Include the identity in telemetry
Telemetry records the invocation identity alongside capability ID, enabling reliable correlation of execution metrics, errors, and verification records.
Acceptance criteria
CapabilityResultincludes a canonical request digest and invocation identity.Non-goals
Related