Skip to content
AIP

Introduction to AIP

AIP preserves the purpose of a change alongside its exact effects and validation:

intent -> operations -> resulting state -> evidence

The reference implementation is a standalone Go binary. Repositories live in .aip/, while your source files remain ordinary files that existing editors, compilers, and coding agents can use. Git is not required or used internally.

What works today

  • Create intents with goals, constraints, and context references.
  • Snapshot files into immutable, content-addressed artifacts and states.
  • Inspect operations, history, object relationships, and file/text diffs.
  • Preserve alternative candidates descending from the same parent.
  • Materialize a state and execute tests against that exact state.
  • Record reported or executed evidence with provenance.
  • Verify canonical objects and their reference graph.

An experimental HTTP development server also supports authenticated local object exchange. It is loopback-only and is not a hosted repository service.

Start here

  1. Build and install the CLI.
  2. Try the first workflow.
  3. Give your agent the workflow.
  4. Read the protocol specification.

Current boundaries

AIP is experimental. Keep independent backups of important projects. Snapshots include all regular files except top-level .aip/ and paths listed in a root .aipignore. List secrets, dependencies, and generated build output there. Unignored symlinks and special files are rejected.

Intent constraints are recorded, not automatically enforced. Reported evidence is a claim. Executed evidence records what actually ran, but execution has your user permissions and is not a security sandbox.

AIPHub is planned. Accounts, hosted public/private repositories, remote synchronization commands, and hosted evaluation are not available yet.