Governance and data

Your code stays on your machines. Here is everything else.

For the person who signs off on a tool. Where the agents run, what travels to us and what never does, what is written down, who may approve what, and the things the method does not do. Every line describes what ships today. Where the answer is that it does nothing, the line says so.

Where things run

Your code never leaves your machines

Your code

Stays in your repositories, on your machines

The agents run inside your own Claude Code or OpenAI Codex, on your own accounts, on your own machines. The method reaches each session one step at a time and is never left in your repository. What the work produces lands in your own repository as plain documents, in your git history.

Halfcycle holds no access to your repositories. Where the console points at code it links to your own remote, under your own permissions, and never shows a copy.

Your credential

Never held, never proxied

Your Claude or OpenAI account talks to Claude or OpenAI. Halfcycle does not sit in between, does not hold the key, and cannot spend on your behalf. Sign-in to the console is through a hosted identity service; on Enterprise, through your own identity provider.

What a
check sees

The change under check, and nothing after

Some checks run away from your machine so that they cannot quietly agree with the session that did the work. What is sent for such a check is checked and discarded.

A check that runs off your machine sees the change it is checking, returns its finding, and keeps nothing. Checks on written code run on the seat that made the edit.

What
travels back

The shape of a problem, with counts and timings

When a project goes wrong in a new way, what comes back to us is the shape of it: enough to make a check stronger for every project after, including yours. That is how the list of checks grows from every project the method touches rather than only the ones we are paid to be on, and it is the reason the boundary has to be this strict.

Never your code, never your documents, and nothing about your people's machines or accounts: the method records nothing about a person's own setup, and refuses to write such a thing into a tracked file.

Training

We do not train on your work

Not on your code, not on your documents, not on your conversations with the agents. The checks improve because somebody wrote down what would have stopped a problem, not because a model was fed your repository.

This is a decision written into the product's own rules, not a policy that could be revised quietly. If it ever changed, it would change on this page first.

What is written down

Every phase ends with a record an auditor can read

Each phase closes with a written record held by the service and mirrored into your repository: what was planned, what was built, what was carried to the next phase or dropped and why, every decision with the options that were turned down, every call an agent made without asking, and who approved what, by name. It is frozen when the phase closes and cannot be edited afterwards by anybody, including us.

On Team and Enterprise, an audit log records who invited whom, who changed a rule and when it first applied, and who approved or sent back each phase. Your organisation can read it at any time.

Who may do what

Approval is a person's act, recorded by name

Roles follow GitHub's

Owner holds billing and can delete the organisation. Admin manages members, projects and rules. Write runs the method in the organisation's projects and holds a seat. Read opens the console and holds none. Invites are by email or by link; a link can be revoked and expires on its own.

Scope and close are approved by people

No agent can approve the scope of a phase or close one. Each project names who may, and a second approver can be required. An approval is made in a person's own interactive session or in the console, and the record carries their name.

Your rules only add

An Admin can write a convention, a check or a step that applies to every project in the organisation from the next edit. A rule of yours can tighten what Halfcycle checks. It cannot switch a check off or soften one, and wherever it fires it says where it came from.

Sign-in through your own provider

On Enterprise, members sign in through your identity provider, and leaving your directory removes their access. Where a contract asks for it, the checks that run off a developer's machine run inside your own perimeter instead of ours.

Disclosure

Software built this way is labelled this way

It is built by agents, and we say so

Software built with Halfcycle is written by coding agents on your own account, planned by agents, and checked by agents. We do not describe it any other way, to you or to anyone you deliver it to.

Nothing is checked by its author

Every piece of work is reviewed by an agent that did not write it, and the reviewer is never the same one twice. Checks on written code run on every edit, on every seat, and cannot be switched off by the person editing.

A person walks it before it counts

A phase closes only after a real person, really signed in, has walked the deployed product end to end. The written record of the phase names who did, and under which conditions, so a later change underneath can send it back for another walk.

The record of a phase is the disclosure. It says which agents did what, which checks ran, what they found, and which person signed it off. We would rather hand a procurement team that than a paragraph of assurances.

What it does not do

Three things to keep doing

Scanning and testing for security

Checking your dependencies for known problems, modelling how somebody would attack the system, paying a specialist to try to break in, and running static or dynamic analysis are all real work, and none of it happens here. Keep doing all of it.

Compliance certification

Halfcycle holds no certification and does not certify your product. What it gives an auditor is a record per phase of what was decided, built, checked and approved, by whom. That is evidence, not a stamp.

Performance under load

No load testing, no query analysis, no latency budgets. A plan cannot tell you what a system does with real traffic on it. What carries over is that the shape of the system was decided and written down rather than accumulated.

What the method does about security is narrower and, we think, more useful: the rules about who may do what are named once and cited by name from then on, a path that does not cite one does not pass, anything that lets a missing login succeed quietly is banned from a deployed build, and the final walk is done as a real person on the real product. The method page says where that helps and where it does not.

On an engagement

When our people are in your repositories

Your code is yours

Anything built on an engagement is assigned to you. We keep nothing of it. What we take away is what every project leaves behind: the shape of any problem that got past a person, written up as a check for the next one.

Our people work under your access

In your repositories, through your roles, in your organisation, with your approvers. We do not ask for a service account, a standing token or a copy. When the engagement ends, the access ends with it.

No hourly billing, and a written record

Fixed fee or a quoted price, with the process and the visibility promised in writing. Every phase an engagement touches closes with the same written record your own phases do, so what we did is as legible as what your team did.

The rest of the paperwork

The privacy policy and the terms are the legal form of this page. Questions a procurement or security team asks that neither answers go to hello@halfcycle.ai, and we answer them in writing.