Use cases
Once the system is on the record, these stop being projects
Share how your team works, connect requirements to evidence, and review changes with context from across your system. Find the workflow you need and the capability behind it.
Find your use case
Shared team skills
Maintain the same instructions across repositories
Share a workspace skill, adapt it where a repository needs an exception, and use it from an MCP-connected coding tool.
Requirements traceability
Find requirements that still need implementation or test evidence
Organise requirements into groups and connect them to code and tests. See where links are missing before treating a requirement as covered.
Cross-repository review
Review a change against the services that depend on it
Use the system map to follow a change beyond its repository. Read findings alongside the limits of which repositories the review could access.
Code review
Check a change against the reasons behind the code
Bring recorded decisions and constraints into review. Read findings on the pull request or follow their evidence in Lens.
Context across sessions
Keep the next coding session from losing what you learned
Record decisions, constraints and workarounds beside the code they explain. Let teammates and MCP-connected tools retrieve that context for later tasks.
Issue and pull request triage
Catch duplicate reports before the backlog grows
Compare incoming issues and pull requests with open work. Flag possible duplicates and apply labels from the repository’s existing set.
Self-maintaining architecture record
An architecture record that tells you when it has aged
Read from the manifests your repositories publish, proposed rather than asserted, approved by a person, and marked stale when it stops matching the code.
Contract drift
A spec diff tells you something broke. It cannot tell you who breaks.
A published interface versioned and compared against its baseline, joined to the services that declare a dependency on it, so the blast radius comes with the finding.
Onboarding
Onboarding used to happen twice a year. Now it happens every hour.
A new engineer and a new agent session ask the same questions and neither can read the answer out of the code. Both get it from the same records.
CVE monitoring
A vulnerable package is installed. Does anything here call it?
Advisories from the same database Dependabot reads, then checked against the code graph, so what you never call is not filed next to what you run on every request.
Supply chain naming
Your internal package is called acme-auth. So could anyone else’s.
Every inferred dependency carries how sure SourceAnt is that it resolves to you, which makes the edges resting on an unowned name a filter rather than an audit.
The same graph answers a few more
These do not have pages of their own yet. They are the same traversal with a different question on the front of it.
- Decommissioning, where nothing inbound is the answer you needed
- Audit evidence, where every part cites the file it was read from
- Extension points, where a manifest declares what it plugs into