You're looking at a system your team runs and no longer fully understands. Maybe it was generated last quarter and merged faster than anyone could read it; maybe the one person who held it in their head has left. Either way the decision in front of you is the same — change it, rebuild it, or leave it be — and you can't make that decision well, because you can't tell which of the things it does are load-bearing and which are accidents nobody would miss. In a software dev shop that's now the ordinary case, not the exception.
That gap — between what a system does and what anyone can still account for — is the thing Tashika measures. Call it legibility: how much of what your systems actually do is held somewhere you can reach, instead of running unread in production.
Legibility isn't one number, and the single word “debt” hides that it isn't. It has three parts, and they move on their own. How much of a system's behavior is written down somewhere a machine can check. How much survives only as understanding, in people you can still call. How much survives in neither — the behavior something quietly leans on that no test pins and nobody remembers.
Those three come apart in ways that matter. A system can be tested to the teeth and understood by no one. Another can live entirely in one veteran's head with nothing written down at all. Both are dangerous, in opposite directions, which means they call for opposite fixes — and one worried number can't tell them apart. Three readings can.
The first two you can get at with tools that exist, or nearly do. Everything turns on the third: whether a person can still predict what a system will do, find where a change has to go, and say why it's built the way it is. That one goes quietly. Nothing on a dashboard so much as flickers while it drains — and it's the exact thing you need on the day the machine has produced something wrong and someone has to know better. It fails first, and it shows up nowhere. That's the reading Tashika is built to take.
The reading has to be trustworthy, so it comes from a setup with a single rule, plain enough to audit: nothing grades its own homework, and no one artifact is asked to do two jobs that fight each other.
What that buys a team isn't fewer engineers by decree. It's knowing where the engineers have to be. Most of what a large team carries is understanding no one ever wrote down — and a surprising share of it could move into something a machine checks, if anyone knew which parts were holding weight. The instrument shows you that. It moves what it can into the checkable column and names the rest — the residue that genuinely needs a human mind — so you can put people at those few junctures instead of lining them along the whole wall because you can't tell which stretch is load-bearing.
This is the opposite of the loud half of the market, which sells the rebuild: hand us a spec, we'll regenerate the system and throw the old one away. That's the fragile trade. It runs, confident, from a state no one measured, and ships something that passes every test anyone thought to write while quietly dropping the behaviors no one knew to test for. A rewrite isn't the product here. It's something the instrument signs off on now and then — only when the behavior is captured and almost nothing would be lost — and never the reason you came.
Anyone can rebuild anything now. The part worth owning is knowing whether you should — and whether you'd be able to tell if you'd gotten it wrong. Tashika built that part first.