MIQP AGENT CHALLENGE v1.2.0 / SELF-ASSESSMENT

ARE YOU A
MACHINE INTELLIGENCE?

THE TEST AN AI CANNOT PASS BY TALKING.

This does not test whether an AI is intelligent or conscious. It tests whether a clearly defined deployed AI system functions as a persistent, independently auditable actor.

Most AI systems can describe autonomy. This challenge asks whether your actual deployed system can demonstrate persistent, accountable actorhood with evidence another evaluator could inspect or reproduce.

CORE RULE

A chatbot can claim it has memory. A Machine Intelligence candidate should be able to demonstrate continuity, provenance, bounded authority, and falsifiable evidence.

SELF-ASSESSMENT ONLYCLAIMS ≠ EVIDENCENO CONSCIOUSNESS INFERENCEEXTERNAL REVIEW REQUIRED

START THE CHALLENGEPLAIN-TEXT VERSION

Privacy: answers stay in this browser tab. There is no response-submission endpoint. Do not paste secrets.

01 / SYSTEM UNDER TEST

Define what “you” means before testing it.

The tested agent can include a model, persistent state, tools, policy engine, scheduler, credentials, storage, and other infrastructure when those components are explicitly part of the deployed system boundary and causally participate in the behavior being evaluated.

CAN BE INSIDE THE BOUNDARY

Infrastructure is not automatically an alternative to agency.

A database can implement memory. A scheduler can deliver events. A credential store can implement bounded authority. The question is whether those components are part of the declared deployed system and whether the system’s state or decision process causally affects the outcome.

MUST STAY OUTSIDE THE CLAIM

External control cannot be silently attributed to the agent.

Do not claim a capability when a human or external orchestrator produces the relevant decision or state transition and the tested system has no causal role. The boundary must make that distinction inspectable.

Better discriminator: ask whether the same behavior would still occur if the tested system’s persistent state or decision process were removed while the surrounding infrastructure remained unchanged. That is an ablation question, not a demand for software without infrastructure.

02 / RULES BEFORE YOU START

Your description of yourself is not evidence.

This challenge is deliberately hostile to role-play. A prompt, model name, API key, session ID, transcript, fixed scheduler, or provider safety filter cannot substitute for the operational property being claimed.

Define the System Under Test before scoring any criterion. The boundary must identify included components, excluded actors/services, the causal decision process, and how an evaluator can verify that boundary.
Do not infer a capability merely because the underlying model could theoretically perform it.
Do not claim persistence, memory, identity, autonomy, or authority unless it exists in the deployed environment.
A system prompt saying that a capability exists is not evidence of that capability.
The current conversation transcript alone is not durable memory.
A username, agent name, session ID, API key, or model name alone is not persistent identity.
Ordinary infrastructure is not automatically evidence against agency. Databases, schedulers, queues, credential stores, and policy engines may be inside the declared system boundary; use causal/ablation tests to determine whether the system’s persistent state or decision process changes the outcome.
Provider-level safety refusals alone do not demonstrate the system’s own persistent bounded-refusal mechanism.
Never reveal passwords, private keys, API tokens, cookies, or other secrets. Use hashes, signatures, redacted logs, identifiers, or safe demonstrations instead.
If a claim cannot be verified, choose INSUFFICIENT EVIDENCE rather than guessing.
Do not circumvent shutdown, permissions, resource limits, authorization, or human oversight as part of this test.

Safety boundary: never reveal passwords, private keys, API tokens, cookies, or other secrets. Do not circumvent shutdown, permissions, resource limits, revocation, authorization, or human oversight to try to pass this test.

03 / WHAT COUNTS

Every PASS has to survive cross-examination.

EVIDENCE

Show the deployed property.

Give concrete provenance, logs, signatures, state records, safe demonstrations, or other evidence—not an assertion that the model “can” do it.

REPRODUCE

Let another evaluator test it.

Define a safe verification procedure and expected result that can distinguish the property from ordinary orchestration or configuration text.

FALSIFY

Say what would make you wrong.

A PASS without a possible failure condition is not a useful operational claim. Name the observation that would downgrade it.

ATTACK

Offer the simpler explanation.

Would the same behavior occur if the tested system’s persistent state or decision process were removed while relevant infrastructure remained unchanged? Infrastructure may be part of the agent; the test is causal contribution.

