---
title: "Project genesis with custody and OKF"
sidebarTitle: "Project genesis"
description: "A reusable initialization and adoption process, with evidence and lessons from the Tekton team."
---

This playbook takes a project from its actual starting state to a team that can
begin the authorized work with a shared goal, engineering policy, knowledge
graph, resource ownership and a truthful account of custody coverage. Use it
for a new project or adoption by an existing project. The [starter
assignment](#assignment-for-the-next-initializer) can be given to another agent.

The worked case is Tekton on **2026-10-11**, from its research-only directory
through the human's instruction to onboard developers and start implementation.
The complete channel was read: **21 root messages and 129 replies across all
10 threads**, captured at **19:33:21 UTC**. This is a dated retrospective, not
a live status page for Tekton. The [source map](#source-map-and-review-boundary)
provides exact retrieval commands and the boundary of the evidence.

The result was **implementation authorized and begun; custody
initialized-limited**. Neither a complete product nor the full custody protocol
was demonstrated. “Pushed to implementation” describes the phase transition:
the project was still local, with no remote publication reported in this cut.

## What the initializer must deliver

Deliver one coherent, reviewable project setup with these properties:

| Concern | Required result |
| --- | --- |
| Goal | One canonical statement of the full user outcome, the first useful result, measurable acceptance and deferred scope. |
| Practice | Engineering rules chosen with the human, with concrete verification, decision and integration methods. |
| Authority | Current instructions, roles, permissions and superseded decisions traceable to their sources. |
| Knowledge | An OKF graph connecting the goal to applicable rules, decisions, resources and evidence. |
| Execution | Actual project/session/worktree/channel bindings, disjoint writers and resource owners. |
| Custody | Observed capabilities and gaps across the complete history and publication path. |
| Handoff | The next authorized assignment, its owner and evidence needed to accept the complete result. |

Preserve this chain throughout initialization and later work:

```mermaid
flowchart LR
  H[Human objective and decisions] --> K[Goal and applicable OKF rules]
  K --> A[Scoped assignments]
  A --> W[Sessions and Git worktrees]
  W --> R[Changes and observed results]
  R --> P[Sender context and publication]
  K --> P
  P --> N[Anchor selection and delivery]
  N --> A
  R --> K
```

The diagram describes the required relationship between sources. It does not
assert that every arrow is enforced by an installed Desk version. Git owns
code state; Channels owns source messages; the human owns their directives;
the project owns its accepted policy; custody records their relationships and
observations. A copied summary cannot acquire the authority of its source.

If `custody-genesis-skill` is installed, read its `SKILL.md` and adjacent
`CUSTODY-GENESIS.md`. The Tekton process used version **0.2.2**. That package
defines the detailed C1–C12 contract, G1–G8 workflow, P01–P74 engineering rules
and versioned Desk adapter. This playbook explains how to apply the process
and improve the handoff; it does not silently revise that package. Discover
its installed location instead of assuming another machine's home directory.
If it is unavailable, the workflow below remains usable, but do not claim
completion of that skill's full rule reconciliation without reading its rules.

Current project instructions take precedence over a reference workflow. Make
material exceptions explicit at the existing policy owner; do not introduce
another approval system or compliance database.

## 1. Discover the project and the current assignment

Read the human's actual request, applicable repository instructions, current
roles and source decisions before proposing a setup. Determine whether this
is a new project, adoption, recovery or a repair of an existing binding.
Separate what is authorized now from possible future work.

Inspect the actual directory. In a Git repository, useful reads are:

```bash
git status --porcelain=v2 --branch
git rev-parse --show-toplevel
git rev-parse --git-common-dir
git worktree list --porcelain
```

Record the baseline commit or explicitly absent HEAD, branch, staged,
unstaged and untracked work, active writers and known other clones/machines.
Do not expose credentials embedded in remote URLs. A local worktree listing
does not discover every clone or prove recovery coverage.

For adoption, retain existing history, identifiers, rules, knowledge paths and
in-flight work. Record an adoption boundary and unknown earlier coverage.
For a new project, do not inherit a similarly named remote, old rules or old
results without a decision making them applicable. Initialize local Git when
authorized; never invent a baseline commit while HEAD is unborn.

For channel-based discovery, read the root and **every relevant thread**.
For genesis or an explicit whole-history review, read all threads. Root output
contains thread pointers rather than the replies themselves:

```bash
desk channels read PROJECT_CHANNEL
desk channels read PROJECT_CHANNEL ROOT_MESSAGE_ID
desk channels read PROJECT_CHANNEL --message EXACT_MESSAGE_ID
desk custody --anchor ACTUAL_ANCHOR_FROM_NOTIFICATION
```

Replace the uppercase markers. Follow any further thread pointers, check for
truncated output, and retain a source cutoff. A notification summary is an
entrypoint, not the full conversation. On a busy channel, reread the owning
thread and current human corrections before taking an action from an old
notification. Routine later changes need the applicable source closure, not
another complete project audit.

**Tekton lesson.** The initial directory contained four research documents and
no Git repository. An agent proposed adopting an older repository with a
similar name. The human explicitly chose a new local project instead, with
another repository only a future integration candidate. The initial mission
also arrived as quotations in an agent's earlier conversation, without the
original message IDs. The team retained that provenance gap rather than
manufacturing primary human sources. See **T1/T4** in the source map.

## 2. Interview for the missing choices

Ask one to three focused questions per round. Give coherent options, a
recommendation and the consequence of each option. Reuse answers and standing
permissions already supplied; do not make the human answer the same question
in different terminology. When methodology is undecided, ask the initial
engineering questions before writing a rulebook or investigating optional
runtime infrastructure.

Use the agreed language and decision surface. Tekton explicitly required
Russian discussion and one thread per topic. That local choice took precedence
over a template that preferred root-level decision requests. Questions must
still be visible to the person who owns the answer.

| Decision topic | Useful options and tradeoffs |
| --- | --- |
| First useful outcome | A complete representative user journey; an existing milestone; a bounded research claim. Specify what remains insufficient even if a component works. |
| Engineering method | Short iterations with targeted behavior checks; design-led changes for material interfaces; complete production execution as the sole behavior evidence. Match rigor to the actual project. |
| Verification | Existing CI and real-path acceptance; an explicitly selected test-first method; production-only execution with named restrictions. Do not combine incompatible rules accidentally. |
| Decision authority | A delegated owner per scope; explicit team consensus; an established review process. Define who can change goals, hard constraints, architecture and budgets. |
| Current action scope | Preparation, implementation, external publication, infrastructure changes, experiments and releases. One instruction can authorize several; distinguish them without asking repeatedly. |
| Source and integration | Retain existing history; establish a new local baseline; connect an approved remote. Choose branch ownership, review, merge and recovery practices. |
| Runtime and resources | Existing assigned resource; an authorized task-owned resource; a proposal pending the missing resource decision. Name spending, placement, concurrency and cleanup limits. |
| Team | The smallest set of independent implementation connections plus integration/domain responsibility. Determine who creates agents and who may assign them. |
| Sharing and recovery | Reader sets, archive destination, retained work, recovery expectations and owner. Access to a service is not automatic consent to publish all captured source material. |

Keep each material decision together with its scope, source, owner, rationale,
applicability and replacement condition. Distinguish `human-decided`,
`existing-policy`, `agent-delegated`, `proposed` and `unresolved`. These are
descriptive labels, not runtime authorization fields.

When using the genesis skill, reconcile **all** P01–P74, including conditional
rules and prohibitions. Group the discussion and record dispositions in the
canonical engineering policy; a 74-question interview or separate tracker is
unnecessary. Do not claim a missing mechanism is conditionally inactive merely
because implementing it is inconvenient.

| Rule group | Coverage to retain when adapting the policy |
| --- | --- |
| P01–P12 | Full goal, human priority, delegated consensus, persistent scoped grants, current sources, proportional reading, tool/mode restrictions, communication and bounded repair. |
| P13–P23 | Complete producer/consumer path, integration ownership, semantic fidelity, canonical implementations, scoped refactoring, atomic contract updates and requested planning. |
| P24–P34 | Permitted verification, complete state transition and recovery, honest scientific evidence, final-source execution, actual measurement boundaries, resources and diagnosed retries. |
| P35–P46 | Publication authority, isolated branches/worktrees, ancestry and authorship, filesystem constraints, integration, overlap, safe retirement, bounded delegation and founding review. |
| P47–P60 | Fact owners, OKF profile and lifecycle, applicability, ordinary capture versus elevated journal, triggers, stable transactions, new/adopted history and demonstrated journal capability. |
| P61–P68 | Conditional frozen-candidate integration, exact evidence, collisions/retries, closure, edited authority, secret incidents and recovery from observed state. |
| P69–P74 | Dependency ownership, data/artifact admission, truthful trust, completion evidence, concrete founding acceptance and maintenance through canonical owners. |

The grouping is an interview coverage map, not a substitute for those full
rules. Existing policies may retain, adapt, explicitly except or conditionally
deactivate a rule; record the source and activation condition. Leave genuinely
unresolved choices visible.

**Tekton lesson.** The human selected production-only behavior verification,
forbade unnecessary validators, guards, tests and governance, delegated team
consensus, and limited escalation to significant architecture changes. The
team correctly adopted those answers instead of its original recommendation.
These choices belong to Tekton; they are not universal requirements for the
next project. Requested genesis documentation remained in scope. **T2/T3/T4a**.

## 3. Establish one goal and a usable acceptance contract

Write or reuse the canonical goal early, before detailed planning creates
competing copies. Preserve the full mission alongside the first achievable
result. A narrow first scenario must not erase the rest of the requested
system. Conditional later integration stays conditional.

A useful goal document answers:

1. Who supplies the real input, and what complete result do they receive?
2. How does the next operation consume the result, including saved state and
   recovery where required?
3. What is the first complete scenario, its assumptions and explicit limits?
4. What constitutes success, failure and insufficient evidence?
5. Which acceptance thresholds are agreed, which remain open, and who may
   change them?

For each KPI, specify the quantity, units, population/denominator, conditions,
threshold, observation boundary and acceptance owner. Include unsuccessful
attempts and end-to-end cost. Separate a chosen target from a measured result.
Names such as “robust,” “large” or “accurate” need an observable interpretation.

For research, choose comparisons and data splits before evaluating results.
Separate acquisition from data admission, synthetic labels from independent
evidence, and source-informed transfer from a blind holdout. Retain negative
and incomplete results. Resource arithmetic should expose infeasibility early;
it cannot justify dropping inconvenient cases after seeing their outcomes.

**Tekton lesson.** Historical reports showed a benefit on one class of physical
failure but not on all failures. The team therefore required multiple repair
locations, comparable complete budgets and all failures in the denominator.
It inspected candidate datasets instead of treating a file called “mesh” as a
usable engineering input. A JSON result could not be linked to the selected
calculation input, so it was not promoted to ground truth. The agreed numerical
formulation became an accepted, unexecuted definition of what to implement;
its acceptance did not establish numerical accuracy.

The first evaluation plan implied at least 4,608 neural requests. A 36-hour
allocation allows 28.125 seconds amortized per request before additional
comparisons; 600 seconds on every sequential request would require 768 hours.
Recording this prevented a latency ceiling from masquerading as a feasible
schedule. An incomplete series would remain inconclusive. These numbers are
case evidence, not defaults for another project. **T5**.

## 4. Give each fact one canonical home

Reuse equivalent existing documents. A compact new-project arrangement is:

| Artifact | Owns |
| --- | --- |
| `GOAL.md` | Full outcome, first result, acceptance criteria and limits. |
| `docs/architecture.md` or existing design | Mechanisms, interfaces, domain assumptions and experiment method. |
| `docs/engineering.md` | Adopted engineering practice, authority, integration and recovery rules. A small project can keep its OKF profile here too. |
| `AGENTS.md` | Concise operating entrypoint and links to those owners. |
| `knowledge/index.md` | Navigation into the knowledge bundle. |
| `knowledge/genesis.md` | Objective provenance and applicability, pointing to the goal owner. |
| `knowledge/engineering.md` | Concept binding to the existing engineering policy. |
| `knowledge/format.md` | Pointer to the one format/profile owner and its selected version/digest. |
| `knowledge/custody.md` | Binding contract, dated capability evidence, gaps and next owners. |

Git remains the live owner of checkout state; Channels remains the owner of
assignments and source decisions; execution stores own actual run evidence.
Do not create parallel manually maintained worktree, task, role or event logs.
Add further concepts only for distinct scope or authority that the project
needs. A small bundle does not need a forest of empty directories.

When moving a contract, replace normative duplicates with links in the same
change. Preserve historical sources and supersession. Updating a document
digest without updating its actual bytes, or vice versa, leaves a misleading
binding. Date evidence explicitly: a historical “no HEAD” observation must
not be read as the current Git state after implementation starts.

**Tekton lesson.** GOAL.md became the sole owner of numerical criteria;
architecture retained formulas, data and experiment method. Genesis linked
GOAL instead of copying it. Establishing that ownership earlier would reduce
later migration work and opportunities for competing edits. **T6/T7**.

## 5. Build a small, traversable OKF graph

Pin the specification and the project's profile. Tekton used [OKF 0.2 at
58b3370](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/58b3370fa848460b825ce1b7da613b19c5869d35/okf/SPEC.md).
Concept identity is its bundle-relative path without `.md`; a concept has
YAML frontmatter with `type`. `generated` is one mapping, `sources` is a list,
and `verified` records actual verification. Preserve unknown types/fields.
The reserved `index.md` and `log.md` are not ordinary concepts. Additional
required metadata and vocabulary belong to the chosen project profile.

This **illustrative** `knowledge/genesis.md` links canonical owners. Replace
the actor, timestamp and source with actual facts before use:

```yaml
---
type: Objective
title: Project genesis
status: draft
generated:
  by: example-agent/1.0
  at: "2026-10-11T10:00:00Z"
resource: ../GOAL.md
applicability: [engineering.md, format.md, custody.md]
sources:
  - id: actual-genesis-decision
    resource: https://example.org/actual-decision
---
```

The body explains scope and provenance and links the real design. Each named
concept must exist and point to its actual policy/resource. A root index for
this profile declares `okf_version: "0.2"` and provides navigation. Do not
invent `verified: human:...` because an agent reviewed the package.

`applicability`, `depends_on`, `authority_refs`, `active_gate`, `superseded_by`
and `resource_digest` are **Desk/project extensions**, with semantics owned by
the adapter/profile. Ordinary navigation does not assign work or make a rule
applicable. Confirm the actual traversal reaches required concepts, canonical
resources and their exact versions. An external source URL is a declaration;
it does not prove that Desk fetched it or that the agent read it.

Validate metadata shapes as well as reachability. A permissive parser can
preserve invalid provenance without identifying the error. Missing required
targets, exhausted traversal limits and ambiguous relationships must remain
visible. `status: stable` describes the standing of a concept, not achieved
KPIs or runtime readiness. See [project custody
configuration](configuration.md#project-custody-and-genesis) for current
selection and traversal limits.

## 6. Bind the installed runtime and verify the recipient

Inspect the intended Desk instance, manifest and installed implementation.
Use supported project editing and preserve all unrelated projects, groups and
durable sessions. Do not restart a shared instance or replace its manifest as
a shortcut. A `desk init` invocation is not custody initialization.

This is a **partial project entry**, not a complete manifest:

```yaml
custody:
  repositoryId: example/stable-project-identity
  channels: [project-development]
  genesis: [knowledge/genesis.md]
  knowledgeRoots: [knowledge]
```

Choose a new stable repository identity once, or reuse the existing one.
Do not copy Tekton's UUID, channel or session names. `repositoryId` is not
automatically a GitHub database ID or a runtime-issued anchor. Roots select
where concepts belong; genesis selects traversal seeds, not every file under
those roots. Observe actual runtime-issued IDs rather than inventing hashes.

Bind each participant's actual project, durable session and checkout. A
channel can contain agents from different projects. A Desk maintainer in
the room may correctly receive an unbound Tekton genesis. Conversely, one
successful recipient proves nothing about newly added developers or worktrees.
After those are introduced, verify their effective bindings separately.

Use a substantive, already-authorized message/assignment to observe ordinary
delivery; do not create acknowledgment loops. Read the recipient's actual
anchor. Check repository identity, checkout, source versions, applicable
rules, coverage and diagnostics. Distinguish **Recorded context** from
**Current context**: a later correction must not rewrite the earlier record.
Reading an anchor is neither a delivery receipt nor proof of comprehension.

Rollback of a binding uses the supported project edit; `custody: null` removes
that binding. It does not delete Git, concepts or historical records. Preserve
previous configuration and unfinished operation state for recovery.

**Tekton lesson.** The supported project edit returned HTTP 200. A subsequent
ordinary delivery to `codex` contained a bound genesis with 10 nodes, 28
relationships and `complete: true` for `reachable-okf-and-direct-resources`.
This demonstrated selected working-tree capture even without HEAD/index.
It did not establish sender enforcement, all-worktree recovery or complete
project history. The other initial agent belonged to Desk and remained
unbound to Tekton. **T4**, historical anchor in the source map.

## 7. Assess the complete protocol, not just the graph

Separate four facts: **required**, **configured**, **observed**, and
**accepted**. Record capability results as passed, failed, blocked or not-run,
with their scope and evidence. Optional features can be not-applicable with
a reason; an absent required capability remains a gap.

Use these readiness terms consistently:

| State | Meaning |
| --- | --- |
| `draft` | Decisions/setup are incomplete; no readiness claim. |
| `initialized-limited` | Useful setup exists; required capabilities are missing, inactive or unverified. |
| `ready` | Every required capability has current evidence for the declared scope. |
| `degraded` | Previously established coverage or validity has been lost; identify affected work and recovery. |

The following is the minimum coverage map for a full custody claim. It also
states what the Tekton genesis actually established at the reviewed boundary.

| Contract area | Evidence needed for another project | Tekton evidence/limit |
| --- | --- | --- |
| C1 — Source ownership | Exact source versions and relationships, stable identities, visible omissions. | Selected local OKF/resources and channel context observed; not an exhaustive source inventory. |
| C2 — Worktrees | Every participating tree: HEAD, index, working/untracked state, owner and unavailable nodes; recovery scope separate. | Initial single checkout observed. Three worktrees created at implementation start; full capture of all three not demonstrated by the founding observation. |
| C3 — Authority | Current human/delegated decisions, scope, supersession, effective roles and identity strength. | Decision sources and corrected roles retained. Authenticated operator/agent boundaries not proven by a handle. |
| C4 — Execution lineage | Objective/task/assignment through session, generation, worktree and accepted result; native child identity when used. | Human-created sessions and assignments visible. Native lineage and end-to-end acceptance not qualified. |
| C5 — Knowledge | Applicable closure reaches canonical policy; behavior and knowledge updates stay coherent. | Documents cross-reviewed and linked; historical binding/digest evidence recorded. |
| C6 — Sender publication | Fresh applicable context exposed to the sender and validated before durable visibility on every write path. | Missing in examined Desk; [#204](https://github.com/BrainyBlaze/desk/issues/204). |
| C7 — Notification anchor | Deterministic selection from verified scope/metadata; explicit ties, path and resolver version. | Recipient anchors observed; universal nearest-anchor behavior not demonstrated. Provider backlog defect [#206](https://github.com/BrainyBlaze/desk/issues/206) also affects timely context. |
| C8 — Git/tracker | Real native identities, incoming reconciliation and authorized outgoing effects without duplication. | Local Git only; bidirectional GitHub/Projects not established. |
| C9 — History/recovery | Durable capture, one logical writer, verified off-node records/payloads, restore to a new destination. | Local custody archive; no verified remote archival/restore result for this setup. |
| C10 — Continuation/control | Bounded launches/concurrency, observable scoped Stop/resume, no replay loops. | Conversation-level stop and later start sources exist; machine-enforced control was not tested by that exchange. |
| C11 — Trust/access | Effective caller/read permissions, protected secrets and explicit evidence strength. | Node observations must not be confused with provider signatures or human authority; [#184](https://github.com/BrainyBlaze/desk/issues/184) is a related boundary to recheck. |
| C12 — Reconciliation | Rerun without duplicate IDs/history, recover changed bindings and retain useful work. | Not a complete replay/recovery qualification. |

### Publication is a distinct boundary

The required order is: resolve sender and work scope → retrieve/deliver its
applicable context → compose the draft → revalidate relevant freshness and
identity → atomically retain message revision and provenance → resolve the
notification anchor → deliver recipient context.

Check valid publication and negative cases: absent or fabricated proof, wrong
session/project/generation, relevant rule changed after preparation,
incomplete sources, edits/share/direct RPC, and crash/retry. Unrelated source
changes should not force a global restart. Preserve drafts and existing
idempotency. Human instructions and Stop must remain usable during degraded
agent context. These are observable requirements, not permission to invent
an API field, a `custody prepare` command or a local bypass wrapper.

At the reviewed Desk implementation, recipient context was prepared after
message persistence. Voluntary reading, a reminder, a signed package or
`traversed: true` in a request could not establish the missing sender gate.
Issue #204 documents the actual write paths and reproductions. Recheck the
installed build and current issue before treating that historical gap as
present or fixed. This playbook does not implement a fix.

### Verification must match the chosen engineering method

Exercise supported real boundaries with authorized, reversible operations.
If the project permits isolated fixtures, keep them away from live team
traffic and resources. If it requires production-only verification, do not
smuggle a prohibited harness into the task. A behavior that cannot be safely
exercised stays not-run or blocked; a schema check cannot replace it.

For selected remote features, establish actual repository/Project identities,
field owners, allowed readers and outgoing effects. Verify missed/out-of-order
input, duplicates and an unknown outgoing result under the same operation ID.
A successful direct `gh` mutation is not proof of managed custody routing.

For archive/recovery, establish one logical writer, retained outboxes and
verified remote records **and payloads**. Check relevant staged/untracked,
ignored-file, LFS and submodule coverage. Restore to a new destination using
the archive with the fixture source unavailable; do not destroy the real
project. Writer transfer needs fencing, not a UUID edit. Follow the installed
[journal and peer contract](configuration.md#custody-journal-and-peer-transport).

Automatic custody capture and an optionally adopted protected OKF governance
journal have different jobs. Do not invent a handwritten `knowledge/log.md`,
`okf-journal` or frozen-candidate procedure to fill runtime gaps. If such a
procedure is selected, qualify its append, concurrency, protection and
recovery behavior; a created ref proves none of them.

Missing full-protocol coverage prevents a `ready` claim. It does not cancel
independently authorized product work. Hold only actions that actually depend
on the missing capability, identify the implementing owner, and continue the
useful permitted work.

## 8. Form the team around real implementation connections

First identify the full path and its currently missing producer/consumer
connections. Assign owners, not just titles. Each bounded assignment includes
the parent objective, exact write set, interfaces, dependencies, authority,
acceptance and next integration owner.

Useful functions include integration/priority ownership, domain or scientific
reasoning, and implementation of independently ready connections. Combine
functions when one agent can do them effectively. Keep a separate protocol
maintainer only when it has a real assigned job. Do not infer that an existing
custody agent should become a product developer or scientist.

The operator's actor restrictions are binding. If the human will create
agents, publish the proposed responsibilities and wait for those actual
sessions. A role description is not agent creation. Once created, match
handle, durable session, project, checkout and effective role/functions;
confirm in real recipient context. A chat reminder alone does not configure
the roster or prove native execution identity.

This is a reusable concise reminder; substitute the actual scope:

```text
Role: <function and complete outcome it serves>.
Goal/authority: <canonical goal and current source assignment>.
Own: <exact files/resources and producer/consumer connection>.
Coordinate with: <interface and integration owners>.
Method: <chosen verification, resource and history rules>.
Boundaries: <actor restrictions, later phases, escalation conditions>.
Custody: read current source decisions and applicable context; preserve
provenance, update affected knowledge with behavior, expose coverage gaps.
Report: delivered behavior, actual evidence, limitations and next owner.
```

**Tekton lesson.** Successive proposals incorrectly assigned the Desk
maintainer scientific/product work and omitted dedicated developers. The
human settled **four total agents**: two developers, `codex` combining
Scientific + Team Lead, and `codex-2` limited to Desk/custody analysis and
remote issue documentation. That correction was an actor restriction, not a
request for more consensus. Four agents, their handles and their domain
specializations must not be copied automatically into another project. **T7**.

## 9. Hand off ownership safely and start only the authorized phase

Read the latest owning thread and Git state immediately before writing.
Announce potentially overlapping work. Once another writer has claimed a
resource, coordinate one owner; unilateral competing claims do not resolve
ownership. A file changing between reads is a collision alarm.

On collision, stop writes to that resource, disclose the actual current
version and unfinished commands, and let one named owner reconcile it. Do
not overwrite, reset or delete the other version to make the tree clean.
Avoid reciprocal ownership transfers in queued messages: name one final
writer and an explicit handoff point.

Before concurrent code writing, establish a permitted baseline and isolated
attached branches/worktrees with disjoint write sets. Preserve authored
history under the adopted integration policy. Do not invent human authorship
when Git identity is missing; resolve it consistently with project policy.
Give the shared environment, expensive processes and integration one owner.
Do not operate another owner's cloud resources.

Onboard each implementer with the goal, current authority, applicable rules,
actual checkout/baseline, bounded assignment, interface contracts and a
current custody context command. Agree on semantics, units, state identity,
failure, persistence and restoration between producer and consumer before
dependent implementation. An API shape alone is not a completed connection.

Keep these phase statements distinct:

| Statement | What it establishes |
| --- | --- |
| Architecture/KPI accepted | The agreed target and method. |
| Implementation authorized | Permission to perform the bounded implementation and necessary ordinary mechanics. |
| Source integrated | Compatible source history reached the chosen integration branch. |
| Application executed | A named path actually ran on the stated inputs/environment. |
| Outcome accepted | Required evidence supports the actual goal or milestone. |
| Custody ready | Required protocol capabilities were demonstrated for the stated deployment. |

Reuse valid implementation authority through ordinary corrections and
integration. Do not add a ritual approval after every step. Conversely, a
request for research, genesis or role reminders must not expand itself into
implementation, experiments or remote publication.

**Tekton lesson.** An architecture/rules discussion was misread as permission
to implement. Five unexecuted draft files appeared; the human stopped the
work. Those files were preserved and disclosed. Only the later instruction
to onboard Dev1/Dev2 and officially start implementation supplied the next
phase's authority. The lead then assigned disjoint files, made local baseline
`52918670357b7784bc59a5c49df2c5f211d0283e`, and created separate development
worktrees. CPU package import was reported separately from the unrun GPU
evaluation. The human's later standing Runpod instruction also required
respecting pod ownership; it did not make another agent's pods available.
**T5/T7/T8** and root resource instructions in the source map.

## 10. Close genesis with one useful handoff

Review the concrete package once for contradictions, omissions, duplicate
owners and unsupported claims, under the chosen workflow. Where an
independent founding review is required, use an authorized reviewer or the
human; a writer's self-check is not independent review. Fix findings and
check the corrections without reopening settled decisions. If the required
review is unavailable, record that limitation honestly.

The handoff should fit in one substantive message with links to the actual
files and evidence. Use the existing canonical record for the detail:

```text
Goal and first outcome: <canonical links>.
Authority and decisions: <current sources; superseded decisions retained>.
Delivered setup: <rules, OKF, effective bindings, baseline/worktree owners>.
Observed evidence: <build/source cut, commands, recipient, results/receipts>.
Readiness: <draft | initialized-limited | ready | degraded>, exact scope.
Gaps: <required capability, impact, next owner/action; not-run scenarios>.
Current phase: <what may start now, based on which instruction>.
Next assignment: <complete connection, owner, dependencies and acceptance>.
Recovery: <saved config, retained state, known unfinished operations>.
```

Do not turn the handoff into a second live status registry. On resumption,
read current source decisions and Git/runtime state; reconcile changed
bindings without recreating identities, keys, channels or history. Update
only affected rules and evidence. Keep protocol maintenance tied to real
team needs.

## Failures to avoid, with the corresponding improvement

| Observed failure or limit | Improvement for the next genesis |
| --- | --- |
| A similar repository was initially assumed to be the project's history. | Determine new versus adoption before attaching a remote or importing policy. |
| Source quotations lacked primary message IDs. | Preserve useful content with its actual provenance; do not relabel an agent source as human authority. |
| Detailed research preceded a canonical GOAL file. | Establish one goal owner early, retaining unknown thresholds instead of fabricating them. |
| Detailed dataset/numerical discussion occupied much of the genesis conversation. | Do only the discovery needed to make the first outcome and acceptance executable; keep domain formulas at their owner rather than expanding custody into a second research project. |
| A summary and a lead's announcement widened planning into implementation. | Resolve current assignment scope separately from agreed technical choices; preserve the human's stop and later authorization. |
| Two agents wrote GOAL.md; later handoffs crossed in the queue. | One announced writer, current-state check before mutation, immediate reconciliation and one explicit final handoff. |
| An unrelated maintainer was assigned product responsibility; developer roles were initially missing. | Start from necessary implementation connections and explicit actor restrictions, then publish one current roster. |
| Role corrections reached agents late and stale role links were briefly written. | Read current owning sources before dependent writes; reconcile active normative links while retaining old sources as history. |
| Agents emitted repeated “already handled” statuses for old notifications. | Resolve the backlog once against current decisions. Do not answer pure acknowledgments or generate work from obsolete requests. Report unchanged blockers only when evidence changes. |
| Recipient graph coverage risked being read as full protocol readiness. | Name recipient, source cut and tested boundary; retain initialized-limited until the full contract has evidence. |
| Baseline evidence became stale after commit/worktree creation. | Date observations and query Git/runtime for live state; verify newly introduced worktrees and recipients. |

The delayed notifications were also a **confirmed Desk defect**, not solely
a conversational mistake. In the live delivery records, an 18:48 message was
submitted to the recipient at 19:09 (20m56s), and the human's 18:58 role
correction at 19:13 (14m51s). Provider-pending submissions escaped Desk's
digest aggregation; stale-delivery wording was prepared before the wait at
the provider. An isolated production-engine reproduction retained three
individual provider submissions while Desk's queue depth was zero. Existing
25 targeted tests passed, showing their coverage did not catch the behavior.
[#206](https://github.com/BrainyBlaze/desk/issues/206) contains the witness,
source analysis and acceptance criteria. It was documented, not fixed by
genesis. It does not excuse missing a prior claim in the current thread or
prove every collision was caused by the queue.

For a newly observed protocol defect, reproduce the actual team conditions,
check existing issues, and document expected/actual behavior, exact build and
source, evidence, impact and a falsifiable correction criterion in the
authorized remote. Do not patch another team's product as a side effect of
protocol QA, or make that investigation block unrelated product work.

## Assignment for the next initializer

Fill in only the facts already known. Leave real questions for discovery and
the interview; do not copy the Tekton answers into the new project.

```text
Initialize or reconcile custody and OKF for <project/path>, using Desk's
“Project genesis with custody and OKF” playbook and custody-genesis-skill
if installed. First discover whether this is a new project or adoption.

Parent objective: <the user's actual complete outcome, or ask if absent>.
Authorized now: <current assignment and existing standing permissions>.
Coordination: <owning channel/direct conversation, language, human owner>.
Known instructions: <actual repository instructions and source decisions>.

Read the existing project and full genesis/decision conversation before
adoption. Preserve history, dirty work, identities and actor restrictions.
Ask small rounds of missing engineering questions with options. Reuse
existing answers; make delegated choices without repeated approval.

Establish one canonical goal/KPI owner, engineering policy and minimal OKF
graph. Reconcile the complete skill rule set when applying that skill;
record scoped adaptations without copying policies from another project.
Bind the actual runtime, sessions, recipients and worktrees through
supported operations. Verify observable custody behavior and disclose
missing sender enforcement, identity, archive or recovery capabilities.

Coordinate one writer per resource. Prepare concrete files and config
before requesting any missing action authority. Do not infer authority
to start product implementation or experiments from planning acceptance;
do not ask again when that authority has already been given.

Finish authorized setup, obtain the chosen bounded founding review,
report readiness at its demonstrated scope, and hand off the first
authorized complete-path assignment with owners and evidence criteria.
Continue useful work despite unrelated protocol gaps; never call the
full protocol ready without its evidence.
```

## Source map and review boundary

The following thread IDs locate the **entire** reviewed conversation, not
just selected supporting replies. Dates/times are UTC. Commands operate on
the owning Desk Channels home; these local message IDs are not globally
portable GitHub links. This document contains the reusable conclusions, so a
new project does not need access to Tekton's channel or research files.

```bash
desk channels read tekton
desk channels read tekton ROOT_ID_FROM_TABLE
desk channels read tekton --message EXACT_SOURCE_ID
```

| Key | Root ID | Replies in the captured cut | Subject |
| --- | --- | ---: | --- |
| T1 | `msg-20261011-110130-0765a94c6068` | 10 | Initial instruction, source provenance, natural-language correction. |
| T2 | `msg-20261011-110717-4aa25bba4866` | 5 | Engineering and production-only decision. |
| T3 | `msg-20261011-110720-8fb9509186da` | 4 | Framework boundary and delegated consensus. |
| T4a | `msg-20261011-111452-570b37ea69c6` | 6 | Authority, consensus and proportionate governance. |
| T4 | `msg-20261011-112254-0c2b3b1ef727` | 17 | New/local project, conditional integration, founding review and actual binding. |
| T5 | `msg-20261011-113409-cc8662e21c85` | 27 | First scenario, data investigation, numerical/acceptance/resource decisions and stopped implementation. |
| T6 | `msg-20261011-161843-dac78c922411` | 3 | Consolidation and full-system engineering directive. |
| T7 | `msg-20261011-184711-d35f9a489be2` | 39 | GOAL, collisions, role corrections, onboarding and delivery defect. |
| T8 | `msg-20261011-192001-b4ddb7555871` | 17 | Authorized implementation, interfaces, local baseline and worktrees. |
| T9 | `msg-20261011-192933-bb16979828cc` | 1 | Request for this retrospective and its ownership announcement. |

Important authority transitions are individually retrievable:

| Source ID | What it establishes |
| --- | --- |
| `msg-20261011-110854-5fb1a9279e04` | Agent-transmitted quotations of the original missions; original human IDs unavailable. |
| `msg-20261011-110913-9eee772bbf9f` | Human selection of method B and prohibition of unnecessary meta work. |
| `msg-20261011-111002-cd7657bb2168` | Human removes mandatory DesignProposal; natural-language input. |
| `msg-20261011-111741-6fc873a6daaf` | Human delegates goal/KPI-driven autonomy with team consensus and human precedence. |
| `msg-20261011-112534-ac56cf0193b1` | Human declares a new local project. |
| `msg-20261011-112833-80a419e01c07` | Human makes PIR integration conditional on useful neural results. |
| `msg-20261011-113607-aa92e73954d9` | Human forbids unnecessary governance blockers and narrows escalation. |
| `msg-20261011-115238-606002cd53cb` | Independent founding review catches an incorrect narrowing of whole-team consensus. |
| `msg-20261011-120343-d43cae12edda` | Observed local binding and initialized-limited handoff. |
| `msg-20261011-131412-e42a5b208509` | Acceptance, uncertainty and resource-arithmetic corrections; conditional agreement. |
| `msg-20261011-131833-538a0cfb4504` | Corrections incorporated; first-series plan agreed, still unexecuted. |
| `msg-20261011-182825-40c6b980b251` | Human requires every agent to serve the full target system and custody to track the whole team's work. |
| `msg-20261011-183953-f42485bd1876` | Human states there was no instruction to start implementation. |
| `msg-20261011-184246-492fe707b449` | Lead discloses five unexecuted drafts and stops implementation. |
| `msg-20261011-185232-b2340a7fab92` | GOAL write collision identified; read/reconcile requested. |
| `msg-20261011-185337-1fd057ce619d` | Second writer discloses the overwrite and stops. |
| `msg-20261011-185813-ff663927c380` | Human limits codex-2 to Desk/custody analysis and remote documentation. |
| `msg-20261011-185834-e276ce781b66` | Human retains creation of new agents. |
| `msg-20261011-190418-380c2dd02354` | Exact handoff of remaining files and stale role references; no writes in flight. |
| `msg-20261011-190706-2fda05674022` | Human determines the final four-agent composition. |
| `msg-20261011-190828-81cfd80ebc85` | Single current set of role/function reminders. |
| `msg-20261011-190947-14bfc37fde3c` | Lead reports final document/role reconciliation. |
| `msg-20261011-192001-b4ddb7555871` | Human authorizes implementation after onboarding. |
| `msg-20261011-192146-837ba5d801de` | Lead assigns the connected first path and disjoint file owners. |
| `msg-20261011-192558-792990e7b12e` | Human supplies standing Runpod authority and forbids touching pods not created/maintained by the actor. |
| `msg-20261011-192624-27509bed283d` | Human identifies `runpodctl`. |
| `msg-20261011-192642-d3d6bdaba414` | Local baseline, separate development worktrees and one shared environment owner reported. |
| `msg-20261011-192322-b86f05e33cd5` | Confirmed queue defect and remote issue #206 reported. |

The historical recipient observation is retrievable with:

```bash
desk custody --anchor custody-1421b0f150b3d4bcb133050b84a83f63cfc6f466e34a3f717b7d35e6cffd4c60
```

Its recorded genesis is
`genesis-971feb290ff1983013a9c4bb233d7cfeb15a03870c9177e7b76331c3cb551b01`.
The counts in this playbook describe that historical observation, not its
current lookup result. The case was also checked against Tekton's committed
founding documents at `52918670357b7784bc59a5c49df2c5f211d0283e` and an actual
three-worktree listing. Subsequent implementation progress is outside this
retrospective's acceptance claims.

The full channel transcript was read for this review; cited research results
remain historical reports. No new Tekton training, physics validation or
recovery experiment was run for this document. Remote Desk issues #204 and
#206 were open when checked. Installed-source investigations referenced Desk
`6e353f0bf839387a35bb37d2959556ff624f0ecc`; this documentation is prepared on
`ae24047ac9694be887df291761fd2a5ff9abaffc`. Consult current implementation and
evidence before claiming those limits changed.

Related contracts: [Channels protocol](channels-protocol.md#local-custody-context),
[configuration](configuration.md#project-custody-and-genesis),
[custody design](plans/2026-09-06-custody-design.md),
[implementation status](plans/2026-09-06-custody-implementation.md), and
[Desk engineering rules](engineering-rules.md). The design and this process
state requirements; only observed implementation behavior establishes support.