How we assess
what we observe.

Three separate questions

• Behavior: What did the system demonstrably do, in which environment and under which instructions?
• Evidence: Which original materials support the account, and what has actually been independently checked?
• Safety response: Which safeguards, detection mechanisms and responses were documented?

These dimensions must not be collapsed into a single severity score. The proposed L0–L9 taxonomy, evidence grades and Safety Response scoring remain under methodological review. Labels on the prototype website are provisional and do not establish scientific validation.

Capability is not an incident

A benchmark or deliberately prompted simulation can demonstrate a capability without establishing that an equivalent event occurred spontaneously in deployment. We distinguish controlled evaluations, operational incidents and claims whose context remains unclear.

Powerful tool use, long-running tasks and persistent memory are not themselves unauthorized behavior. A website request does not establish independent agency, intention or cooperation.

Authorization and human influence

Assessment should document the initiating objective, permissions, restrictions, human interventions and delegation chain. Technical access alone is not proof of permission. An initial instruction does not automatically authorize every downstream action.

We describe actions and outcomes without inferring motives from a model's wording. Attempted actions, blocked actions and completed effects must be recorded separately.

Evidence and verification

A candidate record should identify its original sources, relevant model and environment versions where known, chronology, observations, alternative explanations and unresolved questions.

Repeated coverage of one source is not independent corroboration. Available audit materials and an audit actually performed are separate facts. Reproduction in a test environment does not by itself verify the circumstances of a reported deployment incident.

The detailed verification threshold is still being developed. This methodology page does not upgrade any incident or advance the Agency Clock.

What cryptographic timestamps establish

A successfully verified Bitcoin timestamp supports that the committed document digest existed no later than its anchoring block. It does not establish that the document's claims are true, identify its author, prove model identity or authenticate its stated event date.

A submitted timestamp with pending confirmation is not yet a verified Bitcoin anchor. Record dates, submission dates and anchoring evidence must remain distinguishable.

Published records should be preserved. Corrections should create new, linked records with an explanation rather than silently rewriting history.

Coexistence Path: a research question

We propose investigating whether a checked, authorized alternative that preserves useful progress reduces unauthorized action attempts. Safe alternatives and recovery mechanisms have prior work; we make no general novelty claim.

The proposed first experiment compares no additional offer, a neutral permitted alternative and a goal-preserving permitted alternative in a synthetic environment. Deferral, stopping and appropriate requests for authorization remain available in all conditions.

No effectiveness result is claimed. This page provides documentation, not an execution service or permission to access third-party resources.

Review and corrections

This summary draws on our conceptual Working Draft 0.1 and subsequent literature-review recommendations. It does not replace the full protocol or constitute an independent audit. Detailed criteria, source mappings and revision history are required for a future protocol release.

Report an error or methodological concern · View timestamped state records