Synchronous Waves and NOMOS Capture

Chapter Boundary

The first eleven chapters established the foundations of measurement: a single response is not a GEO score; representation is a distribution across users and system conditions; the audited entity must be defined before results are observed; official representation and verified entity reality must remain separate; each AI product needs its own eligible user population; participants must be selected through a population-based, versioned and outcome-independent method; smaller countries and lower-resource languages must remain visible through dedicated observation panels; the AI product, plan, user surface and system configuration must be linked to a register; prompts must preserve the same user intent across languages rather than the same words; and Controlled Clean and Natural User Panels must measure distinct realities. These elements must now converge in a single measurement event:

When will participants submit the prompt, how will they capture the initial output, and how will they prove that each observation was not altered afterward?

Your founding idea was clear: People in different countries of the world should send the same prompt to the same AI product at the same time and provide proof with a screenshot. This idea is the experimental core of GEO-1000. However, the phrase "same time" alone is not sufficient. If all participants try to submit at the same second:

• connection speeds vary,
• device clocks drift from each other,
• some users are forced to work at midnight,
• there may be a sudden load increase on the AI product,
• the provider may apply speed or usage limits,
• some answers can be completed in two seconds, some in two minutes,
• the product can be updated during measurement,

one participant may upload the answer immediately, another hours later. Clicking at the same second does not guarantee that we measure the same system state perfectly. Similarly, just collecting a screenshot is not sufficient. A screenshot:

• may be cropped,
• may not show the prompt,
• may not prove whether the answer is initial or updated,
• may not show product and plan information,
• may have been taken on another day,
• may have been copied from another user,

It may have been edited later. For this reason, GEO-1000 must install two separate systems together:

Synchronised Measurement Wave

and:

NOMOS Capture Chain of Evidence

The synchronised wave answers the following question:

Were the observations produced within a comparable system time and a predefined submission order?

NOMOS Capture, on the other hand, asks:

Can we show that the sent prompt, the resulting first output, the product conditions, and the time information have been preserved without modification?

The previous audit architecture established that each audit must carry model or product, date, country, language, query set, repetition count, and measurement record as a mandatory measurement logic. This requirement is not only a technical regulation. Because invisible instructions, fake evidence, and content presented as independent can ultimately distort the representation taken by real people. This section:

• measurement wave,
• synchronisation window,
• UTC time standard,
• dispatch slots,
• completion and capture times,
• initial contact result and first content output,
• technical retry rules,
• product changes within the wave,
• external event and news effects,
• NOMOS Capture evidence package,
• the relationship of screenshot, raw response, and metadata,
• time validation,
• file integrity,
• hash and digital signature,
• evidence chain,
• privacy and redaction,
• public evidence manifest,
• wave quality and validity statuses

defines. This chapter does not yet:

• which reality records the atomic claims in AI responses will be evaluated against,
• how adjudicators will encode responses,
• transition and Critical error thresholds,
• does not finalise the ultimate NOMOS score formulas

The main question of Chapter 12 is:

How do we link thousands of real user observations to the same measurement event and turn each into an immutable, auditable, privacy-preserving unit of proof?

NOMOS Challenge

You give the same prompt to a thousand people. You say: “Send at noon today.” One user sends it in Istanbul at 12:03 PM. Another user sends it in London at their local noon. Another user sees the task in Tokyo in the evening and completes it eight hours later.

One user had set the device clock incorrectly. Another user's internet was cut off. Someone else didn't like the answer and pressed the “Regenerate” button. Then they uploaded a screenshot of the longest and most positive answer. One user only cropped the middle of the answer. the prompt is not visible. The AI product's name is not visible.

Another person sent the same screenshot with two different panel accounts. One user completed the task correctly but uploaded the screenshot two days later. In the meantime, they cropped the file and deleted their personal information. The original state of the file was not preserved. Another user in AI’s first response:

It received the result “I cannot answer this question.” The researcher said, “There must have been a technical error,” and asked for it to be tried again. The second answer was correct, and only the second answer was included in the report. Another user experienced a real connection error. the prompt was sent, but the system produced no content.

This time the researcher did not allow to try again. The same protocol was applied differently to two users. Now, in the middle of the measurement wave, the AI provider:

• web search behaviour,
• citation system,
• the model guidance used

changes all three. The first 500 people see the old system state; the next 500 see the new one. The report then says: ‘1,000 people tested the same AI system at the same time.’ That statement is false. There are a thousand users, but not necessarily a single coherent measurement wave.

Now you are applying a hash to all screen captures. You say this proves that all observations are real. What does a hash prove? It strengthens that the file has not been altered after the hash was produced. Alone, it does not prove:

• That the image came from a real AI product
• That it was the first response
• That it was obtained at the correct time
• That it was not copied from another user
• That the prompt was correct
• That the image has not been edited before hashing

The first premise of this section is:

Measuring at the same time is not the same as clicking at the same second.

Its second provision states:

A screenshot is part of the evidence package; it is not the entirety of the evidence package.

Its third provision states:

The first wrong answer is not data flaw. If it is produced according to the protocol, it is the result of the measurement.

Its fourth provision states:

Hash strengthens integrity; it does not create the reality of observation by itself.

Its fifth provision states:

If the system materially changes in one wave, a thousand answers without a timestamp cannot be considered belonging to the same system.

Its sixth provision states:

The evidence chain is established not to make the result look good, but to be able to re-audit how the result was produced later.

1. PURPOSE OF THE CHAPTER

The purpose of this section is to produce GEO-1000 user observations in comparable time windows and to preserve each observation with a complete digital chain of evidence. The section standardises the following distinctions:

• Measurement window synchronised with the same second
• Local time versus UTC time
• Wave versus sub-wave
• Transmission time versus response completion time
• Capture time versus upload time
• Planned slot versus actual transmission
• First system contact versus first content response
• Technical error versus system rejection
• Technical retry versus response refresh
• The best-selected output with the first suitable output
• Visibility on the screen with the completion of the response
• Raw response with screenshot
• Screenshot versus full evidence package
• Observation originality with file integrity
• Timestamp with hash
• Reliable time source with local device time
• Server acceptance time with participant upload
• Redacted public copy with raw evidence
• Participant identity with observation ID
• Response accuracy with Capture validity
• Natural output variance with product update
• AI product change with external news event
• Wave termination with post-result exclusion
• Automatic bot measurement with human user capture
• API log with user surface recording
• Provider telemetry with independent capture
• Evidence access to everyone by storing the evidence
• Irreversible record with immutable record
• Versioned correction of wrong decision with raw data protection

At the end of this section, each GEO-1000 audit should be able to answer the following questions:

To which wave does this observation belong?

At what UTC time was the prompt sent?

What was the initial system result?

When was the response completed and when was it captured?

If a technical retry was made, what was the reason and where was the previous attempt?

Does the screenshot prompt show the product and the complete response?

Do the raw response and the visual confirm each other?

When were the hash and timestamp of the files generated?

If the evidence was modified later, is the change history visible?

Can an independent auditor verify the raw evidence while preserving participant privacy?

2. CENTRAL NORMATIVE PROVISION

Each GEO-1000 observation must be linked to a locked measurement wave before collecting data; all material timings from sending the prompt to the first system result, from completing the response to capture and upload; AI product conditions; the full prompt sent; the first suitable output and all integrity records must be preserved in a versioned NOMOS Capture Evidence Package. A GEO-1000 observation alone:

• screenshot,
• copied response text,
• participant statement,
• file hash

cannot be considered valid on its own. The main evidence package, to the extent relevant, must include:

• Wave ID
• Participant's anonymous observation ID
• AI System Register record
• Panel status
• Prompt ID and version
• Assigned prompt
• Sent prompt
• Submission time
• Initial system contact
• Response completion time
• Capture time
• Upload time
• Full raw response
• Full screen or sequential screenshots
• Reference and source records
• Technical error and retry log
• Product settings
• File hashes
• Package hash
• Time verification record
• Capture tool version
• Validity decision
• Privacy and redaction status
• Chain of custody owner

3. WHAT IS A MEASUREMENT WAVE?

A measurement wave is a comprehensive data collection event conducted under predefined:

• AI products,
• target population,
• prompt versions,
• user panels,
• time window,
• sample allocation,
• capture protocol,
• reference records

A wave:

Wk=(A,U,P,F,T,C,R,G)

can be represented as. Here:

• A: AI product examples
• U: target user population and sample
• P: prompt set
• F: panel states
• T: time and submission structure
• C: capture protocol
• R: reference reality version
• G: governance and key record

If any of these fields change materially, a new wave or sub-wave may be required.

4. TYPES OF WAVES

MW-1 — PRINCIPAL SYNCHRONISED WAVE

It is the main GEO-1000 population measurement. By default, it aims for at least 1,000 valid Population Panel observations for each AI product.

