Journey Builder

A journey is the path an applicant takes from the first screen to an outcome. You draw it as a graph of steps joined by connections. Each run of a journey follows one path through that graph and ends with a verdict: pass, refer or fail.

A journey is versioned. Each run is pinned to the version that was live when it started, and to the rulebook versions that version binds, so a run in progress never moves to a newer version.

Every version is checked each time it is saved: the graph is connected, every step is reachable, every path ends in an outcome, every condition is valid, and every requirement code a step cites exists in the bound rulebook. A version with errors cannot be submitted for review.

• Form. Ask the applicant for information. See Forms.
• Check. Run a verification, such as document capture and verification, liveness, or sanctions, PEP and adverse-media screening. A check is written against a vendor-neutral capability, and a vendor is chosen when the run reaches it, from the vendors you allow for that step. If a vendor errors or times out, the engine retries with backoff, then fails over to the next allowed vendor. Every attempt and failover is recorded with its reason.
• Condition. Branch on what is known so far: the applicant, the resolved jurisdiction, earlier check verdicts, a score or a review decision. Conditions use a small, sandboxed expression language; no arbitrary code runs.
• Score. Combine signals into a risk score that later conditions can read.
• Review. Hand the run to a person. See Review steps and cases.
• Wait. Pause the run until something happens or a deadline passes, for example a vendor result that arrives later. Deadlines are swept on a timer, so a run that waits too long moves on along the path you defined for it.
• Outcome. End the run with a verdict.

Each check returns one normalised verdict (pass, refer, fail, error or not_run) with reason codes from one taxonomy, whichever vendor ran it. The vendor’s raw answer is kept as a hash in the evidence, never copied into it.

Build forms in the Forms tab. Each field can carry:

• Validators — required, formats, lengths and allowed values. The same rules run in the hosted form, the Test console and the headless API.
• Show-if — show a field only when a condition holds.
• Prefill — fill a field from an earlier check’s output, an earlier form, the applicant record or an input you pass when starting the run. A prefilled field can be locked so the applicant cannot change it.
• Consent — a consent field pins a specific version of a text from your organisation’s consent library. The library is append-only: a change is a new version, and a journey picks it up through a new journey version, reviewed like any other. The consent the applicant saw, in the language they saw it, is recorded with their submission.
• Languages — labels, help texts, options and messages are translated per journey. English, Hindi and Arabic are supported today; Arabic is shown right to left.

A version moves through draft → in review → approved → published, and is later retired.

• A draft can be edited freely. Submitting it runs validation.
• Approval needs a person other than the version’s author and last editor.
• Journeys run in two environments, Test and Production. Test allows a single-person publish for experimentation, recorded as such. Production always needs maker-checker.
• Production is reached only by promotion from Test. The promotion shows the differences (steps, forms, vendor policies, translations) and is itself approved.

Rollback

• Emergency rollback. An Administrator or Compliance admin can switch an environment straight back to a version that was approved and live in that same environment before. A reason is required and the switch is recorded as an emergency. No second approval is needed, because that content was approved already.
• Any other rollback copies the earlier version into a new draft with a new version number, which is reviewed and published as usual. The person who asked for the rollback cannot approve or publish that draft.
• Runs already in progress stay on the version they started on.

Every change, transition, promotion and rollback is written to a hash-chained change history, shown on the journey’s Versions page and exportable as CSV.

A review step opens a case in the cases queue when a run reaches it. The step sets the queue and team, the SLA and whether four-eyes applies.

• Assignment, the SLA, four-eyes and the audit trail work as for any other case. A four-eyes step needs two different people before the run moves on.
• The case shows the run’s whole path on one screen: every step with its verdict, vendor and reasons, every vendor attempt, retry and failover, and every earlier review.
• The reviewer can record reason codes from the same taxonomy, narrowed to the ones the step allows. They are kept on the case, the audit log and the run.
• The decision resumes the run: Approve, Reject or Escalate follows the matching connection out of the review step.

When a run ends, Journey Builder produces an evidence bundle as signed JSON and as a PDF. It contains:

• the journey version that ran, with the hash of its definition;
• the rulebook versions and hashes it was bound to;
• every step the run entered, in order, with the requirements each step cites;
• each check’s vendor, verdict, reason codes and failover history, with a hash of the vendor’s raw answer;
• form submissions, redacted; consent evidence; review decisions;
• the outcome, and the run’s full timeline as a hash chain.

Applicant personal data and raw vendor answers are never included. The bundle is signed with Ed25519, and the public keys are published at /.well-known/omnified-evidence-keys.json, so anyone holding a bundle can verify it offline without access to your account. Download bundles from the Runs page or the API; every download is audited. See Verifying evidence.

A journey version binds one or more rulebooks at a specific version and content hash. Each step can cite the requirement codes it satisfies. Those citations are checked on every save, shown on the canvas, and carried into every run’s evidence, so a reviewer can see which requirement each step of a run was meant to meet.

A coverage view lists mandatory requirements that no path satisfies. When a rulebook changes, Journey Builder shows which steps are affected; rebinding the journey is a new draft, approved through maker-checker like any other.

Journey templates are a starting point, not a compliance opinion. Review each template with your MLRO before go-live.

Authors can describe a journey in plain language and get a proposed draft, or revise an open draft by prompt. The canvas and Forms tab work as before.

