Compatibility: Pactmark 0.1.x.

The situation

An insurance operations team processes first-notice-of-loss claims. Each claim arrives as a packet: a form, photographs, a policy reference. Someone has to extract the structured facts, check them against policy terms, flag exceptions, and produce a decision packet that a human adjuster signs off. The work is repetitive and the volume is high — which is exactly why automating it is attractive, and exactly why an unbounded assistant is unacceptable.

Regulated purpose

The reason for processing is not “because we can”. It has a registry code and a retention policy.

Restricted data

Personal and medical data with residency requirements and a model contract behind it.

Reviewable output

The packet is what the adjuster reads. It must be identifiable by its exact bytes.

Retained for years

And readable by someone who was not there, long after the run.

The WorkOrder

apprenticeship_protected
The strongest signal available for “a human is still learning to trust this”. The work is done, and it is done under protected conditions with mandatory review.
gdpr-6.1.b@2
The lawful basis, versioned. When your legal register moves to version 3, existing grants bound to version 2 stop matching — which is the correct behaviour, not an inconvenience.
eu-central / DE
Recorded on the work order. Pactmark does not enforce residency — it records the claim so that a reviewer can check it against your actual deployment.

The flow

Figure 1. In a regulated context, read the third column as your control map. Each stage has a named gate, and each gate has a stable failure code you can alert on.

The model boundary is a contract, written down

Every field is a claim about your provider agreement, and every field contributes to modelSecurityProfileDigest. If someone quietly switches to a US endpoint or a model with different retention, the digest changes and accepted work orders bound to the old profile stop matching.
allowedDataClasses does not include highly_restricted. If a claim were classified that way, the run would be refused rather than downgraded. Declare the classes you actually have a contract for.

Verification is deterministic first

Figure 2. The packet is content-addressed, then checked. Structural checks — schema, required sections, policy-reference resolution, arithmetic — run with no model and no credentials.
Notice what is not here: a model-assisted eval for “is this a good packet”. Reach for one only where a deterministic check genuinely cannot exist — and when you do, its method is recorded as model so a reader can weight it appropriately.

The evidence a reviewer actually reads

The doesNotProve list is what makes this record usable in a regulated setting. A record that only listed achievements would be read as a broader claim than it is — which is threat model row TM-18.

Retention: five different clocks

Do not give these one policy: Deletion must be tenant-scoped, authorised, idempotent and observable, and projections must be rebuilt or removed after source deletion.

What you still own

Whether the decision is right

Verification checks structure. Correctness of the recommendation is the adjuster’s judgement.

Source document authenticity

Pactmark addresses bytes. It does not tell you the photographs are of the right car.

The regulatory mapping

Evidence is an input to your control framework. It is not a compliance conclusion.

Residency in practice

The profile records eu-central. Your infrastructure has to actually be there.

Artifacts and verification

Binding, rubrics and time-boxed exceptions.

Retention and audit

Separate records, separate clocks, verified deletion.