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.