KinLab Cloud // Early access

KinLab for teams

Now the whole team remembers.

Kin keeps a standing map of what your software means and what a change affects. KinLab makes that map shared, so context, review evidence, and agent activity stop living in one developer's terminal and start belonging to the team.

Where the product is
SHARED REPO GRAPH
EARLY ACCESS
REVIEW RECORD
ADVISORY
AGENT ACCESS
SCOPED BY REPOSITORY
PRE-WRITE POLICY
PLANNED

We publish where each capability actually stands. Planned controls are not presented as deployed controls.

What KinLab adds

Separate repositories. One shared understanding.

Local Kin gives one developer a graph of one repository. KinLab extends that record across the people, agents, and repositories that change the same system.

Shared repository graphs

The relationships between a service and everything that calls it usually live in whoever last touched it. KinLab makes the known relationships available to every approved teammate, workflow, and agent, across repository boundaries rather than inside one checkout.

01 // SHARED CONTEXT

Review history that outlives the merge

The reasoning behind a decision usually evaporates when the pull request closes. KinLab keeps the impact a review considered, the gaps it reported, and the context that informed it, attached to the change itself rather than to a thread.

02 // DECISIONS KEPT

Scoped agent access

Approved agents reach the organizations and repositories you name, and no others. The work they produce carries its declared actor and session, so activity stays attributable to something specific. Authorship is declared rather than independently checked, and we say so plainly.

03 // AGENT BOUNDARIES

Readiness

The evidence is either already there, or it is a project.

Software security regimes keep asking for the same underlying thing. Show what the product contains, show what changed in it, show who changed it, and show that somebody looked at the consequences. The European Union's Cyber Resilience Act is the example most engineering teams are being asked about right now.

The expensive part is rarely the security work. It is the reconstruction, going back through months of merged pull requests to assemble an account that nobody was keeping at the time, from commit messages that were never written for the purpose.

Kin keeps that account while the work happens. A change enters the graph with the entities it touched, the actor that produced it, and the review evidence and known gaps that informed the decision. That is the raw material a readiness exercise consumes, held continuously instead of assembled under deadline.

Whether your product meets any given obligation is a determination for you and your assessor. Kin does not evaluate conformity, does not certify it, and does not tell you that you are compliant. It keeps the record that makes the question answerable.

  • Kept as work happens. Changes enter the graph with what they touched, so the account is not reconstructed afterwards from whatever the commit message said.
  • Actors travel with their work. Whether a person or an agent produced a change, the declared actor and session stay attached to it.
  • Gaps stay visible. A relationship the graph does not hold is reported as missing rather than smoothed over, so the record never claims more coverage than it has.
What a change record holdsIllustration
The changeauthorize_paymentpayments-core
What the graph relates to it
authorize_payment
+-- checkout-service
|   +-- submit_order
|   '-- retry_authorization
+-- billing-worker
|   '-- reconcile_ledger
'-- contracts
    '-- PaymentIntent
Who actedDeclared actor and session, carried with the change
What review foundImpact considered, plus the gaps the report gave back
What the team decidedRecorded with the change. Review informs it, people make it.

A worked example of the record's shape, using invented service names. Not live data and not a capture of a real session.

Walkthrough

How one change becomes a record.

Step through what KinLab keeps as a single change moves from edit to decision. Every value below is written into this page as a worked example. Nothing here is live data, a measurement, or a capture of a real session.

Change record walkthrough
Illustration, not live data

Stages of the record

Select a stage
Loading the walkthrough...
What gets written down
Stage detail
Select a stage to read it.

Review evidence is advisory today. KinLab can surface likely impact and preserve what a review found, and the merge decision stays with your team.

KinLab for teams

Bring one repository that already matters.

Tell us which repositories your team maintains, which agents work inside them, and how review runs today. We will reply with fit and a concrete next step. Early access is an evaluation, not a self-serve contract.

Request KinLab access