Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 12 · LESSON 12.4

Record external effects and verify across clusters

Record external effects and retain verifiable exports unchanged.

Lesson 71 of 86 · FabrCore 2.0

Overview

A model/tool trace alone does not independently prove a database update or HTTP side effect. Instrument the actual trusted operation with supported evidence helpers and record a redacted, bounded description or digest. Verification and authorization remain separate concerns.

Instrument the effect where it occurs

A model asking a tool to update a ticket is not proof that the ticket system accepted the change. Wrap the actual trusted HTTP/database/storage operation with the supported evidence helper and record its bounded, redacted outcome. This ties the observed effect to causal context without putting secrets or entire documents into an evidence record.

Business atomicity needs its own design

Evidence capture and the external write can fail independently unless your application coordinates them through a suitable transaction/outbox or external audit mechanism. A signature protects the recorded evidence; it does not make two separate systems atomic. Reconciliation must be able to tell whether the request succeeded when the caller lost its response.

Record a trusted external effect

  1. Wrap the request/Graph operation with RecordHttpCallAsync, RecordDbEffectAsync, RecordStorageEffectAsync or RecordLibraryCallAsync as appropriate.
  2. Bind outcome, causal context and redacted metadata to the evidence. Use transactional/outbox or external audit evidence when the business guarantee requires it.
  3. Export stable chunks without rewriting signatures, certificates or records. Verify against the correct trust bundle across clusters.
external-effects.md · reference snippet
using FabrCore.Core.VerifiableExecution;
using FabrCore.Sdk.VerifiableExecution;

private IVerifiableExecutionContext? _evidence;

public Task InitializeAsync(AgentConfiguration config, IServiceProvider serviceProvider)
{
    _evidence = serviceProvider.GetService<IVerifiableExecutionContext>();
    return Task.CompletedTask;
}
external-effects.md · reference snippet
var result = await _evidence.RecordDbEffectAsync(
    operation: "UpdateOrderStatus",
    target: "Orders",
    subject: orderId,
    effect: () => ExecuteUpdateAsync(orderId, status),
    metadata: new Dictionary<string, string?>
    {
        ["db.system"] = "sqlserver",
        ["db.name"] = "orders",
        ["row_key_hash"] = VerifiableExecutionHash.HashText(orderId),
        ["command_hash"] = VerifiableExecutionHash.HashText(commandText),
        ["parameter_hash"] = VerifiableExecutionHash.HashText(redactedParametersJson),
        ["transaction_id"] = txId,
        ["rowversion"] = rowVersion
    });

var affectedRows = result.Value;

Compare evidence with the actual operation

  1. Perform a harmless fixture update through the instrumented helper and export its evidence. Identify the record naming the actual operation and its outcome.
  2. Compare the record with the fixture system's authoritative operation ID/result. Verify the bundle without rewriting its records, signatures or certificates.
  3. Simulate a lost response after the fixture update. Inspect the operation result before retrying, and report any evidence gap instead of asserting that the effect did not occur.

A reviewer can now distinguish a proposed tool call, an observed external outcome and a verifiable record of that outcome.

If the result is different

SPIFFE identifies the signing workload, not the authorized agent handle. Do not claim uninstrumented effects are independently proven.

Go deeper

Explore the related documentation.