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
| Predicate | Description | Example |
|---|---|---|
schema:rationale | Chain-of-thought or explanation | Rationale 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).
| Predicate | Description | Example |
|---|---|---|
schema:actionStatus | Status of the action | "schema:CompletedActionStatus", "schema:FailedActionStatus" |
schema:startTime | When the action started | ISO 8601 UTC timestamp |
schema:endTime | When the action ended | ISO 8601 UTC timestamp |
schema:object | Input parameters or context | JSON string (hashed via calculateFideId()) |
schema:result | Output result or response | JSON 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
- Create a Session Entity: Usually type
Event(did:fide:0x4...) representing the parent process. - 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