Smart Actions

KDBL Context Lake (K-Lake) doesn't stop at cataloguing your files — it takes action on them. After each crawl, every file flows through a pipeline of actions you choose per source. Content extraction is the first action (on by default); from there you compose a pipeline that can redact sensitive content, notify your own systems, and more.

Think of it as "what should happen to each file once K-Lake has found it?" — answered per source, with a library of building blocks.

The action library

Action	What it does	Status
Content extraction	Pulls searchable text out of each file (documents, spreadsheets, PDFs, images, and more) so it can be searched and served to AI. The default first step.	Available
Redaction	Masks sensitive patterns — identifiers, email addresses, card numbers, and your own custom patterns — in the extracted text, so search results and AI answers return the masked version.	Available
Webhook	Sends a signed notification to an endpoint you control whenever a file is processed, so your own systems can react in real time.	Available
Fallback extraction	When the default extractor fails on a file, retry it automatically on a heavier backend — so the structured or complex documents the fast default can't parse still get extracted.	Available
Entity enrichment	Reads the extracted text and records the people, organisations, locations and agreements it names, plus the relations between them — building the knowledge graph.	Available
Data placement	Copy or tier each object to another location.	Coming soon
Custom script	Run your own sandboxed logic over each file.	Coming soon
Custom container	Run your own container as a one-shot job per file.	Coming soon

Coming-soon actions appear in the catalogue so you can see what's on the way; they're inert until released.

Pipelines cascade

Actions run in order, each building on the one before it. A common pipeline is:

Extract  →  Redaction  →  Webhook

Extraction produces the searchable text; redaction masks the sensitive parts of that text; the webhook then tells your systems the file is ready. You decide the order and which steps are enabled, per source.

How it runs

• Automatic. The pipeline runs after each crawl, with no manual step. New and changed files flow through it as they're discovered.
• Only re-does what changed. A file that has already been through a step — at the same version, with the same settings — is skipped. Change a redaction rule and only redaction re-runs; there's no need to re-crawl or re-extract the whole source. Changes take effect within a few moments.
• Resilient. Each step is tracked per file, so a transient failure is retried rather than silently dropped.
• Retroactive. Adding a step to a source that has already been crawled does not only apply to new arrivals — a background sweep finds the files that were processed before you added it and puts them through. Enabling redaction or enrichment on an existing source backfills it without a re-crawl.
• Elastic. The runners that execute your pipelines scale automatically with the backlog — capacity is added when work piles up and released when it drains. See the sizing guide.

Configuring a pipeline

A source's Smart Actions panel shows its pipeline as a top-to-bottom list of cards. You can add an action, enable or disable it, reorder steps, expand a card to configure it, and remove it.

Everything is also available from the CLI and the REST API, so you can manage pipelines programmatically:

• Web console — the Smart Actions panel on each source's detail page.
• CLI — the kdbl-control source action commands (catalog, list, add, set, reorder, remove).
• REST API — the action catalogue and per-source pipeline endpoints.

The actions in detail

Content extraction

The default first step. It reads each eligible file and produces the searchable text and structure that power content search and AI answers over MCP. You control which files are eligible with extension, size, and path filters, and you can watch extraction progress live on the source's detail page. Leaving extraction off means a source is catalogued (its files are inventoried) but its contents aren't searchable.

Redaction

Redaction runs over the extracted text and masks matches of the patterns you select — common identifiers, email addresses, and card numbers out of the box, plus any custom patterns you supply. The masked text is what search and AI answers return. Because it operates on a source's own pipeline, you can apply redaction to sensitive sources and leave it off elsewhere, and tune the rule set without re-extracting.

The console gives redaction a proper configuration form with a rule tester: paste representative text, see exactly what the current rule set would mask, and adjust before applying it to a source. A redaction rule that is slightly too broad is expensive to discover after the fact, because the masked text is what everything downstream then returns.

Each run also records what it actually removed — how many matches, of which rule — so you can confirm a rule is doing something, and see when one stops matching after a document format changes.

Webhook

The webhook action sends a signed JSON notification to an HTTPS endpoint you configure, each time a file completes its pipeline. Use it to kick off downstream workflows in your own systems — ticketing, data-loss-prevention review, record-keeping. Each request carries a signature so your endpoint can verify it came from K-Lake, and outbound destinations are validated to keep notifications going only where you intend.

The console's webhook form includes a target pre-flight: it checks the endpoint is reachable and acceptable before you save, rather than letting every delivery fail silently against a typo'd URL.

Entity enrichment

Enrichment reads the extracted text and records the entities it names, building the knowledge graph. Like the other actions it is enabled per source, so you can build a graph over your contracts without doing the same work on a bulk archive.

Per-document work is bounded by a character budget, so one pathological file cannot monopolise the fleet, and the default entity schema can be overridden per source when a source has its own vocabulary. Coverage — how much of a source has actually been enriched — is reported in the console, the CLI and the API, so a draining backlog is visible as a partial number rather than looking like a source with nothing in it.

Fallback extraction

A resilience action for extraction quality. K-Lake defaults to a fast, high-throughput extractor that handles the bulk of a corpus cheaply — but some files (complex layouts, unusual or structured formats) don't parse cleanly on it. Fallback extraction catches exactly those: when the default extractor fails on a file, it retries that one file on a heavier backend (for example a higher-fidelity document extractor), so the hard cases still become searchable without slowing down the common case.

• Triggers on failure only — it is not part of the normal success cascade, so it adds no cost to files that extract fine the first time.
• Scope it by file extension (and, optionally, size and path) so only the types you care about fall back — e.g. retry failed pdf / docx on the high-fidelity engine and let everything else be.
• Configure the target backend (the extractor to retry on) in the action's settings. It's best-effort: a failed fallback never blocks the pipeline.

See also

• Sources — where pipelines are configured
• Web console — the Smart Actions panel
• Sizing guide — how the runners scale