scope
Where the agent may act
The contract names the paths and directories the agent is allowed to touch. Everything outside the declared scope is treated as out of bounds and is rejected at validation time.
The system, described in plain terms
Control surface
A short, honest description of what Latchpoint actually is and what it actually does. This page stays focused on behavior that can be verified from the system itself and avoids absolute claims.
The control loop
Every change passes through the same six points.
None of the steps can be skipped, and none of them happen silently. A failure at any point sends the change back to the previous coherent state.
inagent proposes a change
checkvalidate against the approval contract
decidecontract resolves the change
applyatomic write with post-write verification
recordaudit trail for every step
revertclean rollback on failure
The approval contract
Four kinds of rules, declared up front.
The approval contract is what makes validation a structured decision rather than a judgment call. It declares the agent's scope, permissions, operating limits, and pre-write conditions before the agent runs.
permissions
What kinds of actions are allowed
The contract declares the permitted operations — what the agent can read, what it can write, and what is off limits. Permissions are inspectable rather than implicit.
limits
Operating boundaries for this run
Declared budgets, scope of effect, and run-time boundaries the agent is required to stay inside. The contract is the place these become checkable, not the prompt.
preconditions
State the system must be in
Clean-tree gates, branch state, and other pre-write conditions that must hold before any change is applied. Failed preconditions block the change before any write takes place.
Operating modes
How the contract decides
The control layer is mode-agnostic. The team chooses how the contract resolves proposals: fully autonomous, human-in-the-loop, or a hybrid of the two. The validation, write, rollback, and audit machinery is the same in all three.
autonomous
Policy resolves every change
The approval contract decides every change against declared rules. No human review step. Suitable for routine changes inside well-defined boundaries where the cost of a human gate exceeds the cost of a contract miss.
human-in-the-loop
Reviewer on every change
Every change pauses for a human reviewer. The most conservative mode. Useful for high-stakes systems and for the early phase of any new contract while the team builds confidence in the rules.
hybrid
Auto-approve, escalate flagged
The contract auto-approves routine changes and routes flagged ones to a human — risky paths, large diffs, schema or infrastructure files, security-sensitive areas. The default for most teams running the pattern in production.
Reference implementation default: human-in-the-loop. The autonomous and hybrid modes are properties of the contract pattern; the team chooses per change class.
The write step
Atomic, verifiable, recoverable
atomic
Repository never sits in between
Approved changes are applied using atomic file replacement so the codebase moves from one coherent state to the next without spending any time half-written.
verified
Post-write check on every change
Every write is verified after it is applied. If the resulting state does not match what the contract expected, the change is treated as failed and rolled back.
recoverable
Clean rollback on failure
A failed step rolls the repository back to its prior coherent state. Rollback is part of the system, not an afterthought, and it is recorded in the audit trail.
Out of scope
What Latchpoint does not do
- It does not replace code review or CI. Normal engineering practice continues alongside it.
- It does not invent rules. The approval contract is the source of truth, and the team writes it.
- It does not promise absolute privacy or security guarantees. See Security and Privacy for the actual posture.
- It does not claim compliance certifications unless explicitly documented.
Permissions
Permissions are declared in the approval contract and stay narrow by default. Scope, allowed paths, and allowed actions are inspectable rather than implicit. See Privacy for the current access posture.