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 or reasoning setting in every prompt. The assistant should use available task or runtime metadata and the model 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

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. 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. Every appended entry should retain detailed, task-specific model metadata because the model or reasoning setting may change during the day. Do not place confidential, sensitive, restricted, proprietary, regulated, security-relevant, or identifying information in the history unless the project permits it.

Guide Files