What the system is
The structural answer: the parts, and how they fit. This is what a new developer, a new CTO or an owner who has never had a technical picture reaches for first.
- Product System map A system map is a structured account of what a software system is made of and how the parts relate. What belongs in one, what makes it trustworthy, and how it differs from an architecture diagram. What is a software system map?
- Product Component registry Why a list of components is harder than it sounds, what makes an entry stable across analyses, and why identity — not naming — is the thing that decides whether a registry survives its second update. How do I get a reliable list of everything my system is made of?
- Product Integrations map External services, queues, databases and third-party APIs a system needs in order to function — how to find them, why the list is usually incomplete, and what to do about the parts nobody can confirm. What does my software actually depend on to keep working?
How much of it can be trusted
The part that separates a 1ADK project from a confident-sounding summary. Every claim carries its source, and everything nobody could establish is written down as an open question rather than quietly omitted.
- Product Evidence Every statement 1ADK makes carries the file, line range or configuration it came from. What evidence is, what confidence means, and why a checkable claim beats a confident explanation. How do I check whether a claim about my system is actually true?
- Product Unknowns An unknown is a result, not a failure. Why "not found" is not the same as "not there", how an open question gets recorded and closed, and why a document with no gaps in it should worry you. How do you document what nobody knows about a system?
What it does over time
A picture of a system is only useful while it is still true. These two pages are the argument for why 1ADK is a subscription rather than a report.
- Product Change history Comparing two analyses of the same system gives four different answers — arrived, changed, gone, and no longer confirmed. Why the fourth one is the reason to keep analysing. How do I track how my system's architecture changes over time?
- Product Technical memory Documentation decays because it is written once and maintained by hand. What a technical memory is instead, why it has to be rebuilt rather than edited, and what that changes for an owner. Why does technical documentation always go out of date?
Rather than read about it
The demonstration is a full analysed system — invented, and labelled as such on every screen — rendered by the same pages a customer's own project uses. It takes about two minutes to see whether any of this is for you.