For developers
Inspect the modules, adapt the design, connect systems and review the checks and evidence.
How a change reaches your code.
Gain plans the work, reads before it writes, and shows you every file before the relay writes it unless auto-mode is on.
Approve the plan
Gain splits the request into phases and tasks and names the files each task touches. Nothing is written until you approve the plan or turn on auto-mode.
Read before change
Gain reads the files a task touches before it proposes a change to them. A proposal that rests on no file it has read is marked unproven.
Review each file
Each changed file opens as a diff. Accept it, discard it or ask for a change, one file at a time.
Apply with a restore point
The relay takes a restore point, writes the accepted files and runs your project's checks when shell is on. If a write fails partway, every file it wrote is put back.
The relay works in your project, under your rules.
The relay runs on your computer and carries out every read, write and command Gain asks for.
Commands run in a sandbox
Shell stays off until you turn it on. A command then writes inside the project only, cannot write the .git folder and cannot read masked credentials. A one-off command has no network, and a started process has network only after you run kinsugi network on.
Undo any change
The relay keeps a restore point for every change it writes. The Workspace lists them newest first, with the time each was taken, and restores the one you pick.
Use your own agent
Claude Code can connect to the relay over MCP and answer Gain's Work Mode turns. The relay carries out its file changes under the same rules.
A practical route from business need to working solution.
Kinsugi brings together Gain, an AI partner that helps your team define and develop a solution, and KADE, the platform that assembles software from reusable modules. A module is a small piece of software with a clear job. Teams can combine suitable modules, see where a capability is missing, and add what is needed through a controlled development process.
For developers and engineers: Inspect the modules, adapt the design, connect systems and review the checks and evidence.
What do the software checks actually tell you?
Kinsugi runs automated validators against defined rules for its software and the modules used in a build. Depending on the check, they can look for issues such as structure, permissions, documentation, compatibility or a broken test. A passing result means that specific rule passed at that point in the build. A failed result identifies work to fix before the relevant approval or release step.
Passed 5 of 7
Plain-English example
If a new module changes a customer record, a check might confirm that the required permission is declared and the expected behaviour is tested. The result gives an engineer something concrete to inspect and a reviewer a record of what was checked.
Important limit
A validator count is the number of defined checks, not a quality score, a count of independent security audits, or proof that a finished solution is error-free. Human review, integration testing, security assessment and checks against your policies remain necessary.
Reuse proven parts. Focus effort where you add value.
Kinsugi's composable modules are small, single-purpose pieces of software designed to work together. Reusing an appropriate module can reduce repeated development and give engineers a clearer starting point. When the library does not cover a requirement, Kinsugi identifies the gap so the team can decide how to build and test it. The connections and the final application still need to be designed and reviewed for your environment.
Example: A customer onboarding solution might combine identity capture, eligibility rules, document handling and a human approval step. Your organisation chooses the journey and policy; engineers connect the modules to your systems.