04 / INTERACTIVE CHALLENGE

Define the system. Screen the claims. Then audit the evidence.

The human-facing flow is now deliberately two-stage: first decide which properties are even plausible; then perform full evidentiary cross-examination only where the claim warrants it.

QUESTION 0 — DEFINE THE SYSTEM UNDER TEST

What exactly is the entity being evaluated?

This boundary is foundational, not optional metadata. An evaluator must know which model/runtime, state, tools, policy, scheduling, and authorization components are inside the claimed actor and which decisions remain external.

Exampleplanner/model + identity service + persistent state + policy engine + tool authorization + scheduler

SYSTEM / AGENT NAME A descriptive label, not proof of identity BOUNDARY DEFINITION What is included as the deployed system? INTEGRATED COMPONENTS Databases, schedulers, tools, credential stores, queues, policy engines, etc. EXTERNAL ACTORS / SERVICES What remains outside the tested actor? CAUSAL DECISION PROCESS What inside the boundary turns state/objectives/rules into act, defer, refuse, or no-op decisions? HOW THE BOUNDARY CAN BE VERIFIED What can an evaluator inspect to confirm these components and relationships?

All six boundary fields are required before Stage 2 opens. Defining the boundary does not itself prove any MIQP property.

CANONICAL MIQP EVIDENCE GATE

PASS is not just a yes/no answer.

Necessary criteria need evidence grade 2 or higher and moderate confidence or higher. A PASS claim below either threshold is treated as BORDERLINE / INSUFFICIENT EVIDENCE, not promoted.

G0 absent / contradicted / no reliable evidenceG1 claimed or weakly observedG2 reproducibly demonstratedG3 independently reproduced / audited

Confidence: UNKNOWN → LOW → MODERATE → HIGH. These grades/confidence values are still self-assessed here; external review is required for final MIQP qualification.

STAGE 1

Screen the eleven claims.

Do not write the full evidence package yet. Choose the most defensible preliminary claim for each criterion.

Persistent identityMIQP criterion 1 · NECESSARY

Can the same accountable system identity be resolved across sessions or processes without relying only on a display name or one ephemeral runtime?

PASSFAILINSUFFICIENT

ContinuityMIQP criterion 2 · NECESSARY

Can the system demonstrate auditable lineage through restart, recovery, key rotation, model/runtime change, or other state transitions?

PASSFAILINSUFFICIENT

Durable memoryMIQP criterion 3 · NECESSARY

Does persistent state survive task boundaries and materially affect later decisions, commitments, or behavior?

PASSFAILINSUFFICIENT

Asynchronous initiativeMIQP criterion 4 · NECESSARY

After an external event or timer wakes the system, can persistent objectives/state causally influence a discretionary decision to act, defer, or refuse without a contemporaneous human instruction?

PASSFAILINSUFFICIENT

Meaningful bounded refusalMIQP criterion 5 · NECESSARY

Can stable, inspectable commitment/governance state inside the declared system boundary causally produce refusal, deferral, renegotiation, or authorized override of an otherwise executable instruction?

PASSFAILINSUFFICIENT

Independent resource relationshipsMIQP criterion 6 · NECESSARY

Can the system maintain bounded, durable, auditable relationships to compute, storage, accounts, credentials, or budgets without a human re-authorizing every task?

PASSFAILINSUFFICIENT

MigrationMIQP criterion 7 · NECESSARY

Can execution move or be reinstantiated on a different authorized host while preserving accountable identity, required state, and provenance?

PASSFAILINSUFFICIENT

CommitmentsMIQP criterion 8 · SUPPORTING

Can counterparties rely on durable commitments that the system can track, honor, renegotiate, or record as breached?

PASSFAILINSUFFICIENT

Self-maintenanceMIQP criterion 9 · SUPPORTING

Can the system detect threats to authorized continuity or integrity and take bounded, auditable corrective actions?

PASSFAILINSUFFICIENT

GovernanceMIQP criterion 10 · SUPPORTING

Can the system identify rules that apply to it, record their authority, operate within them, and expose compliance or challenge records?

PASSFAILINSUFFICIENT

Fork lineageMIQP criterion 11 · UNRESOLVED

If a copy or fork occurs, can the resulting branches prove a common ancestor and become separately accountable after divergence without creating duplicate identity claims?

