Configurability
Every industry trusts different sources, needs different facts, and lives with different deadlines. So Corobate lets you set the rules. But it will not let you set rules that make a weak decision look strong — and it keeps a sealed record of every rule you ever set. Here is exactly where the line is.
The rules are not carved in stone. They live in a settings file, not in the program itself. A battery importer, a bank, and a used-car marketplace all run the same engine with completely different rules, and nobody has to rewrite any code to make that happen.
But there is a catch, and the catch is the whole point of the product. You can change the rules before a decision, never after. And every change you make is itself recorded and sealed, so anyone reviewing your work later can see what the rules were on the day you decided, who changed them, and what they changed from.
People usually ask about the same three things. Two of them are dials. The third one is a switch, and that surprises people, so it gets its own section below.
| You want to control… | The setting | What kind of control it is |
|---|---|---|
| How much different kinds of sources are trusted | reliabilityTiers |
A dial. You set the score for each class of source. |
| How old a fact is allowed to be | maxAge, maxAgeDefault, kind |
A dial, set separately for each field, in seconds. |
| How important each fact is | critical |
A switch, not a dial. Required or not required. There is no in-between. |
| How high the passing score is | threshold |
A dial. The default is 0.80. |
| What the three answers are called | verdicts |
Labels. "COMPLIANT" for a passport, "AFFIRM (proceed)" for an AI agent, and so on. |
| The cutoff date for evidence | period_end |
A date. Anything observed after it is thrown out, not just marked down. |
Corobate sorts every fact into one of four classes based on where it came from, and each class is worth a certain number of points.
| Class | What it means | Points out of 100 |
|---|---|---|
| verified | Somebody independent measured it and stands behind the number | 95 |
| modeled | A computer or a model estimated it. Plausible, but not measured. | 80 |
| seller-asserted | The party who benefits from the answer told you so | 50 |
| missing | Nobody supplied it at all | 0 |
Those four numbers are the starting point, not the law. If your industry has good reason to score a modeled value at 70 instead of 80, you change the setting and it applies from then on. Regulated industries with published evidence hierarchies do this routinely.
You cannot score an individual source by name. Corobate does record which specific lab, vendor, or system every fact came from, and that name appears on the receipt. But the name never affects the score. Only the class does.
So you cannot decide that one data provider gets 92 points and a competing one gets 88. If you believe one deserves more credit, you have to make the argument out loud, by placing it in a different class, where a reviewer can see the choice and disagree with it.
A true fact can still be useless if it is old. Corobate handles this in two separate ways, and they do different jobs.
First, a shelf life for each field. You set maxAge in seconds, field by field. A fact past its shelf life is called stale, and a stale fact gets its score knocked down to 0.40 no matter how good its source was. A lab-verified measurement from four years ago is still worth only 0.40 if you said measurements expire after one year.
Here is the real setting from the AI-agent rules, which is a good example because the three fields have genuinely different shelf lives:
| Field | Shelf life | In plain terms | Why |
|---|---|---|---|
requestor_identity | 604,800 seconds | One week | Who someone is doesn't change quickly. |
sso_group_membership | 604,800 seconds | One week | Permissions get reviewed on a weekly-ish cycle. |
device_posture | 86,400 seconds | One day | A laptop can fall out of compliance overnight. |
Setting a shelf life of zero is allowed and means "this has to be current right now." It is not treated as "don't bother checking."
Second, how strict the whole decision is about staleness. That is the kind setting, and it changes what an old fact actually costs you:
| Kind | Used for | If a required fact is missing | If a required fact is stale |
|---|---|---|---|
action | Something is about to happen — money moves, access is granted | Refuse to answer | Refuse to answer |
model | An estimate or a score | Refuse to answer | Answer, but flag caution |
passport | A compliance document about a product | Flag caution | Flag caution |
This is how you express urgency. You do not give a decision a priority number. You shorten the shelf lives and you set kind to action, which means the system would rather say "I don't know" than guess while the clock is running.
This is the one that is a switch instead of a dial, and it is the most common question we get.
You list the fields that a decision genuinely depends on. That list is called critical. Everything on the list has to hold up. Everything not on the list still gets recorded on the receipt, but it does not affect the score at all.
What you cannot do is say "this field is worth 30% of the decision and that one is worth 10%." There is no percentage-weight setting. A field is either required or it isn't.
Because of what weights do to the meaning of the answer. The moment you allow weights, a very strong fact can quietly make up for a very weak one. Your final score goes up, and the number now means "on average, the evidence looked fine."
But that is not the question anyone actually needs answered. The question is "did we know each necessary thing well enough?" — and averages cannot answer it. A bridge with nine excellent cables and one frayed one is not a 90% safe bridge. It is a bridge that fails at the frayed cable.
confidence_bound_by. The receipt does not just say "we're not sure." It says which fact we're not sure about, so somebody can go fix that one thing.There is a second setting, aggregation, that changes how the individual scores get combined. Three options are available. All three obey the same rule.
| Option | What it does | Effect on the final score |
|---|---|---|
minimum (default) | Takes the weakest required fact and uses that | The baseline |
product | Multiplies the scores together, so several mediocre facts compound into a worse answer | Same or lower |
soft-min | A smoothed version of "weakest link" that lets nearby weak facts drag on each other | Same or lower |
Read that last column again, because it is the guarantee that holds the whole design together: every available setting can make the test harder to pass. None of them can make it easier. No combination of options anyone can choose will ever push a decision above what its weakest required fact allows.
That is what makes configurability safe to offer. Handing customers a settings file is only dangerous if the settings can be turned into a way to manufacture confidence. Here they can't. The worst a customer can do to themselves is be too strict, and being too strict is visible, honest, and fixable.
A short list, and every item on it is load-bearing.
| Fixed | What it means | What breaks if it were adjustable |
|---|---|---|
| Stale facts cap at 0.40 | Past its shelf life, a fact scores 0.40 at most, whatever its source | A customer could set the penalty near zero and keep "verified" scores on evidence from years ago. |
| Missing is always 0 | A blank, an empty string, or nothing at all scores zero every time | Absent evidence could be given partial credit, which is the single most common way audit trails lie. |
| Scoring happens on the server | The system that calls Corobate can suggest a reliability number, but it is treated as advice and ignored | Anyone integrating Corobate could promote their own evidence to "verified" on the way in. |
| Stricter only, never looser | The rule from section 06 — no setting raises a score | Everything. This is the promise the receipt makes. |
| Evidence dated after the cutoff is thrown out | If a fact was observed after period_end, the decision is withheld and the fact is named |
You could quietly justify an old decision using information that didn't exist yet. |
Rules should change. Regulations get updated, and what you learn from last year's outcomes should sharpen next year's policy. The question is not whether rules change — it's whether the change is honest.
Rules are versioned, like battery@1.0.0. You do not edit the old one. You publish a new one alongside it, and the old version stays exactly where it was, forever.
The system works out precisely what moved — fields added, fields removed, shelf lives changed from what to what, threshold raised or lowered, labels renamed — and seals that summary with the author's name and the time. A rule change is itself an event with a receipt.
Every receipt records which version of the rules produced it, and the version is baked into the receipt's fingerprint. When somebody checks a receipt from March, the engine loads March's rules and re-runs the arithmetic under them. Tightening your rules in July does not retroactively make March's decisions look wrong — or look right.
Stated plainly, because you will run into it during your first integration.
Rules are attached to a decision type, not to an individual decision. When a receipt is requested, the engine looks up that type's rule set and uses it. There is no way to pass a one-time override for a single unusual decision — no "just this once, treat the shelf life as three days instead of thirty."
If you need tighter rules for rush decisions, you define a second decision type up front and publish it, then send rush decisions to that one. It is slightly more work than a flag on a request, and it is the right trade. A one-time override is invisible after the fact and impossible to review. A named, published, versioned variant sits on the receipt where an auditor can read it.
The practical consequence: spend real time on your decision types before you go live. That is the part of the setup that deserves a meeting, not the code.
| The question | The answer |
|---|---|
| Can I set my own source scores? | Yes, by class. Not by individual vendor name. |
| Can I set how fresh evidence has to be? | Yes, separately for every field, in seconds. |
| Can I weight some facts as more important? | No. Required or not required. Deliberately. |
| Can I set the passing score? | Yes. The default is 0.80. |
| Can I make the system more lenient? | No. Nothing available can raise a score. |
| Can I change the rules later? | Yes — as a new version, with a sealed record of the change. |
| Can I change the rules for a decision already made? | No. Old receipts always re-run under the rules that produced them. |
The arithmetic these settings feed into, worked end to end with real numbers.
The settings file as actual code, the six verification checks, and how to wire it into a system you already run.
How to use last year's sealed receipts to work out which settings were actually right — without rewriting a single old receipt.