How Auditors Verify Our Work
FinAdvantage produces a complete, exportable audit trail for every workflow run. This page shows you exactly what data is recorded, how it is structured, and how to export it for audit documentation.
The Five-Stage Audit Trail
Every workflow execution passes through five audit-gated stages. Each stage writes an immutable record to the execution trace.
A workflow run is created with a versioned pipeline definition. Every input file is ingested, header-detected, column-normalized, and typed before execution begins.
The pipeline execution record captures the pipeline version, triggering user, input file bindings, and the deterministic ingestion decisions (header row, column names, coerced types). Logged before any node runs.
Each node runs as SQL against a DuckDB engine (via the MCP server) or a deterministic tool. The exact query, tool parameters, and result row counts are logged.
Every run_sql statement, every tool invocation, its parameters, duration, and output key are written to the execution trace before the result is promoted. Same query over same data → same output, every run.
Any sensitive step — an ERP write, a flagged exception, a human-review node — pauses the run. The reviewer sees full context and approves, rejects, or edits before it continues.
The review decision (approved/rejected/edited, who, when, notes) is recorded and gates the write. The run resumes from its saved checkpoint exactly where it paused.
Approved write operations are posted to your ERP, then immediately read back to confirm they posted correctly. Transient failures are retried up to 3× before surfacing an exception.
POST → READ_BACK → if mismatch, retry with exponential backoff. Final status written to PipelineExecutionEvent with verification_confirmed=True/False.
Before a run is marked complete, acceptance assertions (row counts, tie-outs) run against the actual output. The full trail — queries, tool calls, reviews, ERP confirmations — is exportable.
Acceptance assertions (e.g. matched + unmatched = input, row_count > 0) are evaluated against the run's own output parquet. The export joins execution + events + steps + review data into a CSV or PDF for audit documentation.
The Audit Data Model
Eight first-class tables power the audit trail. Every row is timestamped, attributed to an organization, and immutable.
PipelineExecutionRoot record for every run. Contains pipeline version, triggering user, input bindings, status, and start/end timestamps.
PipelineExecutionEventPer-node events: node_started, node_succeeded, node_failed, node_skipped, awaiting_review, resumed, pipeline_finished. Includes payload and node_id.
PipelineExecutionStepStep-level detail for each node execution, including the tool run and outcome.
ToolInvocationEach atomic tool call (including run_sql queries). Parameters, result row counts, and error state are recorded.
PipelineCheckpointSaved graph checkpoints used for pause/resume and to identify review/approval points.
ExecutionFeedbackPost-run user feedback (correct / near_correct / very_wrong) with correction notes, fed back into the next generation.
Per-Org MCP Isolation
Your ERP OAuth tokens run in a dedicated subprocess. No other organization shares your process, memory, or credentials.
┌─────────────────────────────────────────────────────────────────────┐ │ Platform Core │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Org-A │ │ Org-B │ │ Org-C │ │ │ │ (Tenant) │ │ (Tenant) │ │ (Tenant) │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ MCP Subproc A│ │ MCP Subproc B│ │ MCP Subproc C│ │ │ │ (Isolated) │ │ (Isolated) │ │ (Isolated) │ │ │ │ │ │ │ │ │ │ │ │ QB Creds A │ │ QB Creds B │ │ QB Creds C │ │ │ │ Xero Creds A │ │ Xero Creds B │ │ Plaid Creds C │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ No shared state. No shared memory. No credential leakage. │ │ Circuit breakers isolate failing tenants and limit concurrency. │ └─────────────────────────────────────────────────────────────────────┘
Compliance Standards
The audit trail is designed to support the evidence auditors need under the following frameworks.
Every journal entry, approval, and modification timestamped and attributable to a specific user.
Controls over data isolation, encryption at rest, and access logging documented in the security architecture.
Prepared by Client (PBC) tracking and evidence collection are designed to support audit preparation workflows.
On our compliance roadmap. Our security architecture is built around SOC 2 trust principles — security, availability, and confidentiality — as we prepare to pursue formal third-party certification.
Data export and erasure requests are supported through our privacy team. Data is stored with our cloud hosting providers; residency options can be discussed before onboarding.
Need the Full Audit Package?
Enterprise customers can request the complete audit documentation package including data dictionary, schema diagrams, sample audit exports, and a call with our security team.