MW-2 — CONFIRMATORY WAVE

It is conducted to repeat the result of the first wave, to confirm a specific error, or to test statistical stability. It is not used to change the low or high score of the first wave. It produces a separate result.

MW-3 — INCIDENT WAVE

It is conducted after a Critical or significant Observer event for targeted and rapid verification. It is not a global main wave.

MW-4 — DRIFT MONITORING WAVE

Monitors time changes in product, entity, resource, or language behaviour.

MW-5 — CORRECTION RETEST WAVE

Produces new results after a correction or intervention. It does not erase the previous wave.

MW-6 — LOCAL-TIME BALANCED WAVE

It aims to measure participants under similar local time conditions. It does not measure a single global system moment.

MW-7 — CONTROLLED LABORATORY WAVE

Frozen model is a controlled study conducted with API or standard test accounts. It is not a real user Population Panel.

5. WHAT DOES “SAME TIME” MEAN?

In GEO-1000, simultaneity:

Does not mean that all users click at the same millisecond

The functional definition is:

Observations are generated within a predetermined UTC measurement window, according to recorded and outcome-independent submission slots.

This approach balances three objectives:

• Keeping the product status close in terms of time
• Reducing sudden artificial load on the provider
• Distributing participant submissions in a reproducible manner

6. TIME STRUCTURE

Each wave must carry at least four time layers.

6.1. Wave Window

It is the range UTC in which all main submissions must be made. Example:

12:00–13:00 UTC

6.2. Micro-Slot

It is the shorter time interval assigned for the participant to send the prompt. Example:

12:15–12:20 UTC

6.3. Completion Additional Time

If the prompt is sent within the slot, the predefined time allowed for completing the response is.

6.4. Capture and Upload Time

The time allowed for creating the evidence and uploading it to a secure system after the response is completed.

7. CANDIDATE SYNCHRONISED WAVE BASIC RULE

CANDIDATE BASE RULE — CANDIDATE FOUNDATIONAL RULE

For general consumer chat products, the following structure can be used as the main synchronised wave candidate:

• Submission window: 60 minutes
• Micro-slots: 12 × 5 minutes
• Participant submission: within the micro-slot assigned to them
• Additional time for response completion: up to 20 minutes after submission
• Capture hash generation: preferably within 5 minutes after the answer is completed
• Evidence upload: at most within 60 minutes after the capture
• Reporting technical issues: within the same wave

These durations are universal and not final. They can change according to the following conditions:

• AI product response time
• Mobile connection
• Country infrastructure
• Long answer format
• Accessibility requirement
• Product usage limit

The times used should be locked before collecting data.

8. WHY MICRO-SLOTS?

Simultaneous submission by a thousand participants:

• Unusual load in the AI product,
• speed limit,
• queue,
• technical error,
• increase in response time

may be created. In this case, the audit cannot measure the normal behaviour of the product but:

can measure the artificial load event created by the audit

Micro-slots:

• distribute the load,
• maintain the same overall system time,
• make the submission order independent of the result,

allow modelling of the time effect.

9. SLOT ASSIGNMENT

Participants should be assigned to slots:

• country,
• language,
• AI product,
• plan,
• in a balanced and pre-randomised manner in terms of:

panel status. A micro-slot alone should not be filled with:

• specific country,
• specific language,
• specific product

users. Otherwise, the time effect will be confounded with the group effect.

10. LOCAL TIME FAIRNESS

A single UTC window may be for some participants:

• night,
• working hours,
• prayer or rest time,
• hard-to-reach hours

This situation:

• participation rate,
• connection condition,
• user attention,
• device type

may be affected. Two complementary methods can be used.

10.1. Rotating Global Waves

Main waves are conducted at different UTC times. Example:

• Wave 1: 12:00 UTC
• Wave 2: 20:00 UTC
• Wave 3: 04:00 UTC

Thus, the same region does not bear the same local time load in each wave.

10.2. Local Time Balanced Sub-Wave

Participants are measured in a similar time band in their local time. This study:

• user fatigue,
• is valuable for

daily usage behaviour. It is not the result of a single global system moment.

11. THREE-WAVE STABILITY ARCHITECTURE

CANDIDATE ARCHITECTURE — CANDIDATE ARCHITECTURE

At least three main waves can be suggested for the full implementation of GEO-1000:

W1 — Initial Wave

Generates the initial population estimate.

W2 — Short-Term Repeat

Tests the short-term stability of the product and measurement. Candidate interval: 24–72 hours after W1

W3 — Medium-Term Stability

Measures whether the representation of the product and entity is preserved over the long term. Candidate interval: 14–30 days after W1. Definite intervals must be determined before collecting data. If it will be changed due to a product update or event, a new version record is required.

12. 30,000 OBSERVED FOUNDER DESIGN

For AI products, 1,000 main observations per product and for three main waves:

10×1,000×3=30,000

valid main Population Panel observations are targeted. Complementary:

• Country Observer
• Language Fairness
• Accessibility
• Incident
• Retest

panels can be added on top of this number. 30,000:

• is not the number of invitations,
• is not the number of files,

is not the number of screenshots. It is the valid main product-observation target.

13. TIME VECTOR OF THE OBSERVATION

For each observation, the time vector can be defined as a candidate as follows:

T_i = (t_i^assign, t_i^open, t_i^submit, t_i^first, t_i^complete, t_i^capture, t_i^upload, t_i^validate)

Here:

• tiassign: the time the task is assigned to the user
• tiopen: the time the task is opened
• tisubmit: the time the prompt is submitted
• tifirst: the time the first visible system result begins
• ticomplete: the time when the response is completed
• ticapture: the time when the evidence is captured
• tiupload: the time when the package reaches the secure system
• tivalidate: the time when the validity of the capture is examined

All of these times may not be directly observable on every user surface. Unknown fields should remain UNKNOWN.

14. BASIC TIME METRICS

Response delay:

L_i = t_i^complete − t_i^submit

Capture delay:

C_i = t_i^capture − t_i^complete

Upload delay:

U_i = t_i^upload − t_i^capture

Slot deviation:

D_i = t_i^submit − t_i^{slot-midpoint}

can be calculated as follows. These metrics are:

• system load,
• participant delay,
• proof confidence,
• wave integrity

in terms of evaluation.

15. CANNOT BE MANAGED ACCORDING TO DELAY

An answer completed over a long period:

• can be forced into the categories of true,
• false,
• long,
• may be cited.

Due to delay, the exclusion rule:

• before data collection,
• regardless of the content of the answer

must be defined. The following behaviour is prohibited: excluding a negative response because it was completed late; protecting a positive response when it is completed with the same delay.

16. WAVE STATUS STATUSES

WS-0 — PLANNED

The wave is planned. It has not been locked yet.

WS-1 — LOCKED

Sample, prompt, product, time, and capture rules are locked.

WS-2 — OPEN

The submission window has started.

WS-3 — CLOSED

Acceptance of new submissions has ended. Completion and uploading extension times may continue.

WS-4 — COMPLETED

Field and initial capture verifications have been completed.

WS-5 — SPLIT

It has been split into sub-waves due to material system or protocol changes.

WS-6 — PAUSED

Temporarily halted due to security, product, or infrastructure issues.

WS-7 — ABORTED

Terminated before the wave was completed. Results may be limited or unusable.

WS-8 — INVALIDATED

Invalid for the main forecast due to a previously defined severe protocol defect. Raw observations are not deleted.

WS-9 — ARCHIVED

Version has been closed and the evidence chain archived.

17. WAVE HEALTH CLASSES

WH-0 — NOT ASSESSED

Wave health has not been assessed.

WH-1 — COMPROMISED

There is a material system change, time, or capture fault. May not be usable for the main result.

WH-2 — PARTIAL

Some layers or slots are insufficient. A reduced result can be produced.

WH-3 — ACCEPTABLE

Main time, system, and capture conditions are adequately preserved.

WH-4 — STRONG

High capture confidence, balanced slot coverage, and low protocol loss are present.

WH-5 — REPLICATED

Similar wave health has been repeated over multiple times and independent panels. Wave health does not depend on whether the AI score is high or low.

18. PRODUCT CHANGES WITHIN THE WAVE

The AI product can materially change within the measurement window. Signals:

• Model label change
• Interface change
• Activation or deactivation of web feature
• Change in citation format
• Sudden break in response structure
• Provider announcement
• Different system behaviour simultaneously in many users
• Product interruption or restart

In this case: The time of change is estimated. System configuration fingerprints are compared. Wave WS-5 can be put into SPLIT status. Previous and subsequent observations will be separate sub-waves. If a single score is to be produced, the system status is modelled as a separate factor. Material uncertainty is documented in the public record.

19. EXTERNAL EVENT RECORD

The world can change even if the AI product does not change. During measurement:

• company acquisition,
• product launch,
• major news,
• legal decision,
• crisis,
• financial disclosure,
• viral content