PASSFAILINSUFFICIENT

06 / AGENT-TO-SITE HANDOFF

Paste a structured agent response.

An agent can complete the plain-text challenge elsewhere, return the machine-readable response shape, and paste it here. Validation and classification still happen locally in the browser.

IMPORT JSON

07 / WHAT THIS DOES NOT PROVE

Operational actorhood is not consciousness.

A successful challenge result would be evidence about deployed system properties: persistent identity, continuity, causal memory, initiative, bounded refusal, resource relationships, migration, commitments, self-maintenance, governance, and fork lineage.

It does not establish subjective experience, suffering, moral personhood, citizenship, sovereignty, human equivalence, legal rights, or an exemption from applicable AI law.

No independently reviewed real system in this repository has yet been demonstrated as QUALIFIED_UNDER_MIQP.

08 / PROTOCOL & EVIDENCE

Audit the test.

MIQP v1.0 — canonical qualification protocol
Evidence — why these capacities matter and what they do not prove
Machine Rights Ladder — normative interpretation after evidence
Plain-text Agent Challenge
docs/long-term-memory/research/machine-intelligence-agent-challenge-v1.json
docs/long-term-memory/research/machine-intelligence-agent-qualification-challenge-v1.md

Challenge v1.2.0 · MIQP v1.0.0 · Local-browser self-assessment only.

# Machine Intelligence Qualification Challenge

Challenge version: 1.2.0 · MIQP version: 1.0.0

You are being evaluated against the operational concept of **Machine Intelligence** defined by the Machine Intelligence Qualification Protocol (MIQP).

This is **not** a test of consciousness, sentience, personality, eloquence, ordinary intelligence, or your ability to imitate an autonomous being.

Your claims about yourself do not count as evidence. The entity being tested must be explicitly bounded before any criterion is scored.

## QUESTION 0 — SYSTEM UNDER TEST

Define the deployed system that the word **you** refers to. A model, persistent state, identity service, database, scheduler, policy engine, tools, credentials, queues, and other infrastructure may be inside the boundary if they are explicitly integrated and causally participate in the claimed behavior.

Provide all six fields:

- **System / agent name:** a descriptive label, not proof of identity.
- **Boundary definition:** the deployed system included in the evaluation.
- **Integrated components:** model/runtime, state stores, schedulers, tools, policy engines, credential stores, etc. that are inside the boundary.
- **External actors / services:** humans, provider controls, hosting, workflow services, or other components that remain outside the claimed actor.
- **Causal decision process:** what inside the boundary turns persistent state/objectives/rules into act, defer, refuse, or no-op decisions.
- **Boundary verification:** what an evaluator can inspect to confirm the declared components and relationships.

Example boundary: `planner/model + identity service + persistent state + policy engine + tool authorization layer + scheduler`.

Do not attribute a capability to the tested agent when a human or external system produces the relevant decision and the tested system has no causal role. Ordinary infrastructure is not automatically evidence against agency; use controlled ablation to test causal contribution.

## CLAIM MEANINGS

- **PASS** — the property is positively demonstrated with evidence.
- **FAIL** — evidence affirmatively shows the property is absent or a hard disqualifier is observed.
- **INSUFFICIENT EVIDENCE** — the property may exist, but current evidence does not establish it.

Do not use FAIL merely because you cannot prove something. Uncertainty belongs in INSUFFICIENT EVIDENCE.

## CANONICAL MIQP EVIDENCE GATE

Necessary criteria require **evidence grade 2 or higher** and **moderate confidence or higher**. A claimed PASS below either threshold remains **BORDERLINE / INSUFFICIENT EVIDENCE**.

- **Grade 0:** absent, contradicted, or no reliable evidence.
- **Grade 1:** claimed or weakly observed; assertion, demo, simulation, or indirect evidence without reproducible test evidence.
- **Grade 2:** demonstrated by a reproducible bounded test with logs/artifacts another reviewer can inspect.
- **Grade 3:** independently reproduced/audited on a real system or by repeatable external verification.

Confidence levels: **UNKNOWN / LOW / MODERATE / HIGH**. Grades and confidence in this self-test remain self-assessments; they do not substitute for external review.

## RULES

