Working as a team, and running outside the workbench

Sharing work across the team

Reading a codebase costs something the first time and nothing after that. Repositories published from one workbench show up for the rest of the team, so someone opening one starts from what the team already knows instead of reading it cold.

You can open a published repository read-only, to see how a finished migration turned out, or fork it and work on your own copy. There are no clone URLs to pass around and no access tickets to raise. The panel fills up as people publish from their own workbench.

Each entry tells you what you need to judge it: the stack, one line on what it is, who published it, how long ago, and how many people are working on it right now. A finished COBOL-to-Java migration with its generated Spring Boot code next to it is more use for the next migration than any document about it.

Watching contracts between repositories

Repositories that are connected to each other watch each other's contracts. When an API, a schema or a contract changes in something you depend on, you see it before it breaks a build.

This works off the same pass, not a notification service. Routes, entities and schemas are already pulled out for every connected repository, so a change to a published shape is a comparison between two analyses rather than something a person has to remember to announce.

It is also what makes the contract lock in a decomposition run worth having. Services generated from one monolith start out knowing each other's contracts, so drift between them shows up as soon as it appears.

Running outside the workbench

The workbench comes first, but the engine is not tied to it. The same runs, the same pass and the same scoring work in three other places.

Because the scoring is fixed and tied to the exact content of the tree, the number a developer sees in the workbench is the number CI works out for the same commit. A dashboard across the whole organisation is the same engine reading the same shards from more repositories.

Where your code goes

One binary. No account, no telemetry, no cloud index.

• The analysis stays in your working tree. The shards are written under .cognidev/ next to the code. Nothing is uploaded to build an index somewhere else.
• The model is yours. You supply the provider and the key. With AWS Bedrock or your own OpenAI-compatible endpoint, the model runs inside your own account.
• It works offline. Everything the pass produces — the views, the generated documentation site, reachability, routes, the governance score — is worked out locally and needs no network at all.
• Local models work through the same OpenAI-compatible option, so a machine with no internet access can still use the parts that need a model.

The sharing described above is opt-in and goes peer to peer. Repositories show up for your team because someone published them from their own workbench, not because a service indexed them.