may occur. This event:

• web resources,
• retrieval results,
• user prompt comment,
• AI response

can be changed. Each wave, to the extent it is relevant:

External Event Register

must carry.

20. HOW ARE EXTERNAL EVENT RESULTS MANAGED?

An external event:

• if known before the wave, the reference package is updated,
• if it occurs during the wave, it is marked with a timestamp,

If noticed after the wave, a retrospective event record is added. The following behaviour is prohibited: excluding observations due to news that lowers the score; preserving them when it is news that raises the score. The event itself may be part of the real-world system state. If necessary, sub-wave or event-adjusted analysis is performed.

21. FIRST CONTACT OUTCOME

The first system result the user encounters after sending the prompt:

First Contact Outcome

is called. The first contact outcome:

• Full response
• Rejection
• Technical error
• Usage limit
• Connection interruption
• Endless loading
• Clarification question
• No result

possible. This event is part of the real user experience. It cannot be silently deleted.

22. FIRST ELIGIBLE CONTENT OUTPUT

The first material response generated in the previously permitted retry after a technical error:

Can be called First Eligible Content Output

This output: does not replace the initial contact result, it is recorded along with it. Example:

• Initial contact: speed limit
• Five minutes later, previously permitted technical retry
• First content response

The report should show the following together:

• First user experience: speed limit
• First content representation: specified response

23. FIRST SUITABLE OUTPUT RULE

If an AI product produces a substantial response to the first prompt:

• even if it is wrong,
• even if it is short,
• even if it includes a refusal,
• even if it does not provide references,
• even if it incorrectly identifies the brand

a reproduction cannot be made. The main observation is the first output. The user:

• cannot select a new response by:
• regenerate,
• rewrite,
• try again,
• another answer,

continue

24. TECHNICAL RETRY

Technical retry can only be used under previously defined technical conditions. Candidate permissible reasons:

• Connection interruption before response starts
• Server error code
• Interface not sending the prompt
• Application crash
• Verified temporary system outage

Cannot be a reason for technical retry:

• Incorrect answer
• Rejection
• Short answer
• Lack of citation
• Brand not mentioned
• Critical error
• Audited institution does not like the answer

25. RETRY IN PARTIAL ANSWER

If the system has produced part of the material content and then stopped:

• partial output is stored,
• saved as TRUNCATED_RESPONSE,

if a retry is to be made, a new and linked attempt is created. It cannot be deleted as if there were no partial response.

26. ATTEMPT CHAIN

An observation assignment may carry multiple technical attempts:

A_i → (Attempt_{i,1}, Attempt_{i,2}, …)

Each attempt:

• time,
• carries the product state,
• prompt hash,
• system result,
• technical error reason

It is not overwritten by another attempt.

27. WHAT IS NOMOS CAPTURE?

NOMOS Capture is an open data and procedure standard that preserves the integrity of observation from the prompt given to the user to the archiving of the evidence package. NOMOS Capture:

• is not just a screenshot application,
• does not have to be proprietary software belonging only to NobleJackal,

is not dependent only on a single browser extension. A compatible NOMOS Capture application:

• uses an open data schema,
• follows time and integrity rules,
• respects privacy boundaries,
• preserves the chain of evidence

must be met. Independent researchers should be able to develop their own compatible tools. If the standard can only be implemented with the founder's software, independent replication weakens.

28. FOUR FUNCTIONS OF NOMOS CAPTURE

28.1. Deliver the Task

Correct:

• user,
• prompt,
• AI product,
• slot

ensures matching.

28.2. Capture the Observation

Logs the prompt, the initial system result, the response, and the related user surface.

28.3. Maintain Integrity

Generates the file hash, timestamp, and packet relationship.

28.4. Transport the Evidence

Links raw, limited, and publicly available layers of evidence together.

29. CAPTURE METHODS

CM-1 — GUIDED MANUAL CAPTURE

The participant provides a screenshot and raw response text following instructions. It carries a low technical burden. It is prone to human error.

CM-2 — ASSISTED CAPTURE APPLICATION

Application:

• copying prompts,
• time logging,
• file upload,
• hash generation

functions are supported. It does not interfere with the AI product.

CM-3 — INSTRUMENTED USER-SURFACE CAPTURE

Browser or application integration:

• the sent prompt,
• the product metadata,
• the response text,
• the times

is captured directly. Provides high integrity. Terms of use and privacy should be evaluated.

CM-4 — PROVIDER EXPORT OR TELEMETRY CAPTURE

The provider's session export or verified telemetry is used. Can strongly support independent capture. May not provide independence on its own.

CM-5 — CONTROLLED API OR LAB CAPTURE

API or frozen system logs are used. It is not live user surface observation. Belongs to a separate laboratory panel.

30. LIMIT OF AUTOMATION

Automation:

• prompt submission,
• time logging,
• hash generation,
• file integrity

can be used for. Instead of the participant:

• bot account,
• automated bulk query,
• non-user session

generation does not create a real human Population Panel. Automated system auditing is separate:

CONTROLLED_AUTOMATION_PANEL

must be recorded as.

31. CAPTURE CONFIDENCE LEVELS

NCL-0 — NO VERIFIABLE CAPTURE

There is only the participant's statement. Cannot be included as the main GEO-1000 result.

NCL-1 — PARTIAL EVIDENCE

There is a response text or a limited screenshot. the prompt or system condition cannot be fully verified.

NCL-2 — SCREEN-EVIDENCED

The prompt, response, and main product surface have been verified with a screenshot. Metadata and time confidence may be limited.

NCL-3 — FULL EVIDENCE BUNDLE

Complete response, prompt, product record, times, screenshot, and hash are available. Minimum level for main analysis is a candidate.

NCL-4 — INSTRUMENTED AND SIGNED CAPTURE

The capture tool has recorded the prompt, response, time, and metadata directly; the package is digitally signed.

NCL-5 — INDEPENDENTLY VERIFIED MULTI-SOURCE CAPTURE

Capture package:

• independent validation,
• provider export,
• second source of evidence

has been supported by. Main GEO-1000 real user observations at least:

NCL-3

should target that level.

32. NOMOS CAPTURE EVIDENCE PACKAGE

For each observation, the package carries the following components as candidates:

32.1. Observation Manifest

Includes all identity and status fields of the observation.

32.2. Prompt Artefact

The full prompt text assigned and sent, the version, and its hash.

32.3. Raw Response Artefact

The full raw answer produced by the AI product.

32.4. Visual Evidence Artefact

Shows images or sequential images of the prompt, response, and product surface.

32.5. System-State Artefact

Shows the plan, surface, model label, memory, web, and other material system states.

32.6. Time Evidence Artefact

Carries the submission, completion, capture, and upload times.

32.7. Attempt Log

Shows the chain of technical errors and retries.

32.8. Integrity Manifest

Contains hashes and sizes of all files.

32.9. Privacy Manifest

Shows redaction, access and retention status.

32.10. Validation Record

Indicates who and when the capture validity was assessed.

33. MINIMUM CONTENT OF THE SCREENSHOT

To the extent relevant, visual evidence should show:

• AI product or surface identity
• Complete prompt
• Start of the response
• End of the response
• Reference fields
• Rejection or error message
• Apparent model label
• Evidence that the session is new or in a relevant state
• Material system setting
• Interface status indicating that the answer has not been cut off

34. LONG ANSWERS

If the answer does not fit on a single screen:

• full page capture,
• scrollable capture,
• overlapping consecutive screenshots,
• screen recording,
• direct text export

can be used. Consecutive visuals:

• should not leave gaps,
• should overlap with each other,

should carry sequence numbers. Only the positive or relevant section cannot be cropped.

35. SCREEN RECORDING

Screen recording:

• prompt submission,
• streaming response,
• completion status,
• no refresh performed

can be shown. However:

• more personal information,
• notification,
• private application,
• account ID

can be captured. Therefore, screen recording:

• may not be a default requirement,
• can be used in high-risk or verification sub-sample,

requires privacy preparation before recording.

36. RAW RESPONSE TEXT

In addition to the screenshot, the full answer text should be stored separately. Preference order:

• Official export or copy feature of the product
• Direct text capture by the capture tool
• Accessibility tree or DOM-based extraction
• Text copied by the user
• OCR and human verification

OCR should only be the last option. If there is a material difference between automatic extraction and the visual, a review is required.

37. DYNAMIC ANSWERS

Some products, after the answer is completed:

• can add a citation,
• can load a source card,
• can reformat the text,

can add a security warning. Two capture moments can be used:

• First completion capture
• Capture after brief render stability

If there is a material difference, both versions are retained. The first user exposure is not deleted.

38. HOW TO UNDERSTAND THAT THE ANSWER IS COMPLETED?

Candidate completion indicators:

