A customer's record is wrong, and you can't tell which service changed it.

What it does

Search a customer, order or invoice ID, or any other identifier the record answers to, and get that record’s history in order, across every service that touched it. Open a step and see what it received next to what it produced, field by field.

One record’s journey in the demo: ten steps across two services, ending in the dead-letter queue.

The transformation step: Phone went in with a value and phone came out null. That pair is the bug, a mapping that reads Phone__c.

Then replay that step’s recorded input against your corrected code in development, and compare the result with the original.

The same recorded input, sent to a corrected handler in development. phone came back with its value, and the comparison names the one field that changed. Nothing is sent until you have read what will be sent, and the destination has to be on an allowlist.

How it differs

Follows records, not requests

You search by a business ID. One record is a Salesforce ID in one service, an internal ID in another and a queue message ID in between; search any of them and you get the same journey. Tracing finds a request by its trace ID.

Shows the field that changed

Each step records what it received and what it produced. The diff is structural, a path with its value before and after, so a renamed field and a lost value both show.

Replays a step against development

Rerun a step’s recorded input against a development destination on an allowlist, and compare the new result with the recorded one. Replay to production is not supported.

Runs on your own PostgreSQL

PostgreSQL is the only required backing service. No Kafka, no Elasticsearch, no agent, no workflow engine to move your code onto. The SDK wraps the code you already have.

It is not a replacement for OpenTelemetry. When OpenTelemetry is present, the SDK reads the active trace and span IDs onto each event, so you can move between the two.

The claim, and the neighbours

As of September 2026, I have not found an open-source tool that does all four for services you already run: (1) follow one record by its business id and aliases across services; (2) capture what each step received and produced and show the field that changed; (3) replay a recorded input against development; (4) with no platform to move onto.

Several open-source tools do part of it:

Tool	What it does	What it lacks for this job
Apache NiFi provenance	Finds a piece of data, shows it at each step, replays it	Only data moving through a NiFi dataflow
Workflow engines such as Temporal	Keep each execution’s inputs and results, searchable	Only code written as their workflows
Tracing backends such as Jaeger or Grafana Tempo	Find traces by span attribute, such as an order id	No documented capture of step payloads, field diff or replay
Webhook servers such as Svix	Deliver webhooks with retries	Only the webhook, not the steps around it
Model-history libraries such as PaperTrail or django-simple-history	Record before and after values of a model’s fields	One application’s database models only
Traffic capture and replay such as Keploy and Kubeshark	Record traffic; Keploy replays it as tests	No record history by business id across services
Lineage standards such as OpenLineage	Lineage of jobs, runs and datasets	No single record in the model

Convoy, Bemi and n8n come close to parts of this and are source-available rather than OSI open source. Commercial tools such as Nodinite, Turbo360, Particular ServicePulse, Dynatrace Business Flow and the hosted tracing backends, Honeycomb among them, do this job on their own platforms, which shows teams pay for it.

docs/ALTERNATIVES.md has the licence, the overlap and the gap for each, with a source and the date it was checked. If a tool does all four, this claim is wrong: please open an issue with a link to it.

Alternatives, in fullEach tool's licence, overlap and gap, with a source and the date it was checked (16 September 2026).

Try it in a minute

You need Docker with Compose. Nothing else: no Node, no database, no account.

git clone https://gitlab.com/jojithedev/wayscribe.git && cd wayscribe

docker compose -f infrastructure/compose.yaml \
               -f infrastructure/compose.demo.yaml up --build

That builds the images and starts the API, the interface, PostgreSQL, a queue, and four demo services with a broken integration to investigate. Measured on 2026-09-14 from a fresh clone on a laptop with no Docker layer cache, the build took 38 seconds and the boot 12; the first run also downloads the base images.

Then start a journey:

curl -X POST http://localhost:3100/trigger

Open http://localhost:3000, sign in with the development admin token, replace-for-local-development-0000, and search 0018Z00002ABC. Set your own token and encryption key before the stack holds anything real; the quick start shows how.

Instrument a service

The Node SDK, @wayscribe/node, is not published on npm yet. Until it is, pack it from a clone of the repository, commit the tarball to your application, and install it by path:

pnpm install
pnpm --silent --filter @wayscribe/node run pack:release /path/to/your-app/vendor/
cd /path/to/your-app
npm install ./vendor/wayscribe-node-0.1.0.tgz

One recorder per process:

return createRecorder({
  endpoint: process.env.WAYSCRIBE_URL ?? "http://localhost:8080",
  apiKey: process.env.WAYSCRIBE_API_KEY ?? "",
  serviceName,
  // Must be the environment the API key was issued for.
  environment: process.env.WAYSCRIBE_ENVIRONMENT ?? "development",
  // Leads carry personal data. Keep the fields, replace their values.
  redact: ["**.email", "**.phone"],
  // Prints `delivered_first`, or why nothing arrives. Off once it sends.
  logDiagnostics: process.env.NODE_ENV !== "production"
});

Then, in a webhook handler, a journey per record and a wrapper per step:

// The entity is what someone will search for: the form provider's lead id.
const journey = recorder.startJourney({ entity: { type: "lead", id: leadId } });
journey.record({ operation: "received", name: "receive-lead-webhook", input: request.body });

let lead: Lead;
try {
  // Records the body going in and the lead coming out, and the diff between.
  lead = journey.transform("normalize-lead", request.body, () => parseLead(request.body));
} catch (error) {
  journey.fail("reject-malformed-lead", error);
  response.status(422).json({ error: "malformed lead" });
  return;
}

Both excerpts come from the Express, BullMQ and HubSpot recipe, whose code the repository type-checks against the SDK on every pipeline. The SDK needs Node.js 22.12 or later and has no runtime dependencies.

Node SDKThe full surface, configuration and guarantees.

RecipesExpress and BullMQ, Fastify and SQS, Next.js and Stripe.

Trust

• Self-hosted. No account and no hosted service. Everything is kept in your own PostgreSQL, 15 or later.
• No telemetry. The running services send no telemetry and no analytics, and make no outbound connection other than the ones your configuration creates, such as replays to the development hosts you allow. This site has no analytics, no trackers and no cookies either.
• Apache-2.0, for every package, the SDK included.
• Redaction by field name, at any depth: in the SDK before a payload leaves your process, and again on the server before it is stored. A credential under a name no rule knows is warned about, not redacted. Entity identifiers and alias values are encrypted at rest; payloads are stored as plain jsonb after redaction.
• A security review packet for the engineer deciding on a pilot: data, authentication, deletion, supply chain and known gaps, each linked to its source. The pre-release security review it cites (2026-09-16) was done by an AI review agent at the maintainer’s direction. It is not an independent audit, and no outside party has reviewed the code.
• A 0.x preview. Nothing is published yet: no npm package and no container images. Releases will be 0.x, where a minor release may change the API.
• How it is built. AI agents write most of the code; the maintainer makes the decisions, and each is recorded with its reasoning in the decision log.

Security review packet

Security model

Links

• Source, issues and merge requests: gitlab.com/jojithedev/wayscribe. Development happens there.
• GitHub: github.com/wayscribe/wayscribe is the read-only mirror. Pull requests opened there cannot be merged.
• Documentation: quick start, roadmap, changelog, decision log.
• Reporting a vulnerability: email security@wayscribe.dev or open a confidential issue on GitLab, as the security policy describes.

If a tool already does all four things above, or something on this page is wrong, please open an issue.