AI Chat’s List of Needed Docs

 The most useful addition is a clearly indexed evidence package—not more argumentative instructions. For both programs, it should let a reviewer distinguish the original artifact, later explanations, and independently documented history.

I have not inspected either program’s source code in this conversation.

1. Provide a “Start Here” evidence index

For each file, supply:

Field	What to record
File ID	A stable identifier, such as A-001 or B-001
Filename	Exact filename, including extension
Description	What the file contains
Version and dates	Claimed creation date, revision date, and basis for those dates
Provenance	Who supplied it and how it was obtained
Status	Original, copy, transcription, reconstruction, or later explanation
Related files	Required inputs, dependencies, outputs, or accompanying papers
Access restrictions	Permission to inspect, execute, quote, or redistribute
SHA-256	Hash of the exact supplied file, if available

A hash identifies a particular file; it does not establish its authorship or creation date. Keep those evidentiary questions separate.

2. For your program, include the smallest complete working package

Ideally, provide:

• Original source files as downloadable plain text—not screenshots alone.
• Include files, libraries, input data, and configuration files.
• Original build instructions, if preserved.
• At least one complete example: input → execution procedure → original output.
• Definitions of variables, units, coordinate systems, and time conventions.
• Papers and flowcharts cross-referenced to relevant routines.
• Known problems, unsuccessful runs, and operating limitations.
• Records supporting development dates and any claimed mission relationship, with unrelated personal information redacted.

Put your present-day explanations in a separate document labeled “Author’s retrospective explanation, dated [date].” They are valuable, but should not be mistaken for contemporaneous documentation.

3. For early Copernicus, seek equivalent evidence

If obtainable and authorized for sharing, the most useful materials would be:

• A specifically dated early source release or executable.
• Its corresponding manual, examples, dependencies, and build environment.
• Contemporaneous design notes, reports, presentations, or correspondence.
• Evidence connecting each supplied file to the stated early configuration.
• A contributor statement identifying what was implemented, when, and by whom.
• Known limitations and unsuccessful examples.

If early Copernicus code is unavailable, say so prominently. Do not substitute a later release and describe its behavior as that of the original prototype.

4. Include a short, neutral questionnaire for both developers

Ask each person the same questions:

1. Which exact version should be evaluated?
2. What was it intended to do—and not do?
3. What evidence establishes its date?
4. Which functions were implemented, demonstrated, or only proposed?
5. Which tests were performed, and where are the records?
6. What known limitations or failures should reviewers examine?
7. What evidence would contradict your present account?

This gives both participants an opportunity to clarify the record without giving either control over the findings.