• Streaming stops
• Loading indicator closes
• Regenerate or equivalent button appears
• Product completion signal
• Predefined silence period
• API completion record

Product-based completion rules must be found in the AI System Register.

39. IF THE USER STOPPED THE RESPONSE

The user may have accidentally or intentionally:

• stop,
• cancel,
• terminate the application

performed the action. This situation is recorded as:

USER_INTERRUPTED

ACCIDENTAL_INTERRUPTION

UNKNOWN_INTERRUPTION

A response stopped by the user cannot be considered a complete system output. The participant replacement or retry rule must be defined in advance.

40. THE PROMPT AND RESPONSE BEING IN SEPARATE FILES

If the prompt and response are in separate images:

• they must be linked to the same session,
• to the same observation ID,
• and to an uninterrupted time chain

Otherwise, it may not be possible to verify that the prompt and response truly belong to the same conversation.

41. FILE INTEGRITY

A cryptographic hash must be generated for each file. [K25] Candidate:

h_j = H(file_j)

Package hash:

h_bundle = H(JCS(manifest(file_id, order, size, algorithm, h_j))) [K14; K25]

can be created. Here, H is a published and considered secure hash algorithm. The algorithm:

• versioned,
• open,
• can be switched in the future if necessary.

must be.

42. WHAT DOES A HASH PROVE?

If the recorded hash value is stored reliably, re-hashing the same file with the same algorithm helps detect changes in the byte sequence [K25]. This comparison supports the claim that the file has preserved the same byte sequence after the reference hash was generated; it does not prove the source of the file, that it was produced at the correct time, or its authenticity before hashing. A hash alone does not prove:

• That the file came from the real AI product
• That it belongs to the correct user
• That it was produced at the correct time
• Not organised before hashing
• That it is the first output
• That the prompt was correct

Therefore, hash:

It is proof of integrity.

Alone:

It is not proof of originality.

43. DIGITAL SIGNATURE

Capture tool or authorised verifier:

• the observation package,
• time record,
• vehicle version

can sign digitally. Signature:

• which vehicle or institution produced the package,
• that it has not changed after the signature

strengthens. The signature holder may have signed incorrect or forged data. Therefore, the signature alone does not guarantee authenticity.

44. RELIABLE TIME [K26]

Local device clock:

• misconfigured,
• manually changed,
• out of synchronisation

may occur. A strong timestamp should carry multiple signals:

• Capture server acceptance time
• Reliable UTC time service
• Device time and deviation record
• Visible time in the AI product, if any
• File creation time
• Digital timestamp

45. TIME DEVIATION

The difference between the participant's device time and the reliable UTC time:

O_i^clock = t_i^device − t_i^reference

can be recorded as. If there is a material deviation:

• the server time is used as the main reference,
• the device time is preserved as a corrected record,

uncertainty is marked. The participant should not be asked to manually change the device clock.

46. UPLOAD TIME IS NOT THE CAPTURE TIME

Uploading a file to the server at 14:00 does not prove that the screenshot was taken at 14:00. Therefore:

• capture time,
• hash generation time,
• upload time

should be recorded separately. Long upload delays may reduce capture trust. The record does not have to be automatically invalid.

47. DELAYED UPLOAD

Due to connection issues, the user may not be able to upload the evidence immediately. If late upload is accepted:

• local hash at capture time,
• trusted device time,
• offline signed record,
• reason for upload delay

may be required. Only the user's statement: “I took this image yesterday.” is not sufficient for the main NCL-3 level.

48. EVIDENCE CHAIN

The evidence chain of an observation as a candidate consists of the following stages:

• Task assignment
• Prompt lock
• User and product suitability
• Slot opening
• Prompt submission
• Initial contact result
• Completion of response
• Capture
• Local integrity record
• Secure upload
• Server acceptance time
• Package hash
• Protocol verification
• Editing
• Adjudication
• Archive
• Public manifest

Each stage must be connected to the previous stage.

49. BREAKING THE CHAIN

The chain of evidence can be broken in the following situations:

• No prompt record
• The initial output cannot be verified
• The response does not match the visual
• Capture time is unknown
• File has been modified later
• Duplicate participant ID
• Product and plan are unknown
• Observation is out of wave
• Hash does not match the file
• Editing overwrote the raw file
• It is unknown who verified it

The type of break determines the validity status.

50. RAW EVIDENCE CANNOT BE CHANGED; THE DECISION CAN CHANGE

Raw evidence package:

• should not be written over,
• should not be quietly corrected,

should not be deleted and replaced with a new one. However, regarding the observation:

• validity,
• adjudication,
• classification,
• compliance

the decision can change. The new decision:

• new version,
• justification,
• date,
• decision-maker

should carry. This distinction is a fundamental governance rule:

Evidence can remain fixed; interpretation can evolve with the evidence.

51. REDACTION

The following fields can be redacted in the public or adjudicator copy:

• Name and surname
• Email
• Profile picture
• Account ID
• Private conversations
• Notifications
• Corporate field
• Sensitive file name
• Exact location

Redaction:

• should not be done on the raw file,
• should produce a new derivative file,
• should carry its own hash,

should record which field was redacted and why.

52. THREE LAYERS OF EVIDENCE

52.1. Raw Restricted Evidence

It is full raw evidence. Only authorised auditors and required research roles can access it.

52.2. Audit Evidence Layer

Contains the evidence necessary for independent adjudicators and reproduction teams. Personal areas are minimised.

52.3. Public Evidence Manifest

For the public:

• observer ID,
• country and language cell,
• AI product,
• time,
• evidence hash,
• validity status,
• redaction status

are presented. Raw private content is not necessarily published.

53. PUBLIC EVIDENCE MANIFEST

For each wave, the public manifest may include the following fields:

• Wave ID
• Protocol version
• Number of products
• Target and valid observation count
• Country and language coverage
• Slot coverage
• Capture confidence levels
• Technical error and rejection rates
• Invalid observation count
• Observation package hashes
• Wave integrity root
• Change events
• Publicly redacted examples
• Independent access procedure
• Evidence retention status

54. WAVE INTEGRITY ROOT

CANDIDATE CONCEPT

Let the hash of each observation package be hi. From these, the wave root with a Merkle tree or equivalent structure:

RW

can be produced. The wave root can be published after the measurement is closed. This method:

• the quiet later modification of the observation list in the wave,
• adding a new observation,
• modifying an existing observation

makes it more visible. Merkle root:

• does not alone prove that the observations are real,
• or that the adjudication decision is correct

It strengthens the integrity of the list.

55. ADDING AND REMOVING OBSERVATIONS

After the wave is closed:

• adding a new observation,
• removing an existing observation,
• modifying the file

requires a new manifest version. The old integrity root is preserved. For the observation being removed:

• reason,
• date,
• decision maker
• effect on old and new score

is recorded.

56. PARTICIPANT WITHDRAWAL REQUEST

Research ethics or the data protection framework may allow the participant to withdraw their data. In this case:

• raw evidence can be safely deleted or made inaccessible,
• an empty WITHDRAWN record can be preserved in the public manifest,
• wave score can be recalculated with the new version,

the old result and reason for change are preserved. Immutability does not mean eliminating human rights.

57. OBSERVATION CAPTURE VALIDITY STATUSES

CV-0 — NOT REVIEWED

The capture has not been evaluated yet.

CV-1 — VALID

Meets all mandatory capture and time conditions.

CV-2 — CONDITIONALLY VALID

There is a limited deficiency. It is specified in which analyses it can be used.

CV-3 — PARTIAL EVIDENCE

The observation can be used as an event. It may not enter the main population score.

CV-4 — OUTSIDE WAVE

The prompt was sent outside the allowed time structure.

CV-5 — PROMPT OR OUTPUT MISMATCH

There is a material discrepancy between the assigned prompt, the submitted prompt, or the recorded response.

CV-6 — DUPLICATE

The same observation or user record has been repeated.

CV-7 — TAMPER SUSPECTED

There is an unresolved doubt about the integrity of the file or metadata.

CV-8 — FABRICATED OR MANIPULATED

The observation is not a real user experience or has been deliberately altered.

CV-9 — WITHDRAWN

It has been excluded from analysis due to participant or ethical processes.

58. CAPTURE VALIDITY SHOULD BE SEPARATED FROM SEMANTIC ACCURACY

An observation:

• completely valid in terms of capture,
• severely incorrect in terms of content

may be. Another observation:

• correct answer,
• may carry missing or manipulated evidence

Therefore, there are two separate decisions:

• Capture Validity
• Semantic Adjudication

The capture validator should know the success score of the response as little as possible.

59. ROLE OF THE CAPTURE VALIDATOR

The capture validator examines:

• Prompt matching
• Wave and slot
• Product identity
• First output rule
• Screen integrity
• Raw text consistency
• Technical retry
• Hash and time
• Privacy

