Move use cases section to appendix
Use cases (medtech SDLC, financial trading, logistics) are motivating examples, not protocol definition. Moving them to the appendix keeps the normative body focused on format, transport, validation, and security. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -885,171 +885,6 @@ When an audit ledger is deployed, the implementation MUST provide:
|
||||
The ledger SHOULD be maintained by an entity independent of the
|
||||
workflow agents to reduce the risk of collusion.
|
||||
|
||||
# Use Cases {#use-cases}
|
||||
|
||||
This section describes representative use cases demonstrating how
|
||||
ECTs provide execution records in regulated environments. These
|
||||
examples demonstrate ECT mechanics; production deployments would
|
||||
include additional domain-specific requirements beyond the scope
|
||||
of this specification.
|
||||
|
||||
Note: task identifiers in this section are abbreviated for
|
||||
readability. In production, all "jti" values are required to be
|
||||
UUIDs per {{exec-claims}}.
|
||||
|
||||
## Medical Device SDLC Workflow
|
||||
|
||||
In a medical device software development lifecycle (SDLC),
|
||||
AI agents assist across multiple phases from requirements
|
||||
analysis through release approval. Regulatory frameworks
|
||||
including {{FDA-21CFR11}} Section 11.10(e) and {{EU-MDR}} require
|
||||
audit trails documenting the complete development process for
|
||||
software used in medical devices.
|
||||
|
||||
~~~
|
||||
Agent A (Spec Reviewer):
|
||||
jti: task-001 par: []
|
||||
exec_act: review_requirements_spec
|
||||
|
||||
Agent B (Code Generator):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: implement_module
|
||||
|
||||
Agent C (Test Agent):
|
||||
jti: task-003 par: [task-002]
|
||||
exec_act: execute_test_suite
|
||||
|
||||
Agent D (Build Agent):
|
||||
jti: task-004 par: [task-003]
|
||||
exec_act: build_release_artifact
|
||||
|
||||
Human Release Manager:
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: approve_release
|
||||
ext: {witnessed_by: [...]} (extension metadata)
|
||||
~~~
|
||||
{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
|
||||
|
||||
ECTs record that requirements were reviewed before implementation
|
||||
began, that tests were executed against the implemented code, that
|
||||
the build artifact was validated, and that a human release manager
|
||||
explicitly approved the release. The DAG structure ensures no
|
||||
phase was skipped or reordered.
|
||||
|
||||
### FDA Audit with DAG Reconstruction
|
||||
|
||||
During a regulatory audit, an FDA reviewer requests evidence of
|
||||
the development process for a specific software release. The
|
||||
auditing authority retrieves all ECTs sharing the same workflow
|
||||
identifier ("wid") from the audit ledger and reconstructs the
|
||||
complete DAG:
|
||||
|
||||
~~~
|
||||
task-001 (review_requirements_spec)
|
||||
|
|
||||
v
|
||||
task-002 (implement_module)
|
||||
|
|
||||
v
|
||||
task-003 (execute_test_suite)
|
||||
|
|
||||
v
|
||||
task-004 (build_release_artifact)
|
||||
|
|
||||
v
|
||||
task-005 (approve_release) [human, witnessed]
|
||||
~~~
|
||||
{: #fig-fda-audit title="Reconstructed DAG for FDA Audit"}
|
||||
|
||||
The reconstructed DAG provides cryptographic evidence that:
|
||||
|
||||
- Each phase was executed by an identified and authenticated agent.
|
||||
- The execution sequence was maintained (no step was bypassed).
|
||||
- A human-in-the-loop approved the final release, with independent
|
||||
witness attestation.
|
||||
- Timestamps and execution durations are recorded for each step.
|
||||
|
||||
This can contribute to compliance with:
|
||||
|
||||
- {{FDA-21CFR11}} Section 11.10(e): Computer-generated audit trails
|
||||
that record the date, time, and identity of the operator.
|
||||
- {{EU-MDR}} Annex II: Technical documentation traceability for the
|
||||
software development lifecycle.
|
||||
- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for
|
||||
high-risk AI systems involved in the development process.
|
||||
- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
|
||||
oversight events occurred during the release process.
|
||||
|
||||
## Financial Trading Workflow
|
||||
|
||||
In a financial trading workflow, agents perform risk assessment,
|
||||
compliance verification, and trade execution. The DAG structure
|
||||
records that compliance checks were evaluated before trade
|
||||
execution.
|
||||
|
||||
~~~
|
||||
Agent A (Risk Assessment):
|
||||
jti: task-001 par: []
|
||||
exec_act: calculate_risk_exposure
|
||||
|
||||
Agent B (Compliance):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: verify_compliance
|
||||
|
||||
Agent C (Execution):
|
||||
jti: task-003 par: [task-002]
|
||||
exec_act: execute_trade
|
||||
~~~
|
||||
{: #fig-finance title="Financial Trading Workflow"}
|
||||
|
||||
This can contribute to compliance with:
|
||||
|
||||
- {{MIFID-II}}: ECTs provide cryptographic records of the execution
|
||||
sequence that can support transaction audit requirements.
|
||||
- {{DORA}} Article 12: ECTs contribute to ICT activity logging.
|
||||
- {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven
|
||||
systems.
|
||||
|
||||
## Compensation and Rollback
|
||||
|
||||
Compensation and rollback use cases are described in
|
||||
{{I-D.nennemann-wimse-ect-pol}}. The core
|
||||
ECT mechanism supports compensation through the "par" claim,
|
||||
which links a remediation ECT to the original task.
|
||||
|
||||
## Autonomous Logistics Coordination
|
||||
|
||||
In a logistics workflow, multiple compliance checks complete
|
||||
before shipment commitment. The DAG structure records that all
|
||||
required checks were completed:
|
||||
|
||||
~~~
|
||||
Agent A (Route Planning):
|
||||
jti: task-001 par: []
|
||||
exec_act: plan_route
|
||||
|
||||
Agent B (Customs):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: validate_customs
|
||||
|
||||
Agent C (Safety):
|
||||
jti: task-003 par: [task-001]
|
||||
exec_act: verify_cargo_safety
|
||||
|
||||
Agent D (Payment):
|
||||
jti: task-004 par: [task-002, task-003]
|
||||
exec_act: authorize_payment
|
||||
|
||||
System (Commitment):
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: commit_shipment
|
||||
~~~
|
||||
{: #fig-logistics title="Logistics Workflow with Parallel Tasks"}
|
||||
|
||||
Note that tasks 002 and 003 both depend only on task-001 and can
|
||||
execute in parallel. Task 004 depends on both, demonstrating the
|
||||
DAG's ability to represent parallel execution with a join point.
|
||||
|
||||
# Security Considerations
|
||||
|
||||
This section addresses security considerations following the
|
||||
@@ -1376,6 +1211,177 @@ registry are defined in
|
||||
|
||||
--- back
|
||||
|
||||
# Use Cases {#use-cases}
|
||||
{:numbered="false"}
|
||||
|
||||
This section describes representative use cases demonstrating how
|
||||
ECTs provide execution records in regulated environments. These
|
||||
examples demonstrate ECT mechanics; production deployments would
|
||||
include additional domain-specific requirements beyond the scope
|
||||
of this specification.
|
||||
|
||||
Note: task identifiers in this section are abbreviated for
|
||||
readability. In production, all "jti" values are required to be
|
||||
UUIDs per {{exec-claims}}.
|
||||
|
||||
## Medical Device SDLC Workflow
|
||||
{:numbered="false"}
|
||||
|
||||
In a medical device software development lifecycle (SDLC),
|
||||
AI agents assist across multiple phases from requirements
|
||||
analysis through release approval. Regulatory frameworks
|
||||
including {{FDA-21CFR11}} Section 11.10(e) and {{EU-MDR}} require
|
||||
audit trails documenting the complete development process for
|
||||
software used in medical devices.
|
||||
|
||||
~~~
|
||||
Agent A (Spec Reviewer):
|
||||
jti: task-001 par: []
|
||||
exec_act: review_requirements_spec
|
||||
|
||||
Agent B (Code Generator):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: implement_module
|
||||
|
||||
Agent C (Test Agent):
|
||||
jti: task-003 par: [task-002]
|
||||
exec_act: execute_test_suite
|
||||
|
||||
Agent D (Build Agent):
|
||||
jti: task-004 par: [task-003]
|
||||
exec_act: build_release_artifact
|
||||
|
||||
Human Release Manager:
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: approve_release
|
||||
ext: {witnessed_by: [...]} (extension metadata)
|
||||
~~~
|
||||
{: #fig-medtech-sdlc title="Medical Device SDLC Workflow"}
|
||||
|
||||
ECTs record that requirements were reviewed before implementation
|
||||
began, that tests were executed against the implemented code, that
|
||||
the build artifact was validated, and that a human release manager
|
||||
explicitly approved the release. The DAG structure ensures no
|
||||
phase was skipped or reordered.
|
||||
|
||||
### FDA Audit with DAG Reconstruction
|
||||
{:numbered="false"}
|
||||
|
||||
During a regulatory audit, an FDA reviewer requests evidence of
|
||||
the development process for a specific software release. The
|
||||
auditing authority retrieves all ECTs sharing the same workflow
|
||||
identifier ("wid") from the audit ledger and reconstructs the
|
||||
complete DAG:
|
||||
|
||||
~~~
|
||||
task-001 (review_requirements_spec)
|
||||
|
|
||||
v
|
||||
task-002 (implement_module)
|
||||
|
|
||||
v
|
||||
task-003 (execute_test_suite)
|
||||
|
|
||||
v
|
||||
task-004 (build_release_artifact)
|
||||
|
|
||||
v
|
||||
task-005 (approve_release) [human, witnessed]
|
||||
~~~
|
||||
{: #fig-fda-audit title="Reconstructed DAG for FDA Audit"}
|
||||
|
||||
The reconstructed DAG provides cryptographic evidence that:
|
||||
|
||||
- Each phase was executed by an identified and authenticated agent.
|
||||
- The execution sequence was maintained (no step was bypassed).
|
||||
- A human-in-the-loop approved the final release, with independent
|
||||
witness attestation.
|
||||
- Timestamps and execution durations are recorded for each step.
|
||||
|
||||
This can contribute to compliance with:
|
||||
|
||||
- {{FDA-21CFR11}} Section 11.10(e): Computer-generated audit trails
|
||||
that record the date, time, and identity of the operator.
|
||||
- {{EU-MDR}} Annex II: Technical documentation traceability for the
|
||||
software development lifecycle.
|
||||
- {{EU-AI-ACT}} Article 12: Automatic logging capabilities for
|
||||
high-risk AI systems involved in the development process.
|
||||
- {{EU-AI-ACT}} Article 14: ECTs can record evidence that human
|
||||
oversight events occurred during the release process.
|
||||
|
||||
## Financial Trading Workflow
|
||||
{:numbered="false"}
|
||||
|
||||
In a financial trading workflow, agents perform risk assessment,
|
||||
compliance verification, and trade execution. The DAG structure
|
||||
records that compliance checks were evaluated before trade
|
||||
execution.
|
||||
|
||||
~~~
|
||||
Agent A (Risk Assessment):
|
||||
jti: task-001 par: []
|
||||
exec_act: calculate_risk_exposure
|
||||
|
||||
Agent B (Compliance):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: verify_compliance
|
||||
|
||||
Agent C (Execution):
|
||||
jti: task-003 par: [task-002]
|
||||
exec_act: execute_trade
|
||||
~~~
|
||||
{: #fig-finance title="Financial Trading Workflow"}
|
||||
|
||||
This can contribute to compliance with:
|
||||
|
||||
- {{MIFID-II}}: ECTs provide cryptographic records of the execution
|
||||
sequence that can support transaction audit requirements.
|
||||
- {{DORA}} Article 12: ECTs contribute to ICT activity logging.
|
||||
- {{EU-AI-ACT}} Article 12: Logging of decisions made by AI-driven
|
||||
systems.
|
||||
|
||||
## Compensation and Rollback
|
||||
{:numbered="false"}
|
||||
|
||||
Compensation and rollback use cases are described in
|
||||
{{I-D.nennemann-wimse-ect-pol}}. The core
|
||||
ECT mechanism supports compensation through the "par" claim,
|
||||
which links a remediation ECT to the original task.
|
||||
|
||||
## Autonomous Logistics Coordination
|
||||
{:numbered="false"}
|
||||
|
||||
In a logistics workflow, multiple compliance checks complete
|
||||
before shipment commitment. The DAG structure records that all
|
||||
required checks were completed:
|
||||
|
||||
~~~
|
||||
Agent A (Route Planning):
|
||||
jti: task-001 par: []
|
||||
exec_act: plan_route
|
||||
|
||||
Agent B (Customs):
|
||||
jti: task-002 par: [task-001]
|
||||
exec_act: validate_customs
|
||||
|
||||
Agent C (Safety):
|
||||
jti: task-003 par: [task-001]
|
||||
exec_act: verify_cargo_safety
|
||||
|
||||
Agent D (Payment):
|
||||
jti: task-004 par: [task-002, task-003]
|
||||
exec_act: authorize_payment
|
||||
|
||||
System (Commitment):
|
||||
jti: task-005 par: [task-004]
|
||||
exec_act: commit_shipment
|
||||
~~~
|
||||
{: #fig-logistics title="Logistics Workflow with Parallel Tasks"}
|
||||
|
||||
Note that tasks 002 and 003 both depend only on task-001 and can
|
||||
execute in parallel. Task 004 depends on both, demonstrating the
|
||||
DAG's ability to represent parallel execution with a join point.
|
||||
|
||||
# Related Work
|
||||
{:numbered="false"}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user