• Drafts only. A proposal is validated, then shown as a diff to accept or discard. Nothing is saved until the author saves the draft, and nothing is ever approved or published by the assistant. Maker-checker applies as for any draft.
• The assistant cannot change rulebook bindings or approvals, may only suggest requirement codes from the bound rulebook, and never writes consent wording: a consent field it adds stays unpinned until the author picks a text from the library.
• Only the journey definition and the instruction are sent to the model, never run data or applicant answers.
• Drafting uses research credits, charged on actual usage. The panel shows the most a request can cost before you send it. A draft saved with AI changes is marked “AI-assisted” in its change notes.

• Author drafts: Administrator, Compliance admin and Developer.
• Approve a version: Administrator and Compliance admin, never for a draft they wrote or last edited.
• Publish and roll back: Administrator and Compliance admin.
• Review steps: Administrator, Compliance admin, Member and Auditor see the review queue.
• Settings (hosted links, allowed embed origins, vendor connectors): Administrator, Compliance admin and Developer.
• Change history: Administrator, Compliance admin and Auditor.
• Every role opens Journey Builder except the Approver, whose seat is for policy sign-off only.

All three options drive the same runs, with the same validation and the same evidence. The full endpoint reference is in the API reference.

Hosted link

Create a link in Journey Builder → Settings and send it to applicants. Each link belongs to one environment and always runs that environment’s live version. From the API, a run you start can also hand the applicant a single-use link.

Web SDK

Embed a journey in your site as a modal or inline frame with the dependency-free Web SDK: /sdk/journeys-v1.js, the ES module /sdk/journeys-v1.mjs, and types at /sdk/journeys-v1.d.ts. Add your site to the allowed embed origins in Settings first: the journey can be framed only by those origins and posts its events only to them.

<script src="https://getomnified.com/sdk/journeys-v1.js"></script>
<script>
  OmnifiedJourneys.open({ link: "jl_…", mode: "modal" })
    .on("completed", (e) => fetch("/my-backend/check-run/" + e.runId));
</script>

Events: ready, started, step, completed, failed, expired, error, resize, close. Treat browser events as hints and confirm the outcome from your server before acting on it.

Headless API

Start a run, read its next step, answer forms and read the outcome from your backend, with an API key carrying journeys:run. Send an Idempotency-Key when starting a run so a retry returns the same run.

curl -X POST https://getomnified.com/api/public/v1/journeys/runs \
  -H "Authorization: Bearer omn_sk_test_…" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "journey_id": "6f1c…", "subject_ref": "cust-0001", "jurisdiction": "SG" }'

Test keys run journeys in Test. Responses and webhooks carry ids, statuses and verdicts; personal data you send is sealed in the run’s log.

A key’s environment is the run’s environment, and a key’s jurisdiction list applies to the runs it starts. Agent tokens cannot start runs.

Journey events are delivered to the same signed, retried webhook endpoints as every other Omnified event (see Webhooks for signatures and retries). Payloads carry run, journey and version ids, step ids, verdicts and reason codes, never personal data.

Test runs are marked "sandbox": true and are sent only to endpoints that have Test runs switched on in Settings → Webhooks. It is off by default.

Download a bundle with GET /api/public/v1/journeys/evidence/{run_id} (scope journeys:evidence). The file is an envelope holding the bundle and its detached signature:

{
  "schema": "omnified.journey-evidence-envelope/v1",
  "evidence": { "schema": "omnified.journey-evidence/v1", "...": "..." },
  "signature": {
    "alg": "Ed25519",
    "kid": "…",
    "canonicalization": "RFC8785",
    "bundle_sha256": "<hex>",
    "value": "<base64url>",
    "keys_url": "https://getomnified.com/.well-known/omnified-evidence-keys.json"
  }
}

1. Canonicalise evidence with RFC 8785 (JSON Canonicalization Scheme) and take its UTF-8 bytes. Only evidence is signed.
2. Check that the SHA-256 of those bytes equals bundle_sha256.
3. Fetch /.well-known/omnified-evidence-keys.json and pick the key whose kid matches. Keys are Ed25519 JWKs; retired keys stay published so older bundles keep verifying.
4. Verify value as an Ed25519 signature over the canonical bytes.
5. Optionally recompute the timeline’s hash chain: each event’s hash covers the previous event’s hash, so a removed or altered event breaks the chain.

import canonicalize from "canonicalize"; // RFC 8785
import { createHash, webcrypto } from "node:crypto";

export async function verifyBundle(envelope) {
  const bytes = new TextEncoder().encode(canonicalize(envelope.evidence));
  const sha = createHash("sha256").update(bytes).digest("hex");
  if (sha !== envelope.signature.bundle_sha256) return false;

  const res = await fetch("https://getomnified.com/.well-known/omnified-evidence-keys.json");
  const { keys } = await res.json();
  const jwk = keys.find((k) => k.kid === envelope.signature.kid);
  if (!jwk) return false;

  const key = await webcrypto.subtle.importKey(
    "jwk", { kty: "OKP", crv: "Ed25519", x: jwk.x }, { name: "Ed25519" }, false, ["verify"],
  );
  const sig = Buffer.from(envelope.signature.value, "base64url");
  return webcrypto.subtle.verify({ name: "Ed25519" }, key, sig, bytes);
}

Three Journey Builder tools are available to agent tokens on the MCP endpoint (MCP endpoint). Add them to a token’s tool allow-list when you create it. Every call is written to the audit log as the agent.

No tool approves or publishes a journey. Agents create drafts; people decide.