Form. Fact. Verify.

A Klarefi workflow has three layers. The form is what the applicant sees and fills out. The facts are what your team actually needs to know: each one a specific, answerable question the agent resolves from answers and documents, with evidence attached. Verify checks resolved facts against your own systems through connectors. Most authoring mistakes come from blurring these layers, so keep them straight: fields collect, facts resolve, checks confirm.

What makes a good fact

One fact, one unambiguous question. The agent resolves each fact independently and attaches evidence to it, so a fact that bundles two questions produces evidence that supports neither cleanly.

• Good:“Policy number” and “Policy start date” as two facts.
• Bad:“Policy details” as one fact. What quote would ever prove that?

Every fact your workflow declares has to resolve before the case is ready for review. There is no optional fact and no partial pass. If you ask for it, your agent chases it and your operators see the outcome. So the list of facts is a decision about what your team genuinely needs, and the shortest list that supports the decision is the right one.

Choose where each answer comes from

This is the most important choice you make on a fact, because it decides what counts as proof. Each fact draws from the form, from the documents, or from both.

• Form. The applicant states the value and the agent takes it as stated. Right for contact details, preferences, and anything the applicant is simply the source of truth for. Cheap, fast, and reliable.
• Documents. The agent has to find the value in an uploaded document and cite the exact passage, with the page and the location on it, before the fact resolves. A confident typed answer will not satisfy a document-sourced fact. This is where the agent earns its keep.
• Both. The applicant answers on the form and the agent confirms the answer against the documents, then reports whether the two agree. A match is a strong signal. A mismatch surfaces on the fact card with the distance between the two values, so your operator sees the disagreement instead of a silent overwrite.

Turning on Documents is how you demand proof. Use it for the facts your decision and your payout rest on: identity, amounts, dates of incidents, coverage terms. These are the facts an auditor will ask about, and they are the ones you want a quote behind. Use Both when the applicant knows the answer and you still want the paperwork to back it up, which is the strongest position you can be in for a disputed value.

Every document you demand is friction for the applicant and a possible needs-input card for your operators. Spend that budget on the facts that deserve it.

Give the agent extraction guidance

For any fact the agent reads out of documents, the guidance you write is the difference between a clean citation and a needs-input card. Four fields do the work.

• A clear name and descriptionthat say what the value is, not just what it is called. “The total amount claimed, in euros, as stated on the invoice” beats “Amount”. The description goes to the model as its instructions, so write it as an instruction.
• An example of a valid value, so the agent knows the shape you expect.
• The right type. Type is your validation. A date typed as a date gets parsed, normalized, and returned as a real date; the same value typed as text gets whatever the document happened to say. A number typed as a number comes back numeric. Choosing the type correctly does more for data quality than any rule you could write by hand.
• For choice facts, the optionsyou define, each with its own definition and example. This is the highest-leverage guidance you can write: it is what puts a borderline document in the bucket you meant rather than the one the model guessed. Say what “storm damage” covers and show a line that counts as it, and the judgment stops being a coin flip.

Verify checks against your systems

Extraction tells you what the documents say. Verification tells you whether your systems agree. A verify check runs a function on a connector you have installed: look up the policy number in your policy system, confirm the customer record, check a register.

Setting one up takes two decisions. You enable the connector function you want to run, and you bind its arguments to facts, so the policy number the agent extracted becomes the policy number your system gets looked up by. The check runs once its facts resolve, and the result lands in the case file as its own card next to the facts.

• Verify the facts that have an authoritative source on your side. A policy number can be checked. A description of events cannot.
• The card shows what your system returned, in your system's own words. Klarefi reports the answer and leaves the judgment to your operator, which is what keeps the decision yours.
• Verification results are operator-facing only. Applicants never see which checks you run or what they returned, so you can verify freely without exposing your controls.

Test before you publish

The builder runs diagnostics as you author: errors block testing and publishing, warnings tell you where the workflow is weaker than it should be. Clear the errors, read the warnings.

Then run a test session. A test intake goes through the real pipeline, real extraction, real cross-checking, real verification against your connector, and lands as a real case in your queue, kept separate from live work. Fill it out the way a distracted applicant would, with your actual documents, including the blurry ones.

Read the resulting case file like an operator:

• Did the facts you care about resolve, with quotes that actually support the values?
• Are the needs-input cards genuine judgment calls, or symptoms of a vague description you should sharpen?
• Did anything you marked as Both come back as a mismatch, and is the mismatch real or an artifact of a loose fact definition?

Iterate until a test case reads clean, then publish. The cost of a vague fact is paid on every single intake. The cost of fixing it is one edit before launch.