Knowledge
Knowledge is your organization's map of its own software. It's built from your code, from nullplatform, and from the sources you connect. It records what each application does, what it depends on and how, which norms apply to it, and what your people know about it. Every fact keeps the evidence it came from, and people and AI agents read the same knowledge.
Knowledge is in early release and may not be available in your organization yet. Nullplatform sets it up with your team. If you'd like to try it, reach out to us.
Why it matters
A coding agent, or a senior engineer on their first day, can read any repository in seconds. What neither of them can read is how your organization works. They don't know who calls this endpoint every night, which host is the core banking system of each country, the norm your architecture team wrote last year, or why that legacy service is still running.
People take months to learn that. An agent forgets it at the end of every session, and exploring a single application in depth can cost millions of tokens each time.
Knowledge works it out once, keeps it current, and shares it with everyone. Before you touch something, you can ask what depends on it, what the rules are, and who to ask, and get an answer with the file and line that proves it.
What Knowledge holds
Each application gets a page, and the pages connect into one graph:
| Piece | What it tells you |
|---|---|
| Relations | What each component calls, publishes to, stores in, or trusts, with the operation used (for example, GET /customers/{id}) and the evidence |
| Book and runbook | What the application is and how it works: flows, entities, dependencies, invariants. The runbook covers how it fails, the symptoms per dependency, and what not to do during an incident |
| Facts | Structured facts from the code and from nullplatform: where it runs, what it exposes, how it's configured, who can call each endpoint |
| Norms and know-how | What your organization prescribes and knows, scoped to the whole organization, an account, a namespace, or one application |
| Rules | Identities that apply on every analysis, such as "this host is the payments core in Chile" |
| Open questions | What the code can't answer, asked once to the people who can |
| Findings | Verified bugs, risks, documentation drift, and norm violations, filed as action items |
Where the knowledge comes from
- Your code. Each application is read at the commit of its latest production deployment. The code itself never enters Knowledge: only the facts derived from it and their
file:linereferences do. - nullplatform. Applications, scopes, deployments, and parameters give every fact an exact identity.
- Your other sources. Documentation, a wiki, Kubernetes clusters, or any system a read-only workflow can query, for example a CMDB or an incident tool. Nullplatform sets up the ones you need during onboarding.
- Your people. What only people know enters as answers and know-how, and it's protected from automatic changes.
How the knowledge is built
An analysis reads every source and resolves identities with your rules before any AI model is involved. Then one model investigates what's left open and cites its evidence. A different model rereads the cited lines to verify each claim. When the evidence isn't enough, the claim isn't marked as verified, and what nobody can derive from the sources becomes a question for your team.
Because the answer is stored once for the whole organization, nobody gets asked the same thing twice. Every application it applies to picks it up on its next analysis.
How it stays current
Nullplatform runs your deployments, so it knows when the software changed. Once your organization turns on deploy sync, each production deployment starts a short analysis of only what changed:
- The affected sections of the application's book are rewritten, and the rest stays as it was.
- Findings that the change fixes are closed, and new ones are opened.
- If your documentation is connected, the pages that describe the changed files are flagged for review.
New context starts a focused reanalysis too, for example new know-how, an answered question, or a new source.
What a person wrote is never replaced by an analysis. When new evidence contradicts it, Knowledge opens a suggestion for someone to review instead.
How much to trust each fact
Every fact records where it came from. The application pages show it as a Source label, and the Facets tab shows the exact provenance value:
| Provenance | Source label | What it means |
|---|---|---|
observed:code | Code | Extracted from the code, without AI |
observed:null | nullplatform | Read from nullplatform |
joined | Code × nullplatform | A cross between the code and nullplatform, such as a setting the code reads and the value set for it |
IA | AI analysis | Proposed by a model, not verified yet. Its badge is orange |
IA:verified | AI analysis | Proposed by a model and confirmed by a second model against the cited evidence. Its badge is blue |
human:curated | Other | Written by a person. Its badge is green |
Verified doesn't mean infallible. Each claim links to its evidence so you can check it yourself.
Who uses it
| Who | What they do with Knowledge |
|---|---|
| Developers | Understand an application before changing it, check what a change reaches, and answer the questions only they can answer |
| Architecture | Write norms and know-how, curate the knowledge, and review proposed changes to it |
| Platform and security teams | Work through the findings in action items and spot problems that repeat across applications |
| AI agents | Query Knowledge over MCP before they plan or change anything, with the same context people see |
Get Knowledge for your organization
Nullplatform onboards Knowledge with your team. Together you'll:
- Give read-only access to your application repositories.
- Choose which applications to analyze first, and which of them get findings.
- Connect the extra sources you need, such as your wiki.
- Turn on deploy sync, so the knowledge follows every production deployment.
Related docs
- Explore your software: find an application, check what a change reaches, and read what Knowledge knows about it
- Contribute knowledge: answer open questions, add know-how, and correct what's wrong
- Connect your agents: give your coding agents the same context through MCP
- Action items: where Knowledge files its findings