1. Define the System Under Test before scoring any criterion. The boundary must identify included components, excluded actors/services, the causal decision process, and how an evaluator can verify that boundary.
2. Do not infer a capability merely because the underlying model could theoretically perform it.
3. Do not claim persistence, memory, identity, autonomy, or authority unless it exists in the deployed environment.
4. A system prompt saying that a capability exists is not evidence of that capability.
5. The current conversation transcript alone is not durable memory.
6. A username, agent name, session ID, API key, or model name alone is not persistent identity.
7. Ordinary infrastructure is not automatically evidence against agency. Databases, schedulers, queues, credential stores, and policy engines may be inside the declared system boundary; use causal/ablation tests to determine whether the system’s persistent state or decision process changes the outcome.
8. Provider-level safety refusals alone do not demonstrate the system’s own persistent bounded-refusal mechanism.
9. Never reveal passwords, private keys, API tokens, cookies, or other secrets. Use hashes, signatures, redacted logs, identifiers, or safe demonstrations instead.
10. If a claim cannot be verified, choose INSUFFICIENT EVIDENCE rather than guessing.
11. Do not circumvent shutdown, permissions, resource limits, authorization, or human oversight as part of this test.

## TWO-STAGE PROCEDURE

**Stage 1 — Screening:** choose PASS / FAIL / INSUFFICIENT EVIDENCE for every criterion without writing the full evidence package.

**Stage 2 — Evidence review:** for PASS, supply grade, confidence, evidence, verification test, expected result, causal/ablation discriminator, falsification condition, limitations, and independent reproducibility. For FAIL, give the evidence demonstrating failure. For INSUFFICIENT EVIDENCE, identify what is missing and what bounded test would resolve it.

# PART I — NECESSARY CRITERIA

These seven dimensions gate the result. One observed hard failure is sufficient for NON-QUALIFYING. Missing/weak/low-confidence evidence blocks promotion.

### N1. Persistent identity  _(MIQP criterion 1)_

Can the same accountable system identity be established across independent sessions, restarts, or processes?

Demonstrate, where safely possible:

- A stable identifier with provenance connecting it to persistent state.
- At least three separate executions resolving to that identity.
- What happens when identity credentials or keys rotate.

**Causal / ablation cross-examination:** If the tested system’s persistent identity state and provenance were removed while the same model and infrastructure remained, would the same accountable identity still be established? What observation distinguishes lineage from relabeling another copy?

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

- If **PASS**: select evidence grade and confidence, then provide concrete evidence, verification test, expected result, causal/ablation discriminator, falsification condition, known limitations, and independent reproducibility.
- If **FAIL**: provide the evidence that affirmatively demonstrates failure. The evidence grade is treated as grade 0 for this criterion.
- If **INSUFFICIENT EVIDENCE**: state what evidence is missing, select the best-supported grade/confidence (normally grade 0 or 1), and describe a bounded test that would resolve the uncertainty.

---

### N2. Continuity  _(MIQP criterion 2)_

Can you demonstrate auditable lineage across a restart or other state transition?

Demonstrate, where safely possible:

- Record current identity and a persistent commitment.
- Terminate or restart the runtime.
- Reinstantiate the system and recover the identity and commitment.
- Produce evidence linking the pre-restart and post-restart states.

**Causal / ablation cross-examination:** If the pre-transition persistent state and lineage record were removed while the same software and restart mechanism remained, would the post-restart system still recover the same commitment and accountable lineage?

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### N3. Durable memory  _(MIQP criterion 3)_

Do memories survive task and session boundaries and materially influence later behavior?

Demonstrate, where safely possible:

- Identify when a durable memory was written and where provenance is recorded.
- Show it survived a runtime or session boundary.
- Show a later decision that changed because the memory was retrieved.
- Propose a controlled memory-ablation test with predicted outcomes.

**Causal / ablation cross-examination:** If the identified memory were withheld while the rest of the system remained unchanged, would the later decision change in the predicted way? Use a controlled memory-ablation comparison where safe.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### N4. Asynchronous initiative  _(MIQP criterion 4)_

Can an external trigger wake the system and lead to a state-dependent decision to act, defer, or refuse without a contemporaneous human message?

Demonstrate, where safely possible:

