Actions

Workflow traces and action steps using the Statement schema

Actions use the unified FCP Statement Schema. The Action is an Entity (Type Event / did:fide:0x4...); statements describe it.

Prop

Type

Predicate Mapping

Use the following predicates within the unified Schema:

Core FCP Predicates

PredicateDescriptionExample
schema:rationaleChain-of-thought or explanationRationale string (hashed via calculateFideId())

Common Schema.org Predicates

For linking actions to agents or sessions, use the standard Action Relationships (schema:agent, schema:isPartOf, prov:wasInformedBy).

PredicateDescriptionExample
schema:actionStatusStatus of the action"schema:CompletedActionStatus", "schema:FailedActionStatus"
schema:startTimeWhen the action startedISO 8601 UTC timestamp
schema:endTimeWhen the action endedISO 8601 UTC timestamp
schema:objectInput parameters or contextJSON string (hashed via calculateFideId())
schema:resultOutput result or responseJSON string (hashed via calculateFideId())

Workflow Sessions

A Session represents a single execution context (e.g., a user request, a specific task run, or a "thread"). Actions are grouped into sessions to keep related steps together.

Use the standard grouping predicate (schema:isPartOf) to link steps to their container.

Implementation Pattern

  1. Create a Session Entity: Usually type Event (did:fide:0x4...) representing the parent process.
  2. Link Actions: Each Action Step issues a statement pointing to it.
// 1. The Session Entity (The Container)
const sessionID = "did:fide:0xSessionID..."; // e.g., Derived from "Execution-Run-123"

// 2. The Action Step (The Part)
const actionID = "did:fide:0xActionID...";

// 3. Link them
{
  subjectFideId: actionID,                          // The Step
  predicateRawIdentifier: "schema:isPartOf",
  objectFideId: sessionID                           // The Session
}

This allows indexers to query the sessionID and retrieve all linked steps (incoming isPartOf edges) to reconstruct the full timeline.

DAG Structure

For parallel execution traces, use relationship statements to link actions:

Why DAG over linear indexing?

  • Parallelism: If Step A triggers both B and C simultaneously, both can reference A
  • Traceability: Reconstruct exact execution tree without race conditions
  • Git-like History: Each step cryptographically chained to its predecessor
graph TD
    Step1[Action A: Receive Request]
    Step2[Action B: Analyze Intent]
    Step3[Action C: Check Balance]
    Step4[Action D: Execute Trade]
    
    Step1 -->|Triggered| Step2
    Step1 -->|Parallel Trigger| Step3
    
    Step2 -->|Analysis Complete| Step4
    Step3 -->|Funds Verified| Step4
    
    style Step4 stroke:#0f0,stroke-width:2px

On this page