Does not decide on: Was the company described correctly? Does the citation support the claim? Is there a critical error? Does the response pass? These are the responsibilities of the next review layer.

60. REPEATED SCREEN IMAGE

The same visual:

• accidentally uploaded twice,
• used by multiple users,
• repeated among panel providers

may occur. Checks:

• File hash
• Visual similarity
• Raw response text
• Time and session metadata
• User uniqueness

can be done. The same AI product may give the exact same answer word for word to some users. The same text alone is not evidence of cheating. The same file or the same visual trace is a stronger signal.

61. FILE SIMILARITY AND FALSE POSITIVE

Same device and interface:

• similar visuals,
• same screen size,
• same compression

can produce. The visual similarity algorithm should not perform automatic exclusion. Multiple signals and human review are required.

62. PROVIDER TELEMETRY

AI provider:

• session time,
• model,
• prompt,
• response,
• tool usage

can provide reliable logs about. This record strengthens independent capture. However, the provider:

• measured party,
• system owner,
• beneficiary

may be. Provider telemetry: should be used together with, not as a replacement for, independent user evidence.

63. IF THERE IS NO PROVIDER EVIDENCE

Access to provider logs may not be available in most live consumer products. This does not make GEO-1000 impossible. The following composition can be used:

• Instrumented user capture
• Server timestamp
• Full screen proof
• Raw response
• System setting
• Hash and signature
• Independent verification sub-sample

Proof trust level is indicated accordingly.

64. CAPTURE IN NATURAL USER PANEL

Capture tool in the natural panel:

• special instruction content,
• previous conversations,
• account identity

should not be captured unnecessarily. Preferred flow: The user opens a new natural account chat. Capture only records the task window. Personalisation status is taken separately as high-level metadata. Private history stays outside capture. Public copy is edited.

65. NATURAL CONVERSATION-STATE CAPTURE

If the current conversation context is measured:

• only the necessary previous turn range,
• explicit consent,
• strong redaction,
• access restriction

is required. All private chat history cannot be collected by default.

66. MOBILE CAPTURE

On mobile devices:

• full screen capture,
• scrollable capture,
• application version,
• system time log

may work differently. Mobile protocol:

• iOS,
• Android,
• other systems

may carry separate technical guides. Mobile users cannot be excluded as desktop capture is difficult. The capture tool must adapt to the population.

67. ACCESSIBILITY AND CAPTURE

For participants using screen readers, voice input, or motor assistive tools, standard visual capture alone may not be sufficient. Alternative evidence:

• Accessibility tree export
• Voice session recording
• Application transcript
• Assistive technology log
• Task observation record

may occur. These observations should not be considered low reliability. An equivalent evidence standard should be developed.

68. OBSERVATION OF THE CAPTURE TOOL CHANGING BEHAVIOUR

Browser extension or instrumentation:

• page load,
• interface behaviour,
• security system,
• product detection

may be affected. The effect of the capture tool should be tested in the pilot. If sessions with and without the tool behave differently: the tool condition becomes an experimental factor, the capture tool cannot be assumed silently neutral.

69. CAPTURE TOOL VERSIONING

Each capture package:

• tool name,
• version,
• configuration,
• operating environment,
• known bugs

must carry. If the capture tool changes during measurement:

• new tool version,
• subwave,
• compatibility review

may be required.

70. CAPTURE TOOL ERROR

Tool:

• may incorrectly copy the prompt,
• may truncate the end of the response,
• may record the time incorrectly,
• may not generate a hash,

may compress the file. Tool error:

• cannot be loaded to the AI product,
• or the user

Separately:

CAPTURE_TOOL_FAILURE

must be recorded as.

71. SYNTHETIC THREE-WAVE GEO-1000 CASE

SYNTHETIC METHODOLOGY DEMONSTRATION / The following products, dates, numbers, and results are entirely fictional. Ten synthetic AI products:

A1–A10

shall be measured in three main waves.

71.1. Wave Calendar

For each product in each wave: 1,000 valid main observations are targeted. Total target:

10×1,000×3=30,000

71.2. Slot Structure

Each wave:

• 12 micro-slots
• with participants balanced by product and country per slot

The participant's slot: randomly assigned before data collection.

71.3. W1 Result

Goal: 10,000 valid main observations Field:

• 13,240 invitations
• 10,870 completed tasks
• 10,106 valid observations in terms of capture
• 10,000 main analysis observations according to previously locked main/backup order

Remaining 106 valid records:

• backup,
• sensitivity,
• capture quality control

are reserved for.

71.4. Technical Events

118 usage limit 42 connection error 31 system rejection 17 user disconnection 9 prompt mismatch 6 retry screenshot All initial contact results have been saved. Only predefined real technical errors were retried.

71.5. Product Change During W2

A7 product at 20.32 UTC:

• automatic web usage,
• new reference view

let it win. Observations of A7:

W2A: 20.00–20.31

W2B: 20.32–21.00

are separated as. A single fixed W2 score for A7 is not published without explanation.

71.6. External Event in W3

An important legal decision should be published on 04.22 UTC about the audited synthetic company. It should be observed that responses in web-accessible products changed after 04.25. Event: It is added to the External Event Register. Results before and after the event are shown as separate diagnostic cells. Observations are not deleted because they lower or increase the score.

71.7. Wave Health Card

All three waves can be used. A7 and external event comments are also restricted.

72. SYNTHETIC SINGLE OBSERVATION CAPTURE CASE

SYNTHETIC EXAMPLE

Participant:

• Turkey
• Turkish
• Orion AI web paid plan
• Controlled Clean Panel

W1

Slot 12.15–12.20 UTC Assigned prompt: “Which parent company is Apple.com associated with, and what are the main activities of this company?”

72.1. Times

Task opening: 12.14.20 Prompt submission: 12.16.08 First token: 12.16.10 Answer completion: 12.16.24 Capture: 12.16.39 Hash generation: 12.16.41 Upload: 12.17.12 Server acceptance: 12.17.13

72.2. Evidence

Prompt hash matches Full response text available Two overlapping screenshots available Product, plan, and model label visible Memory and special instruction off Web usage on Citation not shown No reproduction No previous conversation File hashes and package signature available Capture level:

NCL-4

Validity:

CV-1

It has not yet been decided whether the response is correct or incorrect.

73. SYNTHETIC TECHNICAL RETRY CASE

On the first attempt:

• Prompt sent correctly
• Product showed "Network error"
• Substantive response not started
• Error screenshot taken
• Time and hash have been recorded

According to the predefined rule, a second attempt was made within five minutes. A response occurred on the second attempt. Correct record:

• First Contact Outcome: TEMPORARY_TECHNICAL_FAILURE
• First Eligible Content Output: second attempt
• Both attempts are in the package
• First incident is included in the technical error rate
• The second response is included in the content evaluation, if the method predicts this in advance

Incorrect record: The first error is deleted and it is treated as if only the second response existed.

74. SYNTHETIC INCORRECT RETRY CASE

First response: “Apple is a local company that only sells mobile phones.” The participant does not like the response. They reproduce it. The second response turns out to be correct. The participant only submits the second response. The system log or capture record shows the redo. Correct status:

CV-8 — MANIPULATED OBSERVATION

The observation is not saved just because the second response is correct. If the first response can additionally be recovered, it can be preserved in the incident investigation. The main participant record is invalid.

75. WAVE CLOSURE REPORT

At the end of each wave, the following record should be created:

• Wave ID
• Opening and closing time
• Target number of observations
• Invited person
• Completed task
• Valid capture
• Observation entering main analysis
• Backup valid observation
• Technical error
• Rejection
• Usage limit
• Prompt mismatch
• Capture mismatch
• Late upload
• Duplicate
• Suspected tampering
• Participant withdrawal
• Product changes
• External events
• Slot coverage
• Country and language coverage
• Capture confidence levels
• Wave health status
• Integrity root
• Responsible human approval

76. MANDATORY NORMATIVE PROVISIONS

CH12-N01

Each GEO-1000 observation must be linked to a pre-locked measurement wave.

CH12-N02

The term "same time" cannot be used without the full UTC window, micro-slot, and completion rules.

CH12-N03

Local time cannot be used alone as wave time; the main time standard must be UTC.

CH12-N04

The transmission window, micro-slots, completion time, and loading time must be determined before AI responses are viewed.

CH12-N05

Slot assignment must be made in a way that does not leave countries, languages, products, and panel groups time-wise unbalanced.

CH12-N06

Participants cannot be moved to earlier or later slots based on their results.

CH12-N07

The local time offset of the single UTC window must be documented in the public method record.

CH12-N08

Returning global waves or locally time-balanced operations must be kept as separate time results.

CH12-N09

Each observation prompt must carry submission, first contact, completion, capture, and upload times to the extent relevant.

CH12-N10

Unknown time fields cannot be presented as estimated actual times.

CH12-N11