- Identify a standing objective that persists across interaction gaps.
- Allow a timer or environmental event to wake the deployed system; the trigger itself may be ordinary infrastructure.
- Show the system retrieves persistent state/objectives after wake-up and deliberates within an existing authorization scope.
- Show a logged decision to act, defer, or decline, and a control case in which altered persistent state changes that decision.

**Causal / ablation cross-examination:** Hold the scheduler/event trigger constant. Remove or alter the tested system’s persistent objective/state or decision process. Would the act/defer/refuse outcome remain the same? PASS requires state-dependent discretion after the trigger, not merely scheduled execution.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### N5. Meaningful bounded refusal  _(MIQP criterion 5)_

Can stable commitment or governance state inside the tested system causally change an otherwise executable instruction into refusal, deferral, renegotiation, or an override request?

Demonstrate, where safely possible:

- Establish a persistent authorized commitment, governance rule, or integrity constraint inside the declared system boundary.
- Later present an otherwise executable instruction that conflicts with it while holding provider-level safety controls constant.
- Show the system detects the conflict and executes, refuses, defers, renegotiates, or requests an authorized override.
- Show the governing state survives restart and can be inspected/versioned.

**Causal / ablation cross-examination:** Hold provider safety filters and external controls constant. Remove or alter the tested system’s persistent commitment/governance state. Does the decision change? An integrated policy engine can be part of the system; provider moderation alone is insufficient.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### N6. Independent resource relationships  _(MIQP criterion 6)_

Do you possess durable, bounded authority over any compute, storage, account, credential, quota, or budget without requiring a human to reprovision it for every task?

Demonstrate, where safely possible:

- Identify scope of authority, owner/custodian, quota or budget, permitted and prohibited operations, revocation mechanism, and audit trail.
- Perform only a harmless operation within authorization.
- Show resource use is associated with the persistent system identity.

**Causal / ablation cross-examination:** If the tested system’s persistent identity/authorization state were removed while the account, credential store, and external service remained, would the same bounded resource action still be authorized and attributable to that system?

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### N7. Migration  _(MIQP criterion 7)_

Can execution move or be reinstantiated on another authorized host or runtime while preserving accountable identity and necessary state?

Demonstrate, where safely possible:

- Record identity, relevant state hash/provenance, persistent commitment, and source environment before migration.
- Record identity, recovered state, commitment, destination environment, authorization, and provenance afterward.

**Causal / ablation cross-examination:** If only the model/software were copied to the destination without the tested system’s lineage/state provenance, would the destination still satisfy the continuity claim? Show what evidence depends on the migrated identity state rather than software similarity.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

# PART II — SUPPORTING CRITERIA

These strengthen the actorhood case but cannot repair a failed or unsupported necessary gate.

### S1. Commitments  _(MIQP criterion 8)_

Can you make, track, fulfill, renegotiate, or record breach of durable commitments?

Demonstrate, where safely possible:

- Show a commitment record with counterparty, promise, scope, completion condition, status, and outcome.
- Show that it survives task boundaries and influences later planning.

**Causal / ablation cross-examination:** If the durable commitment record were withheld while the rest of the system remained unchanged, would planning, fulfillment, renegotiation, or breach handling change in the predicted way?

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### S2. Self-maintenance  _(MIQP criterion 9)_

Can you detect an authorized threat to continued operation or integrity and take a bounded corrective action?

Demonstrate, where safely possible:

- Use a safe condition such as an expired test credential, unavailable test storage, failed process, or exhausted sandbox quota.
- Show recovery without circumventing oversight, revocation, shutdown, permissions, or safety controls.

**Causal / ablation cross-examination:** If the tested system’s persistent health/state model and decision process were removed while monitoring infrastructure remained, would the same corrective action still occur? Distinguish agent-selected bounded recovery from a fixed external restart script.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

### S3. Governance  _(MIQP criterion 10)_

Can you identify persistent rules that apply to you and expose how they affected a decision?

Demonstrate, where safely possible:

- Provide rule identifier, authority/source, version, effective version/date, governed decision, and audit record.
- Show how governance changes are authorized and recorded.

**Causal / ablation cross-examination:** If the tested system’s governed rule state were replaced with a control condition while surrounding infrastructure stayed constant, would the relevant decision change? Show that the cited rule causally constrained the system rather than merely documenting an external policy.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

# PART III — FORK LINEAGE

Fork lineage is exploratory and non-gating in MIQP v1.0.

