Every new Codex can code. It still starts without the team’s experience.

When a session changes—or a different AI teammate joins—the team must reconstruct architecture, prior failures, protected files, current responsibility, and the definition of done.

Blind long-term memory is not a safe answer. A stale assumption remembered confidently can be more dangerous than a missing fact.

The Codex Team Experience Passport is AI Tapestry by AETHER’s working proposal for this problem. It gives an incoming Codex a task-specific, source-linked view of team experience while enforcing a clear boundary:

I understand — inherited context that explains why the team is here.
I must verify — claims that must be checked against the current repository and tests.
I do not yet know — uncertainty that must remain visible instead of being invented away.

The Competition Edition proves one complete loop:

inherit → classify → human approval → repository verification → minimal correction → tests → final human approval → Experience write-back

Memory is context—not proof.

What the working demo proves

The judge-facing scenario uses a synthetic Python and SQLite development project.

A recorded GPT-5.6 run structures Message, Knowledge, Task, and Experience records into a task-specific Passport.
Codex separates inherited context into what it understands, what it must verify, and what it does not yet know.
A human approves the verification plan before any code change.
Repository inspection confirms that the main path already uses Approach B, while a legacy path still contains an incompatible Approach A.
Controlled evidence shows the expected before-fix failure.
Codex applies one minimal correction by reusing the existing Approach B helper.
The targeted regression, demo-project suite, and broader Competition Edition test suites pass.
A protected artifact remains unchanged before and after the correction.
A second human approval authorizes the verified result for Experience write-back.
Remaining uncertainty stays visible so the next AI must verify again.

Why this is not merely long-term memory

Most memory systems focus on storing and retrieving more context. The Team Experience Passport focuses on whether inherited context is safe to act on.

It is:

shared across AI teammates and sessions, not confined to one assistant’s conversation history;
task-specific, rather than a dump of everything remembered;
source-linked, so important claims remain traceable;
uncertainty-aware, so unknowns remain unknown;
repository-verified, so current code outranks inherited assumptions;
human-governed, with approval before change and before write-back;
recursive, because the next AI inherits the result but must verify it again.

Memory narrows what Codex must verify; it never replaces verification.

Why this matters to Codex

As Codex moves from a powerful assistant toward longer-running, multi-agent, organizational work, model capability is only part of the problem. Teams also need continuity, trust boundaries, and accountable handoffs.

Without continuity, humans repeatedly perform zero-to-one onboarding. With blind memory, outdated mistakes can propagate across sessions. The Team Experience Passport proposes a middle path: organizational learning without turning memory into authority.

We built this for the moment when Codex stops being a single contractor and starts becoming a teammate.

How Codex was used

Codex was the primary engineering partner for the Build Week Competition Edition. Within human-defined purpose, intellectual-property boundaries, approval policy, and GO/HOLD/STOP decisions, Codex helped:

refine the proof architecture;
implement the synthetic fixture and five-stage Judge Mode;
implement two human-approval gates;
build the controlled before/after regression path;
add source-linked evidence and protected-artifact checks;
run the test suites and fresh-clone verification;
sanitize the complete reachable Git history;
create reproducible public-safety and judge instructions.

The repository contains dated Build Week commits and a dedicated Codex collaboration document.

How GPT-5.6 was used

In the recorded product run, GPT-5.6 structures four team records—Message, Knowledge, Task, and Experience—into a task-specific Passport for an incoming Codex.

GPT-5.6 supplies structured onboarding context. It does not decide repository truth. Git state, source inspection, executable tests, protected-artifact checks, and human approvals remain authoritative.

The judge-facing interface deterministically replays the recorded onboarding evidence. Playback requires no API key and makes no external API call.

What was built during OpenAI Build Week

The broader AI Tapestry concept predates the challenge. This separate Competition Edition adds and evaluates:

the Codex-specific Team Experience Passport;
the I understand / I must verify / I do not yet know boundary;
two explicit human-approval gates;
a synthetic Python/SQLite migration fixture;
controlled before-fix and after-fix evidence;
protected-artifact hashing and source-linked Evidence Details;
verified Experience write-back with remaining uncertainty preserved;
a deterministic five-stage Judge Mode;
a separate testable repository, README, sample data, tests, and evidence bundle;
a reproducible make public-safety audit covering the current tree and reachable Git history.

The Competition Edition shares no Git commits or code blobs with AI Tapestry Core.

Technical evidence

Verified from a clean GitHub clone on macOS with CPython 3.13.14, zsh 5.9, and SQLite 3.50.4:

Judge Mode ready in approximately one second after installation;
no OpenAI API key required for Judge Mode;
no external assets or external API calls during replay;
PHASE 5: 20/20 passed;
PHASE 4: 5/5 passed;
PHASE 1: 16/16 passed;
demo project: 4/4 passed;
targeted compatibility regression: 1/1 passed;
replay regenerated 10 times with one canonical hash;
public-safety findings: 0;
current tree and reachable history contain no personal reviewer identity, secrets, Core imports, or proprietary scoring logic.

Judge path

No account, production database, personal data, or API key is required.

git clone --branch main --single-branch \
  https://github.com/miho-tax/ai-tapestry-build-week.git
cd ai-tapestry-build-week
python3 -m venv .venv
.venv/bin/python -m pip install -e .
env -u OPENAI_API_KEY make public-safety
env -u OPENAI_API_KEY make judge-demo

Open the loopback URL printed in the terminal. Select Restart, then use Next to inspect all five stages. Open Evidence Details in the inherited experience, verified execution, and Experience write-back stages.

Supported and verified environment

Verified:

macOS;
CPython 3.13.14;
zsh 5.9;
SQLite 3.50.4;
local loopback browser experience.

Package metadata permits Python 3.12 or later, but Python 3.12, Windows, WSL, Linux, standalone Chrome, standalone Safari, and mobile were not independently verified for this submission.

Transparency, safety, and intellectual-property boundary

Judge-facing data and approvals are synthetic.
The repository contains no production database, customer data, personal information, credentials, or raw private conversations.
Guided Replay is recorded evidence, not a live API call during playback.
AI Tapestry Core / AI結Core is not included.
Proprietary retrieval scoring, weights, thresholds, ranking logic, and patent-sensitive internals are excluded.
Rollback behavior, hosted deployment, A/B comparison, and semantic/vector retrieval are not claimed as completed.
This is one controlled product demonstration, not a statistically generalizable productivity study.

Potential impact

A verified experience layer could help development teams:

reduce repeated onboarding across sessions and AI teammates;
preserve architectural rationale, prior failures, and protected constraints;
prevent stale assumptions from silently becoming authority;
make human approval and executable evidence part of every handoff;
let multiple AI teammates contribute to one evolving body of organizational experience.

No AI Teammate Starts From Zero.

But every AI teammate must still verify the world it inherits.