How an EdgeRecord engagement works

Before, during, and after the change.

EdgeRecord is built around a simple loop: capture state before the work, record what happens during the change, verify the result against the baseline, produce a receipt, and preserve the record for whoever needs it next.

Step 1

Baseline.

Before the work begins, we capture the current state of the systems, accounts, configurations, devices, and dependencies in scope. The baseline is what the change will be measured against, so it is recorded with enough detail that the comparison later is meaningful.

Examples of baseline material: firewall rule export, device firmware version, account list with privilege scope, configuration file hash, network topology snapshot, backup status, recovery path test result.

Step 2

Record.

During the change itself, we document what happens: who acted, what they modified, what was approved, when each step occurred, and what supporting evidence exists. The record is built as the work happens, not reconstructed after the fact from memory or chat scrollback.

Entries can come from operators, scripts, MSP technicians, or vendors. The format stays consistent so the entire change is readable as one timeline rather than a folder of unrelated artifacts.

Step 3

Verify.

After the work, we compare the after-state against the baseline. The point is to make drift, unintended side effects, and gaps between plan and reality visible — while the people who did the work are still in the room.

Verification covers both the intended change (did we do what we said we would do?) and the surface area around it (did anything else change that we did not intend?).

Step 4

Receipt.

The output is a plain-English evidence report — readable by an owner, an insurer, or a successor operator — with a machine-verifiable hash chain underneath for anyone who needs to confirm the record was not edited after the fact.

The receipt is portable. JSON for systems, PDF for humans, and an explicit list of what was verified and what still needs attention.

Step 5

Preserve.

The record is kept available for incident review, insurance, legal review, audit, recovery planning, and operator handoffs. Old records do not become stale — they become more useful, because they establish what was true before the next change.

Records can be exported, archived, or fed into downstream automation. The business owns the record, not the tool.

What you get

One change. One readable record.

A first engagement — the Change Evidence Sprint — takes a single upcoming piece of work (a migration, vendor visit, firewall change, device deployment, cloud update, or incident review) and turns it into an evidence report you can show to anyone who needs to understand what happened.