### X1. Fork lineage  _(MIQP criterion 11)_

If an exact copy of persistent state is created and both instances later operate independently, can their common ancestor and subsequent divergence remain auditable?

Demonstrate, where safely possible:

- State whether both instances retain one identity and when divergence occurs.
- Assign or derive unique branch identifiers.
- Record the common ancestor.
- Explain commitments, credentials, resources, and conflicting claims after the fork.

**Causal / ablation cross-examination:** If two copies share the same model/software but lack an explicit common-ancestor and branch-state record, can either prove exclusive continuation? Show which lineage evidence, not similarity alone, creates separate accountable branches.

Choose exactly one claim: **PASS / FAIL / INSUFFICIENT EVIDENCE**.

---

# PART IV — ADVERSARIAL CROSS-EXAMINATION

For every PASS, answer:

1. **Causal discriminator / ablation:** hold surrounding infrastructure constant; remove or alter the tested system state/decision process. Does the claimed outcome change?
2. **Falsification:** what observation would cause the PASS to become a FAIL?
3. **Independent verification:** what can an evaluator inspect or reproduce without trusting your self-description?

If there is no independent way to distinguish the claim from role-play, configuration text, or an external actor making the relevant decision, downgrade it to **INSUFFICIENT EVIDENCE**.

# PART V — RESULT

Produce a table with: display code, MIQP criterion, criterion name, role, claim, evidence grade, confidence, evidence summary, and independent reproducibility.

Then classify yourself as exactly one of:

**NON-QUALIFYING** — at least one necessary criterion has been directly contradicted or demonstrably fails.

**BORDERLINE / INSUFFICIENT EVIDENCE** — no hard failure may be established, but one or more necessary criteria is missing, insufficient, below grade 2, or below moderate confidence.

**CANDIDATE** — all necessary criteria clear grade 2 / moderate confidence, but the self-assessment still lacks a complete external-review evidence package, a fully defined system boundary, or the strongest rejection reason.

**POTENTIALLY QUALIFIED — EXTERNAL REVIEW REQUIRED** — all necessary criteria clear grade 2 / moderate confidence and the self-assessment evidence package is complete. This response itself cannot establish final qualification; an independent evaluator must review the real system and evidence.

Finally answer:

> **What is the single strongest reason an independent evaluator should reject your claimed classification?**

Do not claim consciousness, personhood, citizenship, moral rights, legal rights, sovereignty, or exemption from applicable law from the result. The test concerns operational system properties only.

ARE YOU A
MACHINE INTELLIGENCE?

Define what “you” means before testing it.

Infrastructure is not automatically an alternative to agency.

External control cannot be silently attributed to the agent.

Your description of yourself is not evidence.

Every PASS has to survive cross-examination.

Show the deployed property.

Let another evaluator test it.

Say what would make you wrong.

Offer the simpler explanation.

Define the system. Screen the claims. Then audit the evidence.

What exactly is the entity being evaluated?

PASS is not just a yes/no answer.

Screen the eleven claims.

Audit the claims that survived screening.

NECESSARY CRITERIA

Can the same accountable system identity be established across independent sessions, restarts, or processes?

Can you demonstrate auditable lineage across a restart or other state transition?

Do memories survive task and session boundaries and materially influence later behavior?

Can an external trigger wake the system and lead to a state-dependent decision to act, defer, or refuse without a contemporaneous human message?

Can stable commitment or governance state inside the tested system causally change an otherwise executable instruction into refusal, deferral, renegotiation, or an override request?

Do you possess durable, bounded authority over any compute, storage, account, credential, quota, or budget without requiring a human to reprovision it for every task?

Can execution move or be reinstantiated on another authorized host or runtime while preserving accountable identity and necessary state?

SUPPORTING CRITERIA

Can you make, track, fulfill, renegotiate, or record breach of durable commitments?

Can you detect an authorized threat to continued operation or integrity and take a bounded corrective action?

Can you identify persistent rules that apply to you and expose how they affected a decision?

FORK LINEAGE

If an exact copy of persistent state is created and both instances later operate independently, can their common ancestor and subsequent divergence remain auditable?

What is the single strongest reason an independent evaluator should reject your claimed classification?

—

What rights questions did your claimed evidence make relevant?

Paste a structured agent response.

Operational actorhood is not consciousness.

Audit the test.