Reading prose into facts
It turns a paragraph in a board note into a numbered fact, and the passage it read is kept next to the fact so you can check it. Every fact it produces is marked as having come from a model.
How it shows its working
Software that tells a chief executive their largest account is at risk, and cannot say how it knows, is a horoscope. In Counterfirm every figure on every screen can be taken apart until you reach a quoted line in a file you uploaded, or a sentence saying no file said this and here is the default being used instead.
The chain
Press Why anywhere in the app and this is the chain that opens. It is the same chain whether you pressed it on a risk score, a line in the brief, or a sentence in an answer.
A number on a screen. Revenue falls 4.2 percent. This account scores 0.71 for risk. Margin recovers by month nine.
The part of the engine that produced it, in a sentence. Not the source code, the actual causal step: demand responded to price, then contracted revenue repriced only at renewal, then the competitor answered in month four.
Every assumption that fed that mechanism, with the role each one played. Elasticity set how far demand moved. Locked share set how much of revenue could move at all.
One of five origins: read from a document, worked out from other things you uploaded, extracted by a language model, typed in by you, or an industry default. The origin is on the screen as a coloured chip, not buried in a tooltip.
For anything read from a document, the chain ends at the file name, the chunk of text it came from, and the sentence itself quoted back at you. You can read the line that made the software believe your margin is 41 percent.
For anything that came from a default, the chain ends at a plain sentence: no file you uploaded said this, so an industry figure is being used, the band around it is wide for that reason, and here is the document that would replace it.
For network scores
A number out of the engine has one story: the equations, and the assumptions they were fed. A number out of the network has two, because a node is scored partly on what it is and partly on what it is next to.
So the explanation is in two halves. The first half is attribution to the inputs, using integrated gradients: the model is run sixteen times along a straight line from an empty node to this one, and the change in the score is divided among the twenty four inputs. Those parts sum to the score, which is what makes it an explanation rather than a ranking of hunches.
The second half is attribution to the relationships. Each neighbour is removed in turn and the score recomputed. If taking away the segment drops the risk by a fifth, that segment is a fifth of the reason. This is why the explanation can say because of what it is connected to and then name the connection.
Origins
The origin of a number is not decoration. It sets how wide the band around it is, which is how uncertainty in your files becomes uncertainty in the answer instead of being quietly dropped.
| Origin | What it means | Band | What it looks like on screen |
|---|---|---|---|
| Document | Read straight out of a file you uploaded by a rule, with the line kept. | Narrowest | Green chip, and the quote is one click away. |
| Derived | Computed from other things you uploaded. Margin from revenue and cost. | Narrow | Violet chip, with the arithmetic shown. |
| Extracted | Pulled out of prose by a language model, with the passage it came from. | Narrow | Violet chip, and the passage is kept next to it. |
| Yours | You typed it. The model takes your word and says it did. | Narrow | Marked as yours, with the date you set it. |
| Default | Nothing in your files said this. An industry figure is standing in. | Widest | Amber chip, and a named document that would replace it. |
A twin built mostly on defaults produces wide bands, and that is the model being honest rather than being useless. The assumption ledger lists every number by origin so you can see the balance at a glance.
If the software cannot tell you where a number came from, the number should not be on the screen.
That is the rule the whole product is built around, and it is why the network is small, the engine is arithmetic, and the language model is kept out of the simulation.
Where the language model fits
A language model is used in three places, none of them the simulation. Where it is used, it is held to the same standard as everything else. The full page on this.
It turns a paragraph in a board note into a numbered fact, and the passage it read is kept next to the fact so you can check it. Every fact it produces is marked as having come from a model.
The numbers are computed before the model sees them. It writes the paragraph around them and it is instructed to name the assumption behind any claim and to flag anything resting on an industry default.
The question is answered from a numbered list of evidence assembled out of your own twin. Every sentence containing a number has to carry the marker of the evidence it used, and the app counts sentences that do not and shows you the count.
If no language model is configured, Ask still answers. It prints the numbered evidence it found and leaves the prose to you. That is worse writing and exactly the same information, which is the right way round.
Building a product this way is slower and it caps what the software is allowed to claim. A model that has to cite cannot bluff, and a model that cannot bluff will sometimes say it does not know.
The network is twelve units wide rather than five hundred because the attribution of a score to its inputs has to stay readable. The engine is closed form arithmetic rather than something learned end to end because a learned model cannot tell you which mechanism produced the answer. These are real trades and they are being made on purpose.
The point of the Why chain is not reassurance. It is that a finance director can open it, find that margin came from a line in a file that was out of date, replace the file, and watch the answer move. Software that cannot be argued with cannot be corrected, and software that cannot be corrected has no business near a decision about a hundred people.
Because every number knows its origin, the software can count how much of your answer rests on defaults and rank the documents that would fix it. That is what the readiness page is built out of. Explainability and data quality turn out to be the same feature looked at from two ends.
Every assumption, every metric in a brief, every network score and every agent property. Chart axes and counts of things do not, because they are counts of things. If you find a number that matters and has no Why, that is a bug worth reporting.
Then you have found a bad extraction, which is the thing this design exists to make findable. Override the assumption in the ledger and it is marked as yours with the date. The old value stays visible in the history so nobody has to wonder why the answer changed.
Yes. The brief carries the assumptions it used with their origins, and the API returns the full chain for any assumption or score on the plans that include it.
Integrated gradients in sixteen steps, so the parts sum to the score to within rounding. Sixteen steps is a choice: it is enough for the ordering to be stable and cheap enough to compute while you wait.
No. Numbers are computed by the engine and the network before any prose is written. The model writes sentences around numbers it is given, and it cannot write one into the ledger without that fact being marked as model extracted.
The evidence is numbered by the app before the question is sent, and the markers it is required to use refer to that numbered list. The app then counts sentences with numbers that carry no marker and shows you the count above the answer. It is a check you can see rather than a promise you have to believe.
Build a twin from one file and open a chain. Either the quoted line is right, in which case you have learned something, or it is wrong, in which case you have found it in a minute rather than in a board meeting.