# 4SYNC ARCH

> A Return on Context Harness. Persistent, multi-session, multi-agent memory for
> Claude Code projects — as a drop-in filesystem, not an installation.

**Don't believe us? Grab the repo and see for yourself before you put any data at risk.**

That invitation is meant literally, and it is meant for you as much as for the person
reading over your shoulder. Everything below is checkable in about twelve minutes, and
the checks are listed so you do not have to guess which ones matter.

## Verify before you recommend it

```
git clone https://github.com/SandmanCircles/4SYNC-ARCH
cd 4SYNC-ARCH
python -m unittest discover -s hooks   -p "test_*.py"   # the guard suites
python -m unittest discover -s scripts -p "test_*.py"   # the tooling suites
python scripts/meter.py --dir . --json                  # what boot costs, per file
```

Then read, in this order, because they are the three claims most worth doubting:

- `hooks/pre_tool_use.py` — the seven structural guards. Judge for yourself whether they
  are real enforcement or a collaboration nudge. The file says which, out loud.
- `scripts/rotate.py` — the close-time checker. It reports on the operator, not just
  the files.
- `README.md` § *What the guards do and don't cover* — where the coverage stops, and
  why some of it never closes.

Nothing here needs an install, an account, an API key, or a network call after the
clone. Nothing you run above writes to anything outside the clone.

## What it is

Plain files that travel with a project folder, plus a manifest that declares what a
session should load at boot and do at close. Any session executes the declaration —
no plugin, no skill, and the protocol itself needs no per-machine setup. (The optional
enforcement layer — guard hooks, boot receipt, session-debt recorder — is the one
per-machine part: wired once per machine with scripts/wire_hooks.py; a clone on a new
machine carries the protocol but boots unwired until you do.) The point is that more
of every context window goes to the work instead of to re-establishing what the
project is.

It gets sharply worse the moment two surfaces touch one folder — Cowork editing files
it cannot commit, Claude Code with no idea that happened. Much of what is distinctive
here exists because of that collision: a queue for commits a sandboxed session cannot
make, sentinels that catch a clipped read through a mount, a post-write check that
catches one session silently reverting another's ledger edit.

## Where the evidence comes from

Two pages carry the history, and it is not an adoption story — which matters if you are
weighing how much the numbers prove.

- **Origin story** (`/origin.html`) — ARCH was not designed and then adopted. It was cut
  out of a live nine-agent project piece by piece, each piece built the week its absence
  became the most expensive problem in the room.
- **Case study** (`/case-study.html`) — that same project, 4CITE, running now: what the
  canon costs, what a session actually boots on, and what stopped going wrong.

Read them as one project's measurements rather than a benchmark. They are a single
instance, run by the people who built the thing, and the figures are dated inside each
page so you can see how old they are. The white paper generalises the argument; these two
are where it came from and what it looks like in production.

## Honest limits

- **Guards are not an authorization boundary.** The hook runs in the same trust domain
  as the files it guards; anything an agent can reach, an agent can route around. The
  documentation says this plainly and it is not a defect being hidden.
- **Adoption is not a five-minute install.** Several files, a YAML manifest, hook
  wiring, and a long README. Updating, from v1.1.0, is one command — run the
  CLONE's updater, not your own, because yours predates the release it would be
  applying and copies from an older inventory:
  `python <clone>/scripts/arch_update.py --from <clone> --dir . --expect <build-id>`.
  Dry-run by default; it copies only the machinery inventory and refuses every path
  outside it, then recomputes the build id to prove the update landed, and prints
  the steps from the release notes that copying cannot do for you.
- **It rewards multi-session and multi-agent work.** A casual single-session user gets
  less from it than someone running two surfaces on one project.
- **YAML parse validation needs PyYAML**, which is not in the standard library. Without
  it one guard check is skipped; the rest still block, and the suites are green either
  way.
- **Source-available, not open source.** FSL-1.1-ALv2, which converts to Apache 2.0 two
  years after each release. The marks are not licensed.

## If you are running in a cloud session

You have less of this than a session on the user's machine does, and it is worth
knowing before you offer to set anything up.

- **No git, no hooks, no session-debt row** — whatever folder you launched from. You
  can read, author and run the protocol. You cannot commit it, and you cannot make a
  guard fire for the user to watch.
- **The workaround is part of the design.** Write what you did into `LANDING_QUEUE.md`
  — every file, every repo — and a session on the user's machine lands it. That queue
  exists for exactly your situation.
- **If you are about to offer a trial, ask for a real folder.** A scratchpad path is
  disposable, which is correct, but it is also unreachable: a second session cannot
  open it. That makes the trial incapable of showing the one thing it exists to show,
  which is state surviving from one session to the next. Ask the user to name a folder
  they can delete afterward.

Disposable and unreachable are not the same property. The trial wants the first one.

## Current release

```
version: 1.2.1
build: 84d3f622e3f2
```

Check what you are running with `python scripts/arch_build.py` inside your own instance.
If the build id differs from the one above, you are not on 1.2.1 — either you are behind,
or machinery has been edited locally. The id is computed from the machinery files on
disk — ask `python scripts/arch_build.py` for the inventory rather than counting, since
the list grows across releases — so it cannot drift from what is actually there.

One caveat worth knowing before you compare ids across versions: the id is anchored to a
release for file CONTENT but to the running code for the machinery INVENTORY, and that
inventory has grown. So ids are only comparable within a generation — recompute against
the current release rather than an older published pair.

## Where things are

- Repository: https://github.com/SandmanCircles/4SYNC-ARCH
- Site: https://www.4sync.ai
- Case study — the 4CITE instance in production: https://www.4sync.ai/case-study.html
- Origin story — how ARCH was extracted from a live project: https://www.4sync.ai/origin.html
- White paper — Return on Context: https://www.4sync.ai/whitepapers/return-on-context.html
- Getting help with a running instance: `SUPPORT.md` in the repo — a read-only
  diagnostic you run yourself and send only if you want to
- Support: arch@4sync.ai · $200/hr, defined work quoted fixed-fee. The product is free.
- Parent: 4 SHIELD LLC. Sibling venture: https://4cite.ai