Skip to content

Idea · Product vision and source review; linked implementation evidence

Understand What Changes Before You Change It

CodeGraph connects the intent, knowledge and evidence behind software. Its wider promise is to make every contribution useful to the work that follows.

Published
Updated
Reading time6 minutes
AI governanceData architectureConnected knowledge

The next person or AI assistant joining your project should be able to pick up the reasoning as well as the files. They should see why a decision was made, what supports it, and which parts of the project a proposed change could affect. That is the opportunity behind CodeGraph, and it reaches well beyond code.

CodeGraph began with a practical software problem: helping AI developers find relevant functionality and follow its connections without repeatedly searching an entire codebase. Its foundations include caller and dependency discovery, test-impact analysis and deployment traversal. Those connections provide a starting point for understanding a change; the evidence attached to them determines what conclusions are justified.

CodeGraph’s vision is software creation and evolution: connect what people need to what gets built, find work worth reusing, generate missing implementation, and carry the reasoning forward. That is a larger ambition than answering questions about a codebase. It also offers a starting point for a broader workspace where people and AI can use knowledge with its meaning, history and permissions intact.

A change carries consequences across the project

Suppose a team changes when a data import reports completion. The code is straightforward to find. The consequences may extend to a performance test, deployment guidance, a customer promise and a support procedure. A search for the function name might miss the promise entirely.

The useful connection is explicit: this test measures that completion boundary; this claim relies on that test; this deployment guide assumes that behavior. A change can then identify a set of material for review, with the exact versions and the reasons those links exist.

A product manager should be able to ask which promises need another look. A designer contributes a flow; a customer supplies an example; a specialist defines an operating constraint. A developer needs the affected code and tests. A new assistant needs enough context to contribute without reconstructing every discussion. Each works through a familiar view of the same connected project.

The proposed experience is practical: open a change, see the affected material, inspect its support, and assign the decisions that need attention. An inferred dependency would be visibly different from a verified one. An old test would remain available as history without masquerading as evidence for a new revision.

That understanding should also help create the next implementation. Start with the required behavior, find suitable capabilities across authorized projects, compose what fits, generate what is missing, and validate the result against the requirement. CodeGraph’s construction vision connects discovery to working software while preserving the reasons for choosing one approach over another.

When several people or AI services contribute, their proposals should carry the revision they started from, the intent of the change and its supporting checks. Changes that interact need to be tested together. The aim is more useful collaboration with less repeated investigation and fewer surprises at integration.

The same idea works beyond software

Replace the code change with a revised supplier commitment. Now the connected material is a launch plan, a customer proposal, a delivery estimate and the assistant’s saved project summary. The underlying job is familiar: discover what depends on the change and help people update the right things.

Or consider a research team. A source is corrected. They need to find the conclusions that relied on it, preserve the reasoning that was reasonable at the time, and distinguish those conclusions from ones supported by other evidence. Useful memory includes the conditions under which it should be reconsidered.

This is why the broader product should be organized around work people recognize: projects, questions, decisions and changes. A graph is a useful way to represent the connections underneath. The person using the product should not need to learn graph terminology to get an answer.

Make AI access a decision people can understand

A project assistant may need a supplier’s technical documentation and the delivery plan. It may have no reason to see employee records or private commercial negotiations. Even within a permitted document, sending information to an external model can require a separate decision.

The broader experience we want is simple to describe: choose the knowledge an assistant can use, see the sources behind its answers, and understand what it proposes to retain, share or change. Access to information, permission to send it to a model and authority to accept a change are separate choices. The interface should make them visible in the context of a task.

The user asksThe product should make visible
What can this assistant see?Its permitted project material and the scope of the current task
Why did it give that answer?Supporting sources, versions and relevant assumptions
What changed?Affected decisions and saved context that need review
What will it send or keep?The destination, purpose and authority for export or retention

We are building toward that control through 8DB’s shared evidence and protection foundation. CodeGraph gives it a demanding software workflow: preserve source, intent, proposals and evidence together, then check authority where information is read or a change is accepted. Extending the experience across documents and other kinds of work follows the same design principle.

Let useful work accumulate

Shared folders preserve material. Search helps retrieve it. Source control and issue trackers preserve important development history. Connected knowledge can make the relationship between those records available to the next person at the moment it matters.

The difference we want customers to feel is cumulative progress. A new assistant starts with the right context. A team reuses a capability with its requirements and tests. An improvement reaches the people whose work could benefit, and they control whether to adopt it. A changed assumption brings the affected decisions into view. Each contribution leaves the next person in a stronger position.

This is the combination we are pursuing: connected intent, useful knowledge, evidence, controlled participation and reusable improvements. CodeGraph applies it to creating and evolving software. The wider opportunity reaches research, projects and operational decisions, where the same loss of context and repeated effort occurs. The value grows as authorized work can build on what came before.

To explore a fit, choose one project where people repeatedly explain the same background to new colleagues or AI assistants. Identify a decision, the sources behind it and a change that would force a review. Bring that non-confidential example to us. It is a concrete way to shape a workspace around the knowledge you need to use and the control you need to keep. [1]

Explore the CodeGraph product vision.

Continue the series

Sources

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work

Continue reading

The next layer of the argument.

Engineering note

AI, Evidence & Control

Put Evidence to Work Inside Your Database

Give your AI application a reusable foundation for judging results, tracing changes and controlling access.

5 min readProduct vision and source review; linked implementation evidenceRead article ↗