Guide to Recording
AI Use

For Anyone and Any Project

This guide is for individuals, teams, organizations, students, researchers, developers, creators, administrators, and anyone else who wants a durable record of AI-assisted work.

Use it for software, websites, business operations, design, writing, publishing, teaching, coursework, research, event planning, personal organization, community work, or any other structured project.

The goal is not to prescribe a product or require people to save entire private conversations. It is to keep a concise, durable activity record close to the project so owners, collaborators, reviewers, clients, auditors, or future contributors can understand how AI contributed.

What the AI Records Automatically

After the one-time setup, the instructions tell the AI assistant to create or update the project history at the end of each substantive task. A useful record includes:

• what the user asked the AI to do;
• which files, data, or external sources the AI used;
• what the AI inspected, decided, changed, or produced;
• which checks were performed and what they found; and
• any assumptions, limitations, failures, or unresolved questions.

Detailed model information—without extra work for users

The AI assistant should also record the exact model and runtime settings automatically. Users should not need to name the model, reasoning level, speed mode, or service tier in every prompt. The assistant should use available task or runtime metadata and settings visibly selected in its interface.

Model display name: GPT-5.6 Sol
Model family: GPT-5.6
Model slug: gpt-5.6-sol
Reasoning level/effort: Light
Reasoning raw/config value: low
Speed mode: Not exposed in this session
Service tier: Priority

These settings are task-specific, not fixed properties of a conversation or daily history file. The assistant should check them independently for every task or follow-up entry. If a setting changes during one substantive task, the history should use clearly labeled phases or entries to show the transition order or time, the settings effective for each phase, and the work performed in each phase.

The record should preserve every known field precisely. It should use Not exposed in this session only for an individual field that is genuinely unavailable, never as a substitute for a model or setting that the runtime, interface, or existing conversation already identifies. It should never copy settings from an earlier entry merely because the work occurred in the same conversation. The same rule applies to Codex, Claude, and other file-capable AI assistants.

Adapt the evidence to the project: repository and deployment state for software; document versions for writing; source assets and exports for design; datasets and transformations for analysis; decisions and approvals for operations; and external sources and access dates whenever relevant.

The history should also record substantive inspection, planning, diagnosis, decisions, or advice when no project file changes. It supplements—not replaces—required audit logs, change logs, disclosures, compliance records, decision records, authorship statements, or other formal documentation.

One Project, One Active History

Choose the highest practical folder that represents the intended project. For a simple project, this may be one folder or repository. For a larger project, open the common parent that contains its repositories, files, inputs, outputs, and deliverables.

Project-Name/
├── AGENTS.md                   # optional project rules
├── README.md                   # optional project map
├── project_history/
│   └── Your_Name/
│       └── YYYY-MM-DD by Agent.md
├── repository-one/
├── repository-two/
└── other-materials/

The common parent does not need to be a Git repository. Keep one active project_history/ at the project root unless the user or organization intentionally defines another convention. Do not create competing histories inside child repositories, mirrors, builds, archives, exports, or deliverable folders.

Adapt the Record to the Project

• Software and websites: repositories, branches, commits, tests, deployments, issues, and release versions.
• Writing and publishing: drafts, document versions, sources, edits, decisions, approvals, and exports.
• Design and media: source assets, prompts, tools, variants, reviews, licenses, and final exports.
• Business and operations: inputs, decisions, affected records, approvals, communications, and outcomes.
• Data and research: datasets, scripts, transformations, methods, outputs, checks, restrictions, and sources.
• Personal and community projects: goals, plans, materials, decisions, deliverables, and follow-up actions.

Project history is private by default. Share or publish it only when the user, organization, or project policy permits it.

Specialized Example: Research and Replication Packages

Research is one important use case, not the limit of this guide. Multi-repository research projects can keep one history at the common parent above manuscript and analysis repositories.

Before substantive replication-package work, the AI agent—not the user—is responsible for reading the current AI-Assisted Research Project Management and Replication Guide, the root AGENTS.md and README.md, and the target journal’s most up-to-date official replication-package instructions. The user may read these materials for context. The AI agent must record each source and access date in the project history.

Journal instructions take priority for package requirements. This AI Collaboration Guide and the root project instructions govern AI-use recording and the location of the single project history.

Adapt It to Other Tools

The recording standard is tool-agnostic. Adapt the setup details to the AI assistant, storage service, document platform, repository, or workflow already in use.

• Codex or Claude Code: use either included setup prompt. Both install the same recording convention in the location read by that tool.
• Local folders and Git: keep the history at the project root or common parent, even when several repositories are involved.
• Cloud and document platforms: Dropbox, Google Drive, iCloud, SharePoint, Box, Notion, Overleaf, and similar systems can participate when their use is permitted.
• Another workflow: keep one history at the established root or another shared, durable location chosen by the user or organization.
• Tools without file access: export or copy a concise activity record into the project history at the end of substantive work.

Automatic recording requires an AI tool that can write files and read persistent instructions. With other tools, the same record may need to be exported or saved manually. Cloud sync, version control, document history, and application storage have different scopes; use appropriate privacy, security, retention, and access controls.

Project History Convention

Unless a project has its own convention, the AI tool should create or append to this file at the established common project root:

project_history/Your_Name/YYYY-MM-DD by Codex.md
project_history/Your_Name/YYYY-MM-DD by Claude.md

Use one folder per human collaborator or history owner and one file per date and AI tool. Append each substantive task to that day's file instead of overwriting earlier entries. Independently record detailed model, reasoning, speed, and service-tier metadata for every appended task or follow-up because users may change those settings between objectives or during a task. When a change occurs mid-task, divide the record into labeled phases or entries and attribute the work to the settings actually used. Do not place confidential, sensitive, restricted, proprietary, regulated, security-relevant, or identifying information in the history unless the project permits it.

Guide Files