--- title: "Introduction" description: "What makes a data team great — and where CAT fits into that." url: "https://docs.justcat.it/what-is-cat/introduction/" --- # Introduction The change is ready. Somebody asks the only question that really matters: **can we ship it?** The code was reviewed. The pipeline is green. And still nobody on the data team can say what this change did to everything sitting downstream of it — the staging layer, the lake, the marts, the reports finance opens on Monday morning, and all the business logic living quietly inside them. So the release goes out on a shrug, or it waits another week while two people check things by hand. Neither of those is a process. Both of them are completely normal. Then the same question comes back, in a worse mood: **did we break something?** Usually days later, from outside the data team, about something nobody was watching. ![A data solution shown as layers, with one changed object marked as checked and the whole area downstream of it left unknown.](blast-radius.png) *You changed one thing. And this is all you checked.* ## So what makes a data team great? Not the ones who never break anything. That data team does not exist — and if you have met one, they were not looking closely enough. Great data teams are the ones who can answer both questions: - **Can we ship it?** — yes, and here is what still holds. - **Did we break something?** — yes, this, and here is exactly where. Evidence, on demand, across the whole data solution — not the corner of it somebody happened to think about. That is also the difference between a data team that sleeps and one that does not. Deploying on a Thursday afternoon stops being a gamble. Being on call stops meaning "waiting to find out". Nobody is carrying the fragile parts around in their head over the weekend, because those parts get checked whether anyone is thinking about them or not. Correct figures matter enormously, of course. But correct figures are the result. The job is holding an entire data solution steady while it keeps changing. And that is not a personality trait. It is a practice. Building data solutions is craftsmanship, in the full sense of the word: you build something, and then you check your own work before you hand it over. Software engineering settled this decades ago — write the code, write the tests, run them every time. Data work, for the most part, never picked the habit up. That is the gap. Not skill, and not care. ![Behind every great data team is quality assurance done right.](quality-assurance-done-right.png) One thing worth saying plainly: CAT does not make your data good. Your data team does. What CAT changes is whether that is realistically possible on an ordinary Tuesday, with the people you actually have. Which is the point of everything here. This is not only a toolkit. A data team can learn quality assurance properly and become genuinely good at it — that is what CAT is for, and it is the part we take most seriously. The toolkit makes the practice affordable. Adopting the practice is yours to do, and it is worth doing. And it lands in people, not in software. What a data team gains is not a tool it now owns but a person on it who can prove the data is right — which is the part that stays when the stack changes and when they move on. ## What does testing data actually look like? Less dramatic than it sounds — and bigger than you probably expect. The simple ones are what you would guess. *No customer code appears twice. Every order has a valid status.* Worth having, and easy to write. The ones that change how release day feels are **comparisons** — two things held against each other until they agree: - **A figure, all the way through.** The revenue on the dashboard is the revenue that left the source system — checked through the transformations in between, not just at the two ends, and quite happily with a different technology on each side. - **An incremental load, under the hood.** Not "does last night's load look plausible" but "does it match the source, row by row". That is the difference between a load that looks normal and a load you can prove is right — and incremental loads are exactly where the difference hides. - **What was built against what was specified.** Data solutions get generated from metadata and specifications all the time. A check can compare the design against the reality — today, and again in six months, when it has quietly drifted. A check states what you expect to be true — and from then on it runs, before a release, after a load, every night, whenever you want. It is the same mechanism each time, which is why the same handful of checks covers the quality of the data, the architecture your team is supposed to be building, a migration from old to new, reconciliation between systems, and who is actually able to see which rows. How that check comes to exist is increasingly your choice: - **You write it.** Straightforward, and often the fastest route when you already know exactly what you want to prove. - **CAT Pilot drafts it.** Describe the check in plain language inside CAT Studio and let it write the first version. You review and adjust, which is a much easier job than starting from an empty file. - **An agent writes it.** A CAT test is a few lines of plain YAML sitting in your repository next to the rest of your code — exactly the kind of thing today's coding agents produce and maintain well. The definition is text. So anything that writes text can author it, anything that reviews text can review it, and it lives in version control like everything else your data team builds. However it came to exist, CAT runs it and keeps the record. A test that passed yesterday and failed today is not an opinion in a meeting. It is a fact with a timestamp. ## So what is stopping you? Rarely disagreement. Almost every data team agrees that data should be tested. They do not start because something is in the way — and usually the very first thing is not knowing where to start at all. So, honestly: **"We would not know where to begin."** Almost nobody does. That is the normal state, not a failure — and it is the most common reason testing never gets started anywhere. CAT is opinionated on purpose: it gives you the shape of a test, the kinds of checks worth having, and somewhere to keep them. Your first day is spent deciding which number matters, not deciding how any of this should work. **"Our data cannot leave the network."** It does not have to. CAT runs where your data already lives. **"IT would take three months."** Installation takes about a minute. No admin rights, no infrastructure change, no ticket. **"We have no CI/CD."** You do not need it. If you can run a command, you can run CAT. Plug it into a pipeline later, if you ever have one. **"Nobody here is a data-QA specialist."** Nobody needs to be — there are barely any on the market anyway. Anyone on your data team can pick this up, including the junior who joined last month. **"We do not want another platform to run."** It is not one. A platform is something you adopt, roll out, and then serve for years. A toolkit is something you pick up and use. CAT is a toolkit. > **🐱:** You do not have to test everything. Start with the one number people argue about — the one that comes up in the same meeting every month. One check, one answer, and the argument is over. That is a good first day. ## What changes ![A grid of data test results over several weeks, with failures visibly decreasing over time.](results-over-time.png) *Not a snapshot. A track record.* Your data team stops guessing. You know which problems you have and how big they are, so you can decide what to fix first — and, just as usefully, what to leave alone on purpose. That decision is the part that matters. A check coming back red is information, and information is only worth what somebody does with it. Testing pays off in data teams that are willing to act on what they find — which is a smaller ask than it sounds, because most of what comes back is a ten-minute fix somebody would have made anyway, had they known. You ship a change and say what it did, instead of hoping. When somebody questions a number, you have proof rather than confidence. And the credit lands where it belongs. Your data team is the one delivering data the business can rely on. The testing is simply why that trust is deserved. ## Where to go next - **[Who is CAT for?](/what-is-cat/who-is-it-for/)** — whether your data team is one person or a dozen teams. - **[Why CAT?](/what-is-cat/why-cat/)** — how it differs from building your own or buying a platform. - **[What CAT actually is](/what-is-cat/what-cat-actually-is/)** — the desktop app, the AI assistance, the automation. - **[Test examples](/how-to-guides/test-patterns/)** — real tests, in full, so you can see how little there is to one. - **[Reference](/reference/basics/introduction/)** — how CAT actually works, once you want the mechanics.