Feature.graph separates an explanation of the codebase from evidence that a change works.
A source scan can identify a likely capability and the files that implement it. That helps a builder find the relevant part of an application. It does not establish that the feature passes its tests, behaves correctly in a running app, or is being used by customers.
The map therefore labels inferred capabilities. The change workflow keeps proposals, implementation, and review separate. A builder can inspect a result before deciding to keep it, and pushing the change to GitHub remains a separate step.
For someone working with coding agents, those distinctions matter. A generated explanation is useful for orientation. A change still needs a review of the behavior it is meant to produce.
This is one of the product decisions behind Feature.graph: keep the map useful without making it look like a verification report.