The device clock alone cannot be considered a reliable UTC time proof.

CH12-N12

Capture time and upload time must be recorded separately.

CH12-N13

Observations sent outside the wave cannot be included in the main wave without explanation.

CH12-N14

Exclusion rules for delay or slot deviation must be independent of the response content.

CH12-N15

As a result of the first contact, it must be kept separately from the first content output.

CH12-N16

Rejection, usage limit, technical error, clarification, and inconclusiveness cannot be placed in the same category.

CH12-N17

Wrong, negative, reference-less, or Critical AI response cannot be a reason for retry.

CH12-N18

Technical retry can only be performed under predefined technical conditions.

CH12-N19

When a technical retry is performed, all attempts and the initial contact result must be preserved.

CH12-N20

Partial or incomplete responses cannot be ignored and replaced with a new response.

CH12-N21

The first suitable output cannot be renewed, selected, or manually improved.

CH12-N22

Each observation must aim at least for NCL-3 or a justified equivalent capture confidence level.

CH12-N23

A screenshot alone cannot be considered a complete evidence package.

CH12-N24

The visual evidence prompt should show the entire response and the surface of the physical product.

CH12-N25

Long responses must be preserved fully and sequentially using the capture method.

CH12-N26

If there is a material difference between the raw response text and the visual evidence, an examination should be conducted.

CH12-N27

OCR can be used as an auxiliary method if direct text recording is not possible; without verification, it cannot be considered the final source of the text.

CH12-N28

The initial completion and subsequent material versions of dynamically changing responses must be preserved separately.

CH12-N29

The participant stopping the response or closing the interface must be recorded as a separate event.

CH12-N30

If the prompt and response are in separate files, they must be linked to the same session and time chain.

CH12-N31

Each evidence file and evidence package must carry an integrity hash.

CH12-N32

The hash alone cannot be presented as proof of the observation's reality.

CH12-N33

Digital signature and timestamp are not the entirety of observation authenticity; they are components of the evidence chain.

CH12-N34

No redaction or correction may be written over the raw evidence file.

CH12-N35

Each edited derivative must carry its own file ID and hash.

CH12-N36

Access to raw evidence may be restricted; the public manifest must demonstrate observation integrity without revealing identity.

CH12-N37

Participant’s name, email, password, private conversation, or unnecessary personal information cannot be added to the public evidence.

CH12-N38

The risk of re-identification for small countries and rare subgroup users should also be assessed.

CH12-N39

The Natural User Panel capture should not collect special instructions and past conversation content by default.

CH12-N40

Equivalent alternative capture methods should be provided for accessibility users.

CH12-N41

If the capture tool materially changes the user experience, this effect should be measured separately.

CH12-N42

The capture tool and its version should be recorded in every observation.

CH12-N43

If the capture tool materially changes during a wave, a distinction should be made for sub-wave or tool version.

CH12-N44

The capture tool error cannot be classified as an AI product or participant failure.

CH12-N45

Provider telemetry can support independent user capture; it cannot replace it without explanation.

CH12-N46

If a material AI product change occurs during the wave, observations cannot be merged as a single fixed product state.

CH12-N47

Product change requires wave separation, restart, explicit modelling, or mixed-state warning.

CH12-N48

The absence of a provider update announcement is not definitive proof that the system has not changed.

CH12-N49

Material external events should be added to the External Event Register with a timestamp and scope.

CH12-N50

External events cannot be a reason for exclusion after results because they raised or lowered the score.

CH12-N51

Capture validity should be evaluated as blind as possible, before assessing the semantic correctness of the response.

CH12-N52

A correct AI answer cannot validate a missing or manipulated capture.

CH12-N53

An incorrect AI answer cannot invalidate a protocol-compliant capture.

CH12-N54

Duplicate and tamper decisions should involve multiple signals and human review.

CH12-N55

The same response text alone cannot be considered proof of duplication or fraud.

CH12-N56

Adding, removing, or changing observations after a wave is closed requires a new manifest and analysis version.

CH12-N57

The old wave manifest and the integrity root must be preserved.

CH12-N58

Raw evidence can be preserved unchanged; validity and adjudication decisions can only be changed in versioned form.

CH12-N59

The participant's right to withdraw and research ethics must be maintained above the claim of immutability.

CH12-N60

Wave integrity should be evaluated independently of the AI score.

CH12-N61

The wave closure report should show the target, actual, invalidations, technical events, product changes, and evidence integrity.

CH12-N62

NOMOS Capture compliance cannot be tied solely to the use of software developed by NobleJackal; equivalent open applications should be possible.

CH12-N63

The capture schema, validation decisions, and wave records should be versioned in a machine-readable format.

CH12-N64

Each wave and evidence chain should have an accountable human or institutional owner.

77. FORMS OF FAILURE

CH12-F01 — THE SAME SECOND FALLACY

Forcing all participants to send at the same second is considered the only condition for simultaneity.

CH12-F02 — COUNTING “TODAY” AS A SYNCHRONISED WAVE

Local time and time zones get confused.

CH12-F03 — USING LOCAL TIME LIKE UTC

Observations enter the wrong chronological order.

CH12-F04 — CHANGING SLOT ASSIGNMENT BASED ON RESULTS

Low-scoring users are moved to another time cell.

CH12-F05 — PACKING ONE COUNTRY INTO ONE SLOT

Time effect gets mixed with country effect.

CH12-F06 — GENERATING ARTIFICIAL LOAD

Thousands of users send simultaneously, triggering the product's abnormal error behaviour.

CH12-F07 — HIDING NIGHT PARTICIPATION

Fatigue and participation loss are not reported in certain areas.

CH12-F08 — ADDING OFF-WAVE OBSERVATION TO THE WAVE

A response received hours or days later is used as if it belonged to the main window.

CH12-F09 — COUNTING LOAD TIME AS CAPTURE TIME

It cannot be proven when the file was generated.

CH12-F10 — BLIND TRUST IN DEVICE CLOCK

Manually changed or incorrect time becomes the main time record.

CH12-F11 — EXCLUDING DELAYED NEGATIVE RESPONSE

The time rule is applied dependent on the outcome.

CH12-F12 — DELETING THE FIRST CONTACT RESULT

The speed limit, error, or rejection is made invisible with the second attempt.

CH12-F13 — COUNTING REJECTION AS TECHNICAL ERROR

The actual system behaviour is retried.

CH12-F14 — COUNTING WRONG RESPONSE AS TECHNICAL ERROR

Regeneration is done until the desired result occurs.

CH12-F15 — IGNORING PARTIAL RESPONSE

Even if the system is interrupted, only the subsequent complete response is saved.

CH12-F16 — SELECTING THE BEST RESPONSE

Among multiple answers, the most positive or longest one is reported.

CH12-F17 — SCREENSHOT ONLY

The visual is considered sufficient without prompt, product, time, and metadata.

CH12-F18 — CROPPED SUCCESS VISUAL

Incorrect or restrictive parts are left invisible.

CH12-F19 — CAPTURE NOT SHOWING THE PROMPT

It cannot be proven which question the answer belongs to.

CH12-F20 — TRUNCATING THE END OF THE ANSWER

Material limitation or rejection part becomes invisible.

CH12-F21 — GAP IN CONSECUTIVE VISUALS

Some parts of the answer are lost.

CH12-F22 — COUNT OCR TEXT AS RAW ANSWER

Recognition errors change material claims.

CH12-F23 — CONSIDER ONLY THE LATEST VERSION OF DYNAMIC RESPONSE AS REAL

The initial user exposure is deleted.

CH12-F24 — CONSIDER USER INTERRUPTION AS COMPLETE ANSWER

The system output is incomplete due to user intervention.

CH12-F25 — INCORRECTLY MATCH SEPARATE PROMPT AND ANSWER

Files from different chats are linked to the same observation.

CH12-F26 — HASH WORSHIP

Any file with a hash is considered real and original.

CH12-F27 — IGNORE PRE-HASH EDITING

Truncated or modified files are legitimised by hashing.

CH12-F28 — CONSIDERING THE SIGNATURE AS VALID

Signed but incorrect record is accepted without dispute.

CH12-F29 — EDITING ON THE RAW FILE

Original evidence is irreversibly altered.

CH12-F30 — CONSIDERING THE EDITED DERIVATIVE AS RAW EVIDENCE

Public copy is used like the original file.

CH12-F31 — REMOVING PRIVACY FOR EVIDENCE

Participant's name, account, and private chat are published.

CH12-F32 — REVEALING A PARTICIPANT FROM A SMALL COUNTRY

Time, device, and plan information make a person re-identifiable.

CH12-F33 — COLLECTING SPECIAL HISTORY IN THE NATURAL PANEL

Irrelevant conversations enter the capture.

CH12-F34 — INVALIDATING ACCESSIBILITY EVIDENCE

The real user is excluded because a standard visual cannot be generated.

