For the people who have to integrate it

The structure below is illustrative. It is not the published contract, the field names are indicative only, and nothing here should be used to size an integration. It is here so that an architect can see what provenance does to a payload before booking a call.

submission
  submission_id
  received_at
  source                      // inbox, API, upload
  documents[]
    document_id
    media_type
    page_count
  record
    fields[]
      name
      value
      status                  // extracted, validated, corrected, absent
      provenance[]
        document_id
        page
        region
      conflicts[]             // other values found, with their own provenance

The part worth looking at is conflicts[]. A field that appears in the slip and again in the schedule with a different value does not get collapsed into one answer before it reaches you. Both are carried, both keep their provenance, and an underwriter’s decision is recorded as a status change rather than as a silent overwrite.

Provenance is not a link to a document. It is a reference to a region of a page of a specific document in a specific submission, and it survives into whatever you export. If your audit requirement is to show a regulator where a bound figure originated, that chain is the point of the product rather than a feature of it.

These are deliberately blank until engineering confirms them. We would rather publish nothing than publish something an integration gets built against and we then change.

Plenty can, and it is a fair question to put to us. Pulling fields out of a clean PDF is not the hard part and has not been for a while. A competent team gets a demo working in a fortnight.

The cost that does not stop is the long tail. A broker changes the layout of a schedule and the parser that worked last month stops. An MRC follows a different version of the wording. A scan comes in at an angle, or a schedule arrives with two sheets that disagree. None of these is difficult on its own and there is no end to them, so the work is maintenance rather than a project, and it competes with everything else your team could be doing.

Alongside that sits the part teams usually underestimate: knowing whether a change made things better or worse. That needs a held-out set of your own documents, scored field by field, run every time anything changes. Building the extraction is a quarter. Building the thing that tells you it still works is the rest.

So the honest version is that we are not selling you something you could not write. We are selling you not having to keep writing it. If your team would rather own it, the API exists so that you can take the record and do what you like with it.

Once an underwriter has reviewed the record, SnapLine pushes it to your system over the API. Nothing is retyped from a screen.

It does not wait for the record to be complete. The fields that are there go across; the ones that are missing or that an underwriter has flagged stay marked as open and are raised to them rather than holding up everything else. That is deliberate. A push that waits for a perfect submission is a push that rarely fires, and the result is somebody rekeying the whole file because four fields out of sixty were absent. The point of the exercise is that the fifty-six do not get typed twice.

What the record lands in, which fields map to which of yours, and what triggers the push are agreed with your team. They differ at every customer we have worked with, so we do not assume them.

SnapLine sits at intake and hands on a record, and the section above says what that handover looks like. What it asks of you is narrower than it usually sounds.

We are not shipping a standard connector for any named policy administration system. If someone tells you otherwise about this product, they are ahead of the evidence. Getting the record into a given system is scoped as work, and the technical call is where that gets sized honestly rather than estimated on a web page.

What we can say before that call: nothing needs migrating to evaluate it, your systems of record stay where they are, and the evaluation runs on your own submissions rather than ours.