From Company Knowledge to Verified Changes

A shared component needs a simpler layout on one screen. A stored procedure needs an extra result field. A report needs to display that field. Each request sounds local until you ask what else depends on the same code.

At Success IT, those dependencies cross Angular frontends, C# services, SQL Server databases, Jasper reports, and legacy Access and VBA workflows. Reading the file you intend to change is only the beginning. You also need to find the callers that expect its current behavior.

CodeGraph helps us trace those dependencies, but it is one part of the system. The larger problem is giving an agent the business context, shared implementation patterns, and verification tools it needs to make a sound change.

Success Brain is the knowledge layer at the top: durable company meaning, business rules, decisions, and cross-product standards. The product repository owns the implementation and its verification. CodeGraph is a queryable projection of structural relationships in that implementation.

These layers meet in the engineering workflow. The agent retrieves relevant decisions, inspects the code and its dependencies, then combines acceptance criteria with affected callers to form a verification matrix. That matrix states what must change and what must remain compatible.

This is a division of responsibilities, rather than a single automatic pipeline. A saved decision does not prove the current code follows it. A graph query does not generate the tests. The agent and reviewer have to connect the evidence and resolve disagreements between it.

Abstractions include both shared implementations and named pattern recipes. The product’s pattern catalogue describes recurring rules with a falsifiable contract, a signature for recognizing instances, and references to actual code. An executable recipe points to its checks: a frontend verifier, a database contract, a static lint, or a backend test.

The catalogue gives the codebase a vocabulary beyond functions and files. Its YAML records where checks live; the existing harnesses execute them. Some recipes remain documented guidance with an explicit reason, so naming a pattern does not mean it is automatically enforced. The catalogue inspected here is product-local, not proof of a company-wide executable pattern library.

Shared implementations give recurring behavior a common home. Consider a small but persistent integration problem: the same line-number field arrives with different capitalization. A shared reader handles the accepted variants instead of making each screen rediscover them.

The current repository contains all three parts of the safeguard. A shared calculator implements the reader. A verification unit calls the actual implementation with the supported field-name variants and an unknown-name edge case. A pattern lint flags new component-local copies and directs them back to the shared implementation.

Each check has a different job. The verifier checks whether the abstraction works for its specified cases. The lint checks for a known way of bypassing it. CodeGraph helps identify callers when the shared code changes. Success Brain is where the durable context and decisions behind such rules belong.

This is also an incremental migration. Some older copies are explicitly allowlisted. Signature lints detect the patterns they are written to find; they cannot recognize every equivalent mistake. The lint registry separates gating checks from advisory checks, so their consequences are explicit.

The frontend includes a verification runner that exercises real code with fixtures and invariants. Its development-only bridge exposes window.__verify, making logic checks available in the running development application. That bridge is loaded outside production.

Results distinguish PASS, FAIL, BLOCKED, and SKIP. An unavailable check is not a successful check. The verification matrix requires an edge-case probe for each unit; where a unit declares mutations, it also checks that those deliberate changes cause the target invariant to fail.

That tests something about the checks themselves: can they detect the mistake they claim to guard against? Coverage still has limits. Some units explicitly record known defects, and a successful suite does not establish that the entire product is defect-free. Browser-visible changes still need the rendered feature exercised; reports still need their output checked.

CodeGraph uses indexers to turn code and database metadata into a shared graph backed by SQLite. Nodes represent objects such as components, endpoints, procedures, and tables. Edges describe relationships the indexers identify between them.

The implementation includes Angular, C#, SQL Server, Jasper, and legacy VBA indexing, as well as a React and TypeScript Azure Functions path. The important work happens at the joins: connecting a frontend request to an endpoint, or a backend database call to the SQL object it uses. Database-qualified identities help distinguish tables with the same name in different databases.

There is still a CLI, but the current service also exposes authenticated REST access and a read-only MCP interface. REST and MCP answers share an evidence envelope: the result travels with source references, freshness information, supported capabilities, and warnings about ambiguity or truncated output.