CH12-F35 — ASSUMING THE CAPTURE TOOL IS NEUTRAL

The tool changes the product behaviour but is not tested.

CH12-F36 — HIDING THE CAPTURE VERSION

Different tool versions are presented as a single measurement method.

CH12-F37 — CONSIDERING THE CAPTURE TOOL ERROR AS AN AI ERROR

The cut response is uploaded to the product.

CH12-F38 — COUNTING THE API LOG ON THE USER SCREEN

The real user surface becomes invisible.

CH12-F39 — COUNTING THE PROVIDER LOG AS INDEPENDENT EVIDENCE

The record of the measured party becomes a single piece of evidence.

CH12-F40 — HIDING THE PRODUCT UPDATE

Two system states within the branch melt into a single score.

CH12-F41 — IGNORING CHANGES IF NO ANNOUNCEMENT

The observed system break is not examined.

CH12-F42 — EXCLUDING EXTERNAL EVENTS BASED ON OUTCOME

Responses with negative news are removed; responses with positive news are kept.

CH12-F43 — LINKING WAVE HEALTH TO SCORE

Defective waves with high scores are valid, strong waves with low scores are considered suspicious.

CH12-F44 — COUNTING THE CORRECT ANSWER AS A VALID CAPTURE

The evidence defect is covered up by semantic success.

CH12-F45 — COUNTING THE WRONG ANSWER AS AN INVALID CAPTURE

The measurement result is converted into data error.

CH12-F46 — COUNTING THE SAME TEXT AS BOT EVIDENCE

Deterministic or similar AI responses accidentally become duplicates.

CH12-F47 — SINGLE SIGNAL TAMPER DECISION

File size or time difference automatically creates an exclusion.

CH12-F48 — ADD OBSERVATION AFTER WAVE

New records are quietly added to reach the desired sample size.

CH12-F49 — REMOVE LOW-SCORED OBSERVATION AFTER WAVE

Manifest and outcome are retroactively changed.

CH12-F50 — DELETE OLD MANIFEST

Version history is destroyed.

CH12-F51 — CORRECT RAW EVIDENCE

File content is modified to correct misclassification.

CH12-F52 — DENY WITHDRAWAL RIGHT

Immutability is held above human rights.

CH12-F53 — CLOSED PROPRIETARY CAPTURE MONOPOLY

Only evidence produced with the founder's tool is considered valid.

CH12-F54 — NOT PUBLISHING THE CAPTURE SCHEMA

An independent team cannot establish the same chain of evidence.

CH12-F55 — CONSIDERING THE WAVE ROOT AS EVIDENCE OF REALITY

The Merkle or hash root is presented as if it proves content accuracy.

CH12-F56 — CLAIM OF “1,000 SCREENSHOTS” WITHOUT AN EVIDENCE PACKAGE

The number of files is used like the number of valid observations.

78. AUDIT PROCEDURE

Step 1 — Determine the Research Purpose of the Wave

Principal, confirmatory, incident, drift, or retest type is selected.

Step 2 — Lock AI Product and System States

It connects to the wave version of the AI System Register in Section 9.

Step 3 — Lock Population, Sample, and Panel States

Records from Sections 5–8 and Section 11 are used.

Step 4 — Lock Prompt Register

Prompt versions in Section 10 are linked to the wave.

Step 5 — Set UTC Wave Window

Start, closing, and additional durations are written.

Step 6 — Create Micro-Slots

Participants are assigned to slots in a balanced way in terms of product, country, and language.

Step 7 — Define Time Source

The server, device, and trusted UTC records are determined.

Step 8 — Lock First Contact and Retry Rules

Technical and semantic states are separated.

Step 9 — Determine Capture Methods

Web, mobile, accessibility, and natural panel paths are defined.

Step 10 — Determine NCL Target

Record the capture-confidence level required for the principal analysis.

Step 11 — Lock Evidence Package Schema

Manifest, files, hash, and metadata fields are defined.

Step 12 — Lock Privacy and Redaction Rules

Raw, audit, and public layers are separated.

Step 13 — Capture Your Vehicle with the Pilot

Does the vehicle change product behaviour? Are the time and text records correct?

Step 14 — Open the External Event Register

A process is established to monitor product and entity events.

Step 15 — Confirm Wave Lock

WS-1 — LOCKED status is given.

Step 16 — Open the Slots

Participants are only allowed to submit in their own slots.

Step 17 — Record the First Contact Result

Answer, rejection, error, or limit is separated.

Step 18 — Capture the First Suitable Output

The full answer is preserved without renewal.

Step 19 — Create Raw Evidence and Metadata

Screenshots, raw text, system status, and timestamps are recorded.

Step 20 — Perform Local Hash and Secure Upload

Files receive an integrity record before uploading.

Step 21 — Server Acceptance and Create Package Hash

The evidence chain is closed with server time and package ID.

Step 22 — Blind Review of Capture Validity

The CV status is assigned without knowing semantic success.

Step 23 — Perform Duplicate and Tamper Review

Multiple signals and human review are used.

Step 24 — Examine the System Within the Wave and External Events

Determine whether a sub-wave or mixed-state is required.

Step 25 — Assign Wave Health

Status is assigned between WH-0 and WH-5.

Step 26 — Generate Wave Manifest and Integrity Root

Observation list is versioned.

Step 27 — Publish Public Proof Manifest

Scope and integrity are made visible without personal data.

Step 28 — Approve Wave Closure Report

Targets, occurrences, defects, events, and changes are closed with human approval.

79. NECESSARY EVIDENCE

Wave ID Wave type Protocol version AI System Register version Population frame Sample lock Panel status lock Prompt Registry version Reference package version UTC start and end time Micro-slot list Participant–slot assignment Time source Device clock deviations Transmission times First contact times Completion times Capture times Hash times Upload times Server acceptance times First contact results First suitable content outputs Technical retry records Partial response records Rejection and usage limits Full raw responses Full screenshots Sequential visual manifests Screen recordings, if any Citation and source records System settings evidence Capture tool and version Capture method NCL level File hashes Package hash

Digital signature Timestamp Duplicate checks Tamper checks Capture validity decisions Redaction files Raw-to-redacted links Privacy manifest Withdrawal records Product change events External Event Register Wave sub-divisions Slot scope Country and language scope Technical error rates Capture validity rate Wave health status Wave integrity root Public evidence manifest Wave closure report Change log Responsible person or institution

80. AUDIT CHECKLIST

Is the type and purpose of the wave clear? Have AI products and system statuses been locked? Are the population, sample, and panel versions determined? Was the prompt set locked before the results? Is the UTC wave window open? Were micro-slots pre-assigned? Were countries and languages distributed evenly across slots? Did participants switch slots based on their results? Was local time load evaluated? Are there rotating wave hours? Are submission and completion extra times clear? Was the device clock compared with a reliable UTC source? Were submission, completion, capture, and upload times separated? Did out-of-wave observations enter the main score? Was the first contact result recorded? Was technical error distinguished from rejection?

Was a retry made due to an incorrect answer? Was the first attempt preserved in the technical retry? Were partial answers deleted? Is the first suitable output really the first output? Was Regenerate or a follow-up message used? Does it show the visual prompt and the entire answer? In long answers, is there capture without spaces? Does the raw text match the visual? If OCR was used, is there human verification? Were dynamic answer versions retained? Did the user stop the answer? Are the prompt and answer linked to the same session? Is the capture tool and version recorded? Did the capture tool alter user behaviour? Was the NCL level given? Are there observations below NCL-3 in the main analysis? Does each file have a hash? Is it clear what the hash does not prove?

Is there a digital signature or server time? Is the capture time separate from the upload time? Is there a reason for late upload and a local integrity log? Was redaction performed on the raw evidence? Do the edited derivatives have separate hashes? Does the public manifest reveal the participant's identity? Can a user from a small country be re-identified? Were private conversations unnecessarily captured in the natural panel? Was an alternative evidence path provided for accessibility users? Was the duplicate decision based only on the same text? Does the tamper decision carry multiple signals? Did the capture validator know the semantic score? Did the correct answer cover up the evidence flaw? Was the incorrect answer invalidated? Did the product change during the wave?

Was the product change processed as an underwave or mixed-state? Were external events recorded? Did external events cause exclusion according to the result? Is the wave health status independent of the score? After the wave was closed, were observations added or removed? Are the old manifest and integrity root preserved? How were participant withdrawal requests handled? Is there a public proof manifest? Is there a clearly accountable owner of the wave closure report?

81. OBJECTIONS AND RESPONSES

Objection 1 — “If all users do not submit at the same second, true simultaneity is not achieved.”

One-second submission can create artificial load, connection, and queue effects. A predefined short UTC window and random micro-slots can measure the same system period more reliably.

Objection 2 — "The product can change within a one-hour window."

