Repository custody reconciliation: moving work without losing it
Reconciling custody of a code repository means proving who owns it, freezing a verifiable baseline of everything in scope, moving it by the most native supported route, and then confirming from the actual destination that identity, history and records survived, with a distinct receiver signing off. A copy of the files, a matching title or a total count is not custody. Coesite Operations maintains this as a proposed control procedure for moving the Group's repositories and work records into their living owners.
The source specification carries the status proposed: it is an operating control and a set of receiving conditions, not an enforced mechanism. This article summarizes its method in public terms.
Why does custody need its own procedure?
Organizations that grow quickly accumulate work in the wrong places: personal namespaces, machine snapshots, staging pages, abandoned branches. Consolidating it is risky in three ways. Ownership can be inferred from a namespace rather than verified. Information can be silently lost in a transfer that "succeeded". And the migration can be declared done when only the archive moved, while the useful content never reached an implementation anyone uses.
The procedure's governing idea is stated bluntly: archiving branches is not helpful; the contents that matter must reach living code, and only then should redundancy be deleted. Preservation supports transformation; it does not replace it.
What are the effect classes?
Before any action, classify the actual operation, including its secondary effects.
| Class | What it is | Notes |
|---|---|---|
| Read only | Inspect repository metadata, references, bodies, comments, timelines, reviews, non-secret configuration | An opaque dispatcher is not read-only because its argument sounds observational |
| Source proposal | Prepare bounded changes for the existing review route | Preparation is not publication or deployment |
| Content write | Publish source, reconstruct a work record, add a provenance comment, repair a reference | Needs a specifically authorized destination |
| Custody transfer | Move repository or issue ownership | Verify audience and access consequences, not only admin capability |
| Retirement | Closure, archive, deletion or redirection of a subordinate record | Needs exact authority and verified receiving |
| Security or reserved | Credentials, persistent access, permissions, sensitive disclosure, legal changes | An ordinary migration request does not authorize these |
A timeout or lost response after a write is an uncertain effect. It is not a denial and not permission to repeat the write.
How does the destination-first transaction run?
1. Resolve and compare
Read the current sweep and all concurrent comments, then resolve the exact source work and target owner from current content and owner decisions. Names alone do not settle ownership: science, engineering, operations, group and public-web are separate namespaces. Read both source and destination metadata and compare stable identifiers, not display names. A redirected name can be the same repository; a repository with the expected name can be the wrong one. Search the destination for the original stable ID or a migration marker, not only the title.
Classify the operation explicitly as a repository transfer, a native issue transfer, a reconstructed work-record migration, a history reconciliation or a directory relocation, and never report one as another. If the target name exists with a different identity, or histories diverge, stop. Preserve both histories and recover the owner's merge-or-supersede decision. Do not overwrite, delete, rename speculatively or create another repository to bypass the collision.
2. Freeze a baseline, without pretending it is a lock
Record a read-only baseline of branches, tags and commit ancestry, including pull-request head, base and merge identifiers. A commit identifier and a tree identifier are different identities. Enumerate all pages of issues and pull requests with their original bodies, comments, review submissions, inline review threads, statuses and timelines, keeping authors, timestamps and original identifiers. Where history is inaccessible, record the omission instead of reconstructing it by guesswork. Keep byte digests for text and binary evidence. Never broaden the audience of private material to make an export convenient.
A baseline is not a lock. Re-read heads and versions immediately before each mutation, and use a real compare-and-swap or expected-revision write where the platform supports one.
3. Choose the supported route
For a whole repository, prefer the platform's own transfer when authorized and supported, after proving the destination's identity and the permission and audience consequences. Do not pre-create an empty repository at the target name; that creates the collision. A provider's 202 response is submission evidence only. If native transfer is unsupported, a reconstruction is a new object and must carry explicit mappings from every original identifier to its new one; it cannot satisfy a whole-repository-transfer goal. Content copy is not history preservation.
4. Receive from the actual destination
Read the real destination after the operation, not a local alias. Require the expected host, owner, repository identity, visibility and access result. Verify that all frozen references and their reachable history remain available. Verify the complete inventory of issues, comments, reviews and statuses by stable identifiers and content digests; count equality alone is insufficient. Test the intended readers' access without impersonating them. Repair live references (remotes, submodule files, links in active records, workflow and package metadata) and verify the repaired consumers against the new location. A redirect alone does not prove them.
5. Sync back and close
Supply full content, original and new identities, causal links and conflict records to the receiving system. Distinguish received at the host from received natively: the host may have genuinely received the source while the Group's own typed record system has not, and the procedure keeps an explicit "sync-back pending" state for exactly that case. The overall obligation closes only after a distinct, authorized receiver verifies content by readback and an idempotent second pass produces no duplicate. The producer's own claim cannot count as acceptance.
What are the most important rules in it?
- Integrate before you retire. Independently receive each needed capability, datum, issue obligation and stranded variant through living implementation and ordinary consumer use. History custody alone leaves this step open.
- A matching blob proves little. A historical byte match does not establish current semantic equivalence, a consumer's acceptance or permission to retire.
- No force rewrites or last-write-wins. Peer repositories are reconciled under the owner's explicit decision.
- Missing bindings are recorded, not invented. Where an office or duty binding does not yet exist, the obstruction and the sync-back obligation are recorded in the work record; they are not filled with made-up identifiers, and they are not a veto on separately authorized repair.
- Credentials are never read or re-entered. Only non-secret configuration metadata is preserved.
- Migration receiving never implies implementation, deployment, scientific validity or business-outcome acceptance. Each is a separate receiving.
How does this relate to the receiving ladder?
This is the receiving ladder (how to prove a service reached someone) applied to a repository instead of a website. The same logic holds: source custody is one rung, destination readback another, consumer acceptance another. The procedure also reflects the Group's work method that substantive work is saved in its owning repository, with content and not merely pointers (the operating method).
What limits does the procedure state about its own evidence?
It cites a dated measurement from the forest-reconciliation exercise only as a discovery input, with its omissions kept: a coverage threshold of 20 percent for an "already placed" label, name-only matches explicitly unverified, many repositories not harvested, moving heads observed during harvest, no line-by-line comparison of divergent copies and no test runs. Its authors refuse to promote it to an ownership or receiving verdict. We think that is the right attitude toward any migration inventory.
Is this implemented?
No enforcement mechanism is claimed. The specification is a proposed operations control, a binding to the native office system is recorded as unresolved, and its Git mechanics belong to the Group's engineering counterpart. Treat it as a checklist you can adopt, not as a statement that every migration at the Group has followed it.
Where to go next
Deterministic tools before model tokens · Can an AI agent hold an office? · Red Cup Engineering · the 561 Group