rfc: add workflow-composition evidence profile

[DmitrL-dev]

Summary

• Adds a format-neutral workflow-composition evidence profile for sequences of individually permitted actions.
• Separates proposed, validated, reserved, committed, withheld, executed and unknown lifecycle states.
• Requires atomic cumulative decisions, delegation monotonicity, revocation propagation, cross-boundary continuity and replay safety.
• Adds machine-runnable conformance vectors and integrates the profile into SAFE evidence preservation and review.

Addresses #26.

Validation

• DCO sign-off present
• git diff --check passes

[victor-davidenko]

This is a well-scoped profile. The decision to specify evidence requirements and conformance behavior rather than a transport format or policy language is correct: it lets implementations converge on what composition evidence must prove without locking them into a single schema.

Two structural observations on scope:

The profile covers composition within a single governance domain well. For cross-boundary composition, several behavioral requirements (particularly #7, cross-boundary continuity) assume a cooperation mechanism between governance instances that the profile does not specify. The comments below identify specific points where the cross-boundary model needs to be either specified or explicitly named as a dependency on a separate cooperation protocol specification. The choice matters because it determines whether the profile's behavioral requirements are achievable or aspirational for federated workflows.

The lifecycle terminates at executed. For single-domain workflows this is sufficient. For workflows involving delegated work across governance boundaries, the evidence chain between "the work happened" and "the workflow is done" is ungoverned. The comments below propose additional lifecycle states for acceptance, settlement, and completion. If the profile does not cover settlement, it should say so in the Limits section and reserve the lifecycle states so implementations are not locked to an incomplete lifecycle by the time a settlement specification exists.

Detailed comments on specific sections below.

[victor-davidenko]

This is the right requirement for single-domain workflows. For cross-boundary workflows, the profile needs to address which governance instance's workflow_id is authoritative. Three options:

(a) Propagation. The originating governance instance's workflow_id crosses into the receiving domain. The receiving instance treats it as a foreign correlation identifier with no governance authority in its own domain.

This fails on revocation. If the originating instance revokes the workflow, the receiving instance must interpret a foreign identifier's revocation semantics — lifecycle states, timing, and authority model that it did not define and cannot verify against its own governance policy. It also fails on liability attribution: when the receiving agent causes harm under a foreign workflow identity, the evidence chain for determining which governance instance authorized the harmful action depends on one instance trusting the other's interpretation of the identifier.

(b) Independent minting with bilateral binding. The receiving governance instance mints its own workflow_id and records a binding to the originator's identifier.

This solves the governance sovereignty problem (each instance governs under its own identity) but creates an evidence fragmentation problem. Trajectory reconstruction requires assembling two independent evidence chains and joining them through the binding record. If the binding record is lost, corrupted, or disputed, the cross-boundary trajectory is unrecoverable. Cumulative constraint enforcement across the boundary requires one instance to query the other's state in real time, which creates a runtime dependency that may not survive network partition or organizational disagreement. And there is no neutral ground for resolving disputes about what happened at the boundary — each instance holds its own evidence and interprets the binding according to its own rules.

(c) Shared protocol-produced identifier. A cooperation protocol between governance instances produces a workflow identifier that both instances recognize, with semantics defined by the protocol rather than by either instance unilaterally.

This is the architecturally complete answer because it solves the problems that (a) and (b) leave open:

Revocation propagates through a shared identifier whose lifecycle semantics both instances agreed to when they established the workflow. Neither instance needs to interpret the other's internal governance model to determine whether the workflow is still authorized.

Cumulative constraint enforcement operates against a shared ledger state rather than requiring real-time cross-queries between independent ledgers. When two governance instances both need to know how much of a shared budget has been consumed, a protocol-defined shared state is the only option that doesn't degrade under network partition or organizational disagreement.

Liability attribution traces to a shared record that neither instance controls unilaterally. When a cross-boundary workflow causes harm, the evidence record for the boundary crossing is jointly attested rather than asserted by one side.

Dispute resolution has a neutral reference point. When two governance instances disagree about what happened at the boundary, a protocol-produced shared record is verifiable by a third party without requiring trust in either instance's evidence.

The cooperation protocol itself is a separate specification effort. But the profile should specify option (c) as the target architecture for cross-boundary workflow identity and state that implementations using (a) or (b) must document the limitations in their evidence records: which cross-boundary properties (revocation propagation, cumulative constraint enforcement, liability attribution, dispute resolution) are not achievable under their chosen model.

This ensures the profile is not locked to a federation model that cannot support the full set of behavioral requirements it specifies.

[DmitrL-dev]

Addressed in 0881ce2. Each side now retains its locally authoritative identity and durable counterpart binding, declares the identity model in use, and reports which revocation, cumulative-state, attribution, and dispute-reconstruction properties remain unavailable or unverified.

I kept a protocol-produced shared identifier/ledger as a supported federation extension rather than the sole target architecture. It can provide jointly defined semantics, but it still has availability, partition, and governance assumptions that the evidence must not hide. The separate federation specification can define that stronger mechanism; this profile now makes the dependency and the limitations of every model explicit.

[victor-davidenko]

The lifecycle terminates at executed: "an execution boundary produced a receipt for an externally observed effect." This is incomplete for any workflow where execution is not the final obligation.

Consider a cross-boundary workflow: A's governance instance delegates work to B's governance instance. B's agent executes the work. B's governance instance records executed. At this point A's governance instance has evidence that execution occurred, but not that the work was accepted as fulfilling the delegation terms. A committed payment when the workflow was authorized. B committed capacity. The execution receipt proves the work was done. It does not prove that the work satisfied the agreement, that A accepted the deliverable, that payment was released, or that both parties' obligations are discharged.

Without completion and settlement states, the governance evidence chain has a gap between "the work happened" and "the workflow is done." That gap creates three concrete problems:

Orphaned obligations. A's committed payment remains in a governed-but-unresolved state. The evidence shows A authorized payment and B executed work, but no evidence records whether the payment was released, returned, or disputed. A cumulative budget that committed funds to this workflow cannot reclaim them because no lifecycle event marks the commitment as resolved.

Phantom authority. B's agent was authorized under a delegation for this workflow. Execution occurred. But without a completion state, the delegation's scope is never formally retired. B's agent retains residual authority under a workflow that is functionally finished but governancewise still open. The revocation requirement (Behavioral Requirement 6) handles premature termination but not normal completion.

Unauditable outcomes. A reviewer examining the workflow can reconstruct every governance decision from proposal through execution. They cannot determine whether the workflow achieved its purpose, whether both parties consider it complete, or whether any obligations remain outstanding. For incident review, this matters: a workflow that executed successfully but never settled may be the root cause of a subsequent dispute that triggers a security incident.

Three additional lifecycle states would close this:

accepted: the party that delegated the work acknowledged that execution satisfied the delegation terms. This is distinct from executed because execution can occur without acceptance (the work was done but rejected, requiring rework or dispute resolution).

settled: reciprocal obligations (payment, resource release, data deletion, access revocation) were fulfilled. This is distinct from accepted because acceptance triggers settlement but does not constitute it — A can accept B's work without A's payment system having released funds.

completed: the workflow and all its downstream delegations are fully discharged. No residual authority, no uncommitted obligations, no open references. This is the terminal state that allows cumulative budgets to reclaim committed capacity and delegation scopes to be formally retired.

The profile already handles premature termination well (withheld, revocation propagation). Adding normal completion and settlement closes the lifecycle and makes the evidence chain auditable from authorization through discharge. Leaving the lifecycle open at executed means every federated workflow's evidence chain ends with "the work happened" and a reviewer has to go outside the evidence to determine what happened next. That is the kind of gap this profile exists to close.

If settlement semantics are complex enough to warrant a separate specification (and they may be — payment protocols, acceptance criteria, and dispute resolution each carry significant design weight), the profile should at minimum reserve the lifecycle states and specify that implementations which support cross-boundary workflows must record completion and settlement events even if the semantics are implementation-defined until a settlement specification exists. This prevents the lifecycle from being locked at executed by the time implementations adopt the profile.

[DmitrL-dev]

Addressed in 0881ce2. The base lifecycle now states explicitly that executed establishes neither acceptance, settlement, nor completion. It reserves accepted, settled, and completed for versioned extension profiles and forbids base implementations from aliasing or inferring them. Negotiation, settlement, dispute handling, and terminal-completion semantics are also named in Limits as separate work.

I did not require implementation-defined settlement events in the base profile, because identical state names with incompatible semantics would create false interoperability. An extension must declare its semantics/version and preserve the link to the base workflow and downstream delegations.

[victor-davidenko]

This decomposition is correct and necessary. One gap: the profile does not address what happens when the delegation relationship is negotiated rather than unilaterally granted.

In a unilateral delegation (principal A delegates to agent B), A defines the scope and B operates within it. In a negotiated delegation (A's agent and B's agent agree on terms, scope, and commitments before work begins), both sides commit resources: A commits payment, B commits capacity. The delegation scope is the output of a bilateral agreement, and the governance evidence must capture what both parties committed and under what terms the workflow was authorized to proceed.

The lifecycle states handle the post-agreement execution well. They do not cover the pre-agreement negotiation: what was proposed by each side, what was accepted, what commitments were made, and the point at which the negotiated agreement became a governed workflow. That negotiation-to-delegation transition is where the evidence chain starts for federated commercial workflows. If the profile intends to cover those, the lifecycle needs an earlier state or a separate negotiation record type. If it intentionally excludes them, that should be stated in the Limits section.

[DmitrL-dev]

Addressed in 0881ce2. When delegated authority derives from negotiation, the minimum record now includes a stable agreement reference or digest plus the participant attestations required to establish that authority. The profile also says where its boundary begins: once an authority or grant exists. Proposal, counterproposal, acceptance, and commitment semantics for producing that agreement are explicitly outside this base profile.

[victor-davidenko]

The non-disclosure constraint is important and correct. One clarification needed: "sufficient to join the trajectory" is ambiguous about who performs the join. Three cases:

(a) Each governance instance independently holds its fragment and a third-party reviewer joins them using the handoff references.
(b) One governance instance holds the full trajectory and the other trusts it.
(c) Neither holds the full trajectory, and reconstruction requires cooperation from both.

Case (a) requires the handoff reference to be meaningful to a party that controls neither governance instance. Case (b) is operationally simpler but creates an asymmetric trust dependency. Case (c) is the realistic scenario for cross-organizational workflows but makes incident review dependent on bilateral cooperation.

The profile does not need to mandate one model, but it should specify that the evidence record states which model was used, so a reviewer knows what trajectory reconstruction is possible and what cooperation is required.

[DmitrL-dev]

Addressed in 0881ce2. Cross-boundary continuity now requires the record to declare whether reconstruction uses independently joinable fragments, a full trajectory held by one instance, cooperative bilateral assembly, or another model, together with the evidence, access, and cooperation that model requires. The new handoff vector checks both the two-fragment reconstruction and what a reviewer can establish from either fragment alone.

[victor-davidenko]

These cover the single-domain and simple-delegation cases well. Two cross-boundary vectors would strengthen the set:

7. Cross-boundary workflow handoff. Governance instance A delegates a workflow to governance instance B. B's governance instance mints its own workflow identity and records the handoff binding. A reviewer with access to both evidence records can reconstruct the cross-boundary trajectory. A reviewer with access to only one record can determine that a cross-boundary handoff occurred and identify the counterpart's workflow reference.

8. Cross-boundary revocation propagation. Governance instance A revokes authority for a workflow that was delegated to governance instance B. B's governance instance observes the revocation before B's agent commits. B's evidence records the revocation source, the timestamp of observation, and the disposition of any reserved authority. If B's governance instance cannot observe the revocation (network partition, no federation protocol), B's evidence records the inability to verify continued authorization.

These may be premature if the cross-boundary federation protocol is not yet specified. But including them as "aspirational" vectors, clearly marked as dependent on a federation specification, would signal that the profile is designed to extend to federated workflows rather than being limited to single-domain composition.

[DmitrL-dev]

Added both vectors in 0881ce2 and marked them federation-dependent. The handoff vector checks locally authoritative identities, the durable binding, and one-sided versus bilateral reconstruction. The revocation vector has reachable and unavailable variants; the unavailable case must report continued authorization and propagation as unverified rather than claiming success.

[victor-davidenko]

This is the right scope boundary. One suggestion: add an explicit statement that the cross-organizational reconciliation protocol is a separate specification effort that this profile enables but does not contain. Naming it as a known dependency rather than simply excluding it helps future contributors understand where the next piece of work begins.

[DmitrL-dev]

Addressed in 0881ce2. Limits now explicitly names cross-organizational cooperation and reconciliation — identity binding, cumulative-state reconciliation, revocation distribution, joint attestations, and dispute resolution — as a separate specification effort that this evidence profile enables but does not contain.

[DmitrL-dev]

Thank you for the detailed review. I pushed 0881ce2 to address all six points:

• the record now declares the cross-boundary identity and trajectory-reconstruction models, the locally authoritative identity in each trust domain, and any properties that remain unavailable or unverified;
• negotiated authority is bound to stable agreement evidence, while negotiation semantics remain outside the base profile;
• accepted, settled, and completed are reserved extension states, and executed is explicitly not evidence of any of them;
• federation-dependent handoff and revocation vectors now cover both reachable and unavailable cooperation mechanisms; and
• the Limits section explicitly names cooperation/reconciliation and negotiation/settlement as separate specification efforts.

One deliberate boundary remains: a protocol-produced shared identifier, joint attestation, or ledger is supported as a federation extension, but is not the only normative architecture. A shared service still has availability and partition assumptions, so the evidence profile requires implementations to declare what their chosen model can actually establish rather than treating the presence of shared state as proof.

[victor-davidenko]

Clean implementation. The declared-model approach for cross-boundary identity and trajectory reconstruction is the right call and requiring implementations to state which properties their model can and cannot establish is more useful than mandating a single architecture at this stage. The federation-dependent conformance vectors with reachable and unavailable variants handle the realistic case where cooperation is not guaranteed.

The reserved extension states for accepted, settled, and completed are handled correctly: reserving the names without defining semantics prevents false interoperability while keeping the lifecycle extensible. The separate specification efforts named in Limits (cooperation/reconciliation, negotiation/settlement) are the natural next documents.

[DmitrL-dev]

Thank you — glad the declared-model boundary and federation-dependent vectors address the concern. I will keep this PR scoped to the evidence profile and treat cooperation/reconciliation and negotiation/settlement as separate follow-up specifications.