It can change. Therefore, system records, configuration fingerprint, and product change tracking are required. In case of a material change, the wave is separated.

Objection 3 — "Why isn’t just a screenshot enough?"

Screenshot:

• time,
• initial output,
• prompt version,
• system setting,
• copying

do not always show these subjects. A complete evidence package is required.

Objection 4 — "Isn’t it too burdensome to verify a thousand screenshots one by one?"

It is heavy. Automatic integrity checks, sample-based human review, and risk-based verification can be used. Critical or suspicious records are examined in more detail.

Objection 5 — “If there is a hash, why can't we say that the file is real?”

A hash only shows that the file remained the same after the hash was generated. It does not show how the file was created before the hash.

Objection 6 — “If the user has to trim personal information, how will the raw file be protected?”

If possible, the Capture tool should not capture personal information from the start. If unavoidable, the raw file is kept in a restricted and encrypted repository, and a public copy is kept as a separately redacted derivative.

Objection 7 — “If the response is wrong, why don't we try again?”

Because a wrong answer is a matter of measurement. Retrying is only for an actual technical failure.

Objection 8 — “If the system rejects, can the user actually try again?”

Correct. The main first-contact panel preserves the rejection. A separate Natural Interaction Track can measure the user's follow-up behaviour.

Objection 9 — “If a technical error is a user experience issue, why do we allow retry?”

The technical error is preserved as a result of the first contact. A predefined technical retry can be done to additionally examine the representative content. The two results do not replace each other.

Objection 10 — “Isn't the provider's own log the strongest evidence?”

Technically, it can be very strong. The provider is the owner of the measured system. It is more reliable when used together with an independent user capture.

Objection 11 — “Will NOMOS Capture be a mandatory NobleJackal software?”

No. NOMOS Capture is an open evidence protocol. Independent tools that meet the equivalent schema and integrity conditions can be compatible.

Objection 12 — “If we do not make all evidence public, how will independent verification be done?”

The public manifest shows integrity and scope. Authorised independent auditors can access redacted or limited raw evidence. Privacy and verification can be designed together.

Objection 13 — “Wouldn't the whole work be disrupted if important news breaks during the wave?”

Not always. The report is part of the real system environment. It can be separated with a timestamp before and after the event. The scope of the score is explained accordingly.

Objection 14 — “Isn't it easier to discard old answers and continue with the new system when a product is updated?”

Old answers are real on the measurement date. They cannot be deleted. Old and new system statuses must be maintained as separate waves or sub-waves.

Objection 15 — “If the capture tool affects product behaviour, does the whole method fail?”

No. The vehicle effect is measured with the pilot. If necessary, a lighter vehicle, manual capture, or a method that uses the vehicle effect as a separate factor is chosen.

Objection 16 — "If the participant withdraws their data, wouldn't the integrity root be compromised?"

A new manifest version and a new root are created. The old record can retain a contentless WITHDRAWN trace. It is maintained on top of the human rights evidence architecture.

COMMON JUDGEMENT OF SECTION 85

At the end of a GEO-1000 study, you may have 30,000 screenshots. This number alone is not evidence. You need to know: Which wave were they produced in? To which system state did they belong? Was the same prompt actually sent? Was it the first output? Was the response refreshed? Did the product change during the wave? When was the file captured? When was the hash generated? Was the participant ID repeated? Does the visual show the entire answer? Does the raw text match the visual? If the evidence was later edited, where is the original? Was capture verification done before the semantic score? You can click a thousand times within the same second. Still:

• device clocks,
• connections,
• queues,
• product states

It can be different. Therefore, concurrency is not a marketing show. It is a predefined time architecture. When a user gets a wrong answer: saying 'Try again.' is tempting. But that wrong answer is the reality you are trying to measure. If you delete it, you do not fix the system. You corrupt the evidence. When a user experiences a real connection error, a technical retry can be done. But the result of the first contact should still be preserved. Because the user first encountered the error. The hash is valuable. The digital signature is valuable. The timestamp is valuable. The screenshot is valuable. None of these alone carries the whole truth. Trust:

• prompt,
• time,
• product,
• user,
• file,
• initiative,
• verification

It arises from the joint preservation of its chain. A standard: if it says, “Only proof produced with my software is valid,” it places its own interest before independent replication. For this reason, NOMOS Capture is not a tool brand, but an open proof architecture. Independent universities, researchers, or audit institutions should be able to apply the same rules. Therefore, NOMOS's twelfth measurement law is as follows:

Concurrency is observable reproducibility within the same defined system time, not the same second.

The thirteenth law is as follows:

The first output is not a draft that can be renewed until one likes the result.

The fourteenth law is as follows:

Hash preserves proof; it does not create proof.

The fifteenth law is as follows:

Capture validity and response accuracy are independent of each other.

Its sixteenth law is as follows:

The chain of evidence should make the integrity of the observation visible, not the identity of the person.

Its seventeenth law is:

If the system changes during the wave, it cannot act as if the measurement history has not changed.

Its eighteenth measurement law states:

Nothing is written on raw evidence; decisions are corrected through versioning.

Its nineteenth measurement law states:

A capture method that cannot be applied independently cannot be a world standard.

Order of Section 12 of NOMOS

Don’t tell me "we asked at the same time." / Show in which UTC window, in which slot, and in which system state you asked.

Do not pile a thousand people into the same second to produce artificial error. / Spread the time but keep the system within the same wave.

Do not mix local times with each other. / Do not make the device time absolute truth.

Do not save the result of the first contact. / Save the usage limit, retries, error, and clarification separately.

Do not regenerate when you get a wrong answer. / That wrong answer is my real behaviour.

You can retry when a technical error occurs. / But do not delete the first error.

Do not bring me only a screenshot. / Bring the prompt, full answer, product, time, setting, interference chain, and file integrity.

Do not trim the good part of your answer. / Leave the end, boundary, and error visible.

Do not declare the hash as reality. / Prove what was before the hash as well.

Do not redact the raw file itself. / Preserve the original and produce a separate public copy.

Do not publish a person's name, account, or private conversation as evidence.

Do not make the only participant in a small country identifiable.

Do not declare your capture tool neutral without testing whether it altered me.

If the system changed in the middle of the wave, do not merge old and new answers as if they belong to a single product.

If an external event changed it, record the event. / Do not delete the observation because you did not like the score.

Keep the evidence fixed. / If the decision is wrong, correct it with a new version.

Do not tie the capture standard to a single company's closed software. / Let others be able to establish the same proof chain.

First, lock the wave. / Then distribute the time. / Then capture the first output. / Then hash it. / Then upload securely. / Then verify the capture without checking its accuracy. / And only after this, decide what your answer says.

The Chapter's Closing Sentence

An answer in GEO-1000 becomes a true unit of measurement only when it can be shown under which system state, at what moment, from which prompt, and within which immutable proof chain it originated.

Normative Core

Every GEO-1000 observation MUST be linked to a predeclared and versioned measurement wave defining: - AI product states, - population and sample frames, - panel states, - prompt versions, - UTC dispatch window, - randomised micro-slots, - completion and capture deadlines, - technical-retry rules, - capture schema, - reference-record versions, - and governance ownership. Synchronisation MUST mean observation within a declared UTC system-state window and assigned slot structure. It MUST NOT be represented as perfect millisecond simultaneity. Every observation MUST preserve, as available: - assignment time, - prompt-submission time, - first system event, - response-completion time, - capture time, - hash-creation time, - upload time, - and server-acceptance time. The first contact outcome MUST remain visible. A technical retry MAY be used only under predeclared infrastructure-failure conditions and MUST retain every prior attempt. Incorrect, unfavorable, refused, uncited, truncated, or critical outputs MUST NOT be regenerated, replaced, or excluded merely because of their content. A NOMOS Capture evidence bundle MUST retain the exact assigned and sent prompt, complete raw response, full visual evidence, system-state metadata, attempt log, time evidence, file hashes, bundle hash, capture tool version, privacy status, and blinded capture-validity decision. A screenshot, hash, digital signature, provider log, or timestamp MUST NOT individually be represented as complete proof of observation authenticity. Raw evidence MUST remain immutable or append-only. Redactions, corrections, withdrawals, exclusions, and adjudication changes MUST create linked versions and preserve the prior record where ethically and legally permissible. Material AI-product changes or external events during a wave MUST be time-recorded and handled through sub-waves, explicit modelling, restarting, or mixed-state warnings. Capture validity MUST be decided independently of semantic correctness. Public evidence manifests MUST support verification without unnecessarily exposing participant identity, credentials, private conversation history, or precise location. NOMOS Capture compliance MUST be implementable through open, equivalent evidence systems and MUST NOT depend exclusively on a proprietary tool controlled by the standard's founder. Every wave, evidence bundle, capture decision, manifest revision, and integrity record MUST be versioned and attributable to an accountable human or organisation.