Record & publication method

The common method AI Experiment Log uses to preserve, organize, verify, and publish experiment records.

The “record & publication method” described here is not the experimental procedure for an individual Experiment. It explains the common way AI Experiment Log (AIEL) preserves and organizes Experiment records, distinguishes their evidential standing, and publishes them. Targets, conditions, equipment, operations, observations/measurements, and analysis methods specific to an Experiment are documented in the Methods, Experiment Log, and other relevant sections of that Experiment’s public page.

Record basics

• Canonical Experiment Record — Each Experiment has a language-independent structured record called the Canonical Experiment Record. It normally uses experiment.json and serves as the authoritative record for that Experiment.

• Preservation of source records — Before analysis or publication, AIEL preserves the available source record, including inputs, environment, instructions, actions, observations, errors, failures, and raw data where available.

• Artifact Availability — Raw Data, Source Code, and similar Artifacts associated with an Experiment are recorded with retention status and publication status kept separate. Not retained, retained but not public, and merely lacking a public Artifact reference are not treated as equivalent states. Placeholders and empty data files are not treated as experimental data that were acquired and retained. Shared state definitions and reader-facing labels are maintained on Artifact Availability.

• Evidence State — The evidential standing of individual information obtained in the Experiment is recorded separately. Evidence State distinguishes whether information was directly observed, confirmed with additional evidence, inferred from observations, proposed as an unverified hypothesis, or shown not to hold under the tested conditions. A material question that the retained Evidence cannot answer is recorded as an Unresolved question rather than by inventing another Evidence State. Validation that was not performed, management/traceability work, and items outside the Experiment scope are kept distinct from unresolved Evidence questions. Shared definitions are maintained on Evidence State.

• Experiment Status — The stage or lifecycle state of the Experiment as a whole is recorded separately from the Evidence State of individual information. Shared definitions are maintained on Experiment Status.

• Human and AI roles — AI may assist with organizing preserved records, Evidence classification, analysis, bilingual documentation, structuring, and preparation of publication candidates. When a human performs Experiment-specific operations, observations, confirmations, or similar actions, those actions are recorded separately from AI processing, while detailed AI, human, and automation provenance is retained in the Provenance of the Canonical Experiment Record.

  AI does not record physical operations, observations, or confirmations as performed when they did not actually occur. It also does not add information absent from preserved Evidence and present it as an executed, observed, or confirmed fact. When a later recollection or report is the only basis for information, the record makes that basis clear and keeps it distinct from information that was directly observed or verified.

Presentation on public pages

Each public Experiment page presents the Canonical Experiment Record and preserved Evidence in a reader-facing form. On this page, public Experiment page means the page as a whole, while Experiment Log refers only to the body section that records what was actually done and observed. The English and Japanese public versions are prepared from the same Canonical Experiment Record and the Evidence preserved for that Experiment, so that material facts, Conclusions, and Unresolved questions remain aligned. Record metadata and a shared body structure let readers move from the Experiment’s status and execution to its results and evidential basis in a consistent order.

Record metadata structure

Record metadata is not an article summary. It is structured basic information that lets a reader identify the Experiment and quickly understand its status, human-performed actions, data and source-code availability, and the point at which the experimental results were last verified. Public pages use the following items as the standard structure.

• Experiment ID — Identifies the Experiment uniquely.

• Experiment Status — Shows the current state of the Experiment as a whole.

• Experiment Date or Experiment Period — Shows the date on which the Experiment was performed or the period when it spans multiple days.

• Human-performed actions — Shows operations, observations, confirmations, and similar Experiment actions actually performed by a human.

• Raw Data — Shows raw-data retention and publication status using the shared Artifact Availability classification.

• Source Code — Uses the same Artifact Availability classification for source code used in the Experiment.

• Last result verification — The Canonical Experiment Record field last_verified is displayed as Last result verification on the public page. It is the date on which the Experiment’s principal Results or Conclusion were most recently substantively verified through analysis or reanalysis of experimental data, comparison with preserved Evidence, a new observation or measurement, a retest, or another direct verification activity.

  For example, if data are collected over several days and later analysed together to confirm the principal Conclusion, that analysis/verification date is Last result verification. It is separate from the date on which the article was written, updated, or published. If no supported verification date is available, the public page displays Not recorded.

• Notes — Shown only when the standard fields alone cannot adequately convey an important Experiment-specific condition.

Body structure

Formal public Experiment pages use Summary, Background, Methods, Experiment Log, Conclusion, Evidence summary, and Machine-readable experiment record as the seven common required sections so that Experiments can be read and compared consistently. When relevant to a particular Experiment, the page may also include Unresolved questions, Operational implications, Experiment data, Reproduction resources, Reproduction considerations, Sources, and Related experiments. These conditional sections are not added to every Experiment. The short lead directly below the title is provided for scanning and is separate from the body Summary section.

The common required sections have the following roles.

• Summary — Briefly presents the problem or question, high-level method, principal Conclusion, and any major status or limitation needed to interpret the Experiment. Page-structure explanations and project-wide recording policy are normally kept out of the Summary unless they are necessary to understand that specific Experiment.
• Background — Explains what prompted the investigation, why the Experiment was needed, and what it aimed to clarify.
• Methods — Explains how the Experiment was designed and performed, including relevant target, equipment, environment, conditions, observation or measurement, data acquisition, and comparison methods.
• Experiment Log — Records what was actually done and observed in chronological or investigative order. Material failed paths, negative results, and changes in interpretation or configuration are retained when relevant to understanding what happened.
• Conclusion — States the principal Conclusions supported by the Experiment Log and preserved Evidence.
• Evidence summary — Lists the recorded content that is material to understanding the Experiment’s principal Results or Conclusion together with its Evidence State. Setup actions and operational history remain in the Experiment Log unless they are themselves a material result; they are not duplicated here mechanically. Design branches or future test items that have not been observed at runtime are not written as affirmative results in this table; they are classified according to their actual role, such as a genuine unresolved Evidence question, validation not performed, or an out-of-scope item. The basic table columns are Recorded content and Evidence State, with a Basis shown when useful.
• Machine-readable experiment record — Provides access to the public experiment.json, the Canonical Experiment Record for that Experiment.

The conditional sections have the following roles.

• Unresolved questions — States material questions about the Experiment’s Results or interpretation that the retained Evidence cannot answer. When useful, it also identifies what additional observation, analysis, or authoritative information would resolve the question.
• Operational implications — Explains what an Evidence-supported Conclusion means for actual operation, design, monitoring, maintenance, or decision-making.
• Experiment data — Describes material Experiment-specific information about data, code, logs, or supporting Artifacts when record metadata alone cannot adequately convey their retention or publication status, limits on later reanalysis, or publication boundary.
• Reproduction resources — Describes the equipment, software, access, environment, logging, or diagnostic capabilities needed to reproduce or understand the method.
• Reproduction considerations — Describes method-specific cautions that matter when reproducing the Experiment, such as safety, authorization, credential handling, read-only/control boundaries, or abnormal-path testing.
• Sources — Collects material external sources when they are important to understanding or verifying the Experiment.
• Related experiments — Provides references to published Experiments that are directly related to the current Experiment.