This is what makes the graph useful as an agent tool. The agent can inspect both the dependency result and the reasons to trust or qualify it.

Our repository instructions make CodeGraph an early step in engineering work. They also require checking the product, revision, freshness, capabilities, ambiguity, and truncation of the returned evidence. Running the query alone is not the whole procedure.

1. Establish the scope. Resolve the object in the intended product and check that the indexed revision is relevant to the checkout.
2. Ask a focused question. Find callers, shared-component consumers, table dependencies, or the structural path through the graph.
3. Read the qualifications. Check freshness and coverage. Investigate ambiguous matches and partial results before drawing conclusions.
4. Plan the change and the checks. Name the callers whose behavior should change and the callers whose behavior must stay the same.
5. Verify against code and behavior. After editing, use an index that matches the code being reviewed, inspect the changed dependencies, and run focused checks on the affected and protected paths. Refreshing or publishing a shared index follows its own controlled workflow.

A stale or incomplete answer should narrow what we claim. It should not turn into a clean bill of health because the query returned successfully. In the service contract, PASS means the question is answerable against current evidence; it does not mean the change is safe. DEGRADED keeps qualifications such as staleness visible, while AMBIGUOUS flags matches that cannot be safely resolved to one product. Source inspection, text search, and tests remain part of the workflow.

Other commands help investigate renames and apparently unused endpoints. CLI commands do not all carry the REST and MCP service’s safeguards. They produce candidates for review. An endpoint with no indexed callers may still have a caller outside the indexed sources.

Shared UI components make the value of this workflow concrete. Suppose one invoice screen needs a more compact totals panel. A component-level change can also alter quotation or purchasing screens that use the same panel.

The frontend instructions pair consumers --show-inputs with a selector search in the source. The aim is to identify both sets of callers: the ones that need the new presentation and the ones that need the existing presentation preserved.

The current code contains this pattern: optional presentation inputs retain existing behavior by default, and verification fixtures mount the real shared totals component for different caller cases. Those checks assert which labels, headings, and dropdowns should be present, and which should be absent.

The graph helps find the callers. The fixtures check their behavior. Together, they turn “this component is shared” into a specific review question: did the intended screen change while the protected callers kept the behavior they rely on?

Reports reveal a different challenge. A Jasper template can consume JSON while the backend selects a stored procedure using a value supplied at runtime. Reading the backend source alone may not reveal which procedure belongs to which report.

The report indexer includes explicit template-to-procedure bindings for this gap. It checks authoritative mappings first, then supports a labelled convention-based fallback. That fallback only links to a procedure that already exists in the graph; it does not invent one from a plausible name.

There is a useful boundary here. A declared report field can establish a JSON key the template expects. It does not, on its own, prove which SQL column supplied that value. Keeping those claims separate makes the graph more useful than presenting every inferred relationship as equally certain.

A graph can be stale. Its indexers can miss a relationship. A dynamic call can be unresolved. A query can stop at an output limit. These are properties of the evidence that need to stay visible when an agent summarizes it.

Even a correctly indexed relationship says little about whether behavior remains compatible. A report can still call the same procedure and fail because its result shape changed. A screen can still render the same component and show the wrong total.

The layers work together by answering different questions. Success Brain preserves meaning and decisions. Abstractions concentrate implementation. Pattern lints discourage known regressions. CodeGraph makes structural consequences visible. Verifiers provide executable evidence for the cases we have defined.

After a change, durable business lessons belong in Success Brain; tests, code-specific quirks, and implementation instructions stay with the product repository. That keeps both the next agent and the next reviewer better informed without asking any one layer to stand in for all the others.

Implementation reviewed on 21 September 2026. Examples are generalized from repository instructions, source, and verification fixtures. They describe implemented capabilities, not a live deployment audit or a new test run.

• Why a Knowledge Management Layer Still Matters - the KM layer that makes "CodeGraph first" a rule agents actually follow.
• Everyone Gets a Jarvis - how bounded agents expand staff capability while people keep authority.
• Work catalogue - the repositories and tools behind these systems.