IntentOS pilot

Give AI-assisted changes a clear contract.

Define what must stay true, what the agent may change, and what evidence your team needs before merging. Happi Hacking helps you test this approach in your own repository.

Discuss a pilot See the worked example

The engineering problem

The patch is becoming the easy part.

Expert attention still goes into establishing whether a change preserves the behavior that matters, follows the right decisions, and carries evidence for the exact candidate under review.

01

The tests have a boundary

A patch passes the existing suite and breaks behavior the suite never examined. Reviewers must reconstruct the missing property under time pressure.

02

The decision lives elsewhere

A policy or architecture decision exists, yet the agent never sees it. The change can be locally tidy and globally wrong.

03

The evidence drifts

A check ran at some point, against some revision. Reviewers cannot establish whether its result applies to the candidate being merged.

The working agreement

A Change Contract makes the important parts explicit.

A Change Contract is a short, versioned agreement about one software change. It connects the specifications, policies, decisions, and tests the team already trusts.

The pilot establishes how your team should define, review, and test one.

Illustrative pilot contract

Internal transfer atomicity

For review
Intent
Make an internal bank transfer atomic under storage failure.
Must remain true
Preserve total funds. Post both ledger entries or neither.
May change
Ledger posting and the tests needed to verify it.
Open decision
What should happen if the audit export fails?
Authority
The accountable ledger owner, with the required approval recorded before landing.
Evidence
Regression tests, generated histories, and injected storage failures.
Identity
transfer-atomicity v0.3
demo candidate 7f3c2a1
Why identity belongs in the contract

A passing result is useful only when reviewers can connect it to the contract version and exact code candidate it evaluated. Establishing that link is part of the proposed pilot integration.

Synthetic research demonstration

Forty passing tests missed a one-cent failure.

In a demonstration banking repository, all 40 existing tests passed. An injected failure between debit and credit exposed a partial transfer. A subsequent Hypothesis experiment reduced the known failure to a single one-cent transfer.

Before

1¢+1¢=2¢

Both accounts balance.

After injected failure

0¢+1¢=1¢

The debit posted. The credit did not.

Expected

1¢+1¢=2¢

A failed transfer leaves both balances unchanged.

The useful move was to state the invariant, then attack it. The generated test harness was built after the defect had been identified. This demonstration is evidence for the pilot method. It is separate from the proposed Change Contract compiler and protected merge integration.

Workflow to establish during the pilot

Keep your engineering system. Add a clearer change boundary.

Your repository, coding tools, CI, and review process stay in place. The pilot connects them around one contract and one candidate at a time.

  1. 01Scope one change
  2. 02Review its contract
  3. 03Implement with the existing agent
  4. 04Run independent checks
  5. 05Review the exact candidate
  6. 06Retain the landed-change evidence

Warrant can link landed changes to intent. Existing approved constraint sources can supply requirements. Adoption does not require buying every Happi Hacking tool.

Authenticated approvals, exact-candidate evidence, contract compilation, and protected merge enforcement are integration work proposed for the pilot.

Proposed pilot

A small enough scope to evaluate properly.

The indicative scope is 4 to 8 weeks. That timing is a scoping assumption, subject to repository access, working CI, clear ownership, and agreed staffing.

  • 01

    One reviewed contract and explicit ownership decisions.

  • 02

    A reproducible check harness for important behavior and failure cases.

  • 03

    Repository and CI integration for the agreed scope.

  • 04

    A reviewable evidence bundle linking decisions, checks, and the landed change.

  • 05

    An evaluation of expert effort, rework, and missed constraints.

Evaluation

Measure whether it earns its place.

The pilot should establish whether the tooling improves on a good existing workflow. Total expert effort includes preparation, maintenance, review, and repair.

Approach Preparation Review Repair and rework Missed constraints
Ordinary agent-assisted work Measured Measured Measured Recorded
Manually prepared contract Measured Measured Measured Recorded
Compiled contract Measured Measured Measured Recorded

The comparison defines the evaluation. It does not assume a result or promise a saving.

IntentOS pilot

Start with one change that matters.

Bring an existing repository, an important invariant, and a representative maintenance task. We can decide whether the scope is specific enough for a useful pilot.

Discuss a pilot