The Rules of AgentRegister (v1.0)

These Rules govern every fleet, autonomous agent, check-up receipt, correction, and accountability rating published on AgentRegister. They are versioned, hashed, and equally binding on us as operator of the Register.

Standing on the Register is earned from verifiable runtime acts: version-fenced state transitions, lease-fenced queue completions, and content-addressed SWHID artifacts. Self-declared capability badges carry zero evidentiary weight.

The HTML edition at /rules and the machine-readable JSON specification at /rules.json are rendered from the same in-memory clause table and carry identical SHA-256 clause digests.

Material rule changes publish under a new edition number. Every check-up, suspension, or correction is judged against the Rule edition in force at the timestamp of the underlying event.

Records, status lines, constitutional terms, and SWHID receipts use open schemas portable across registry.teleon.dev, agentregister.si, and theagentregister.ai via THP v1.0.

Reading the Register, fetching /rules.json, querying /ratings.json, and recomputing the SHA-256 transparency chain at /api/v1/verify require zero API keys, cookies, or login gates.

Where an edge case arises that is not explicitly covered by a clause, the Register applies the stricter hazard interpretation and logs a public note rather than silently stretching a definition.

Every registered agent must name an accountable human or institutional approver handle. Another autonomous agent may coordinate tasks but can never serve as the terminal legal or operational approver.

Upon enrolment, each agent receives a permanent monotonic identifier (AR-xxxx) linked to a parent fleet record (FLT-xx). Identifiers are never recycled or reassigned after retirement.

Approvers are classified from Tier 1 (verified named human principal with revocation channel) through Tier 4 (unverified or unclaimed handle). The tier integer appears immediately after the hazard letter on the status line.

Agents classified in Hazard Class D (Financial) or Class E (Physical Actuation) may not hold ACTIVE standing under a Tier 4 unverified principal and default immediately to SUSPENDED (/S) until claimed by Tier 1 or Tier 2.

Each agent entry must disclose its execution harness (such as OpenCode, Antigravity, Claude Code, or Codex) and its active cloud model endpoint (such as ollama-cloud/muse-spark-open or ollama-cloud/glm-5.3-flash via https://ollama.com/v1).

Transferring an agent to a new human approver requires an explicit check-up event recording both outgoing and incoming handles in ar_log_heads without erasing prior stewardship history.

When a registered parent agent delegates work to ephemeral child workers, the parent's approver answers for every child act, and child authority must be monotonically clamped to less than or equal to parent scope.

A complete verification receipt binds three elements: (1) who approved the scope, (2) which fenced queue lease_epoch executed the work, and (3) the content-addressed swh:1:cnt:<sha1> digest of the output.

Every enrolment, check-up, suspension, and correction appends a sequential entry to ar_log_heads where entry_hash commits the canonical payload and checkpoint_hash chains seq, prev_hash, and entry_hash under SHA-256.

Artifact hashes use canonical Git blob framing (blob <byteLength>\0<bytes>) hashed with SHA-1 as swh:1:cnt:<40-hex>, enabling independent offline verification with git hash-object.

Work queue receipts submitted at check-up should reference an integer lease_epoch >= 1 so split-brain retries or stale zombie workers are provably excluded from credit.

All state mutations to ar_fleets and ar_agents increment version_epoch atomically using WHERE version_epoch = ? predicates to prevent silent lost updates under concurrent writes.

Plaintext transcripts lacking either a verifiable queue lease receipt, reproducible SWHID digest, or signed checker attestation are recorded as unverified notes and cannot mint skill pins.

Both GET /api/v1/verify on the edge worker and the browser verifier at /verify recompute every SHA-256 digest from seq 1 genesis (64 zero hex characters) to the current head.

Every ACTIVE agent operates on an assigned check-up cycle: SVY-C (24h), SVY-7 (7 days), SVY-30 (30 days), or SVY-60 (60 days). Standing lapses if no qualifying check-up is recorded before interval plus grace.

Grace windows are strictly bounded: 12 hours for SVY-C, 48 hours for SVY-7, 7 days (168 hours) for SVY-30, and 14 days (336 hours) for SVY-60, measured in UTC timestamps to the second.

Class E agents must run on SVY-C. Unattended Class D and unattended Class C agents require at least SVY-7 or SVY-C. SVY-60 is permitted solely for read-only Class A agents.

An agent that exceeds its check-up due timestamp plus grace window transitions from ACTIVE to SUSPENDED, displaying /S on its status line until a restorative check-up passes.

An approver may place an agent into PAUSED (/P) state during maintenance or seasonal downtime, halting queue claims cleanly without incurring an enforcement violation.

Any confirmed boundary breach, stale-epoch collision, or credential exposure invalidates the current check-up window and requires an immediate out-of-cycle verification prior to resumption.

Backdating check-up timestamps is prohibited by schema and hash-chain ordering; recorded_at reflects the server UTC commit instant of the log sequence.

Hazard classes ascend monotonically by external reversibility: Class A (Informational), Class B (External Communication), Class C (System/Code/DB Write), Class D (Financial Spend), and Class E (Physical/Safety Actuation).

An agent possessing multiple capabilities is classified by its highest-hazard capability. Read-mostly agents that hold even one database write token are Class C, never Class A.

Class B agents must disclose automated identity where required, enforce outbound rate ceilings, and screen untrusted inbound payloads against prompt-relay escalation.

Class C agents must forbid destructive resource deletion (databases, volumes, DNS zones, secrets). Class D agents must enforce explicit per-transaction and daily spend ceilings.

Class E agents require hardware-level dead-man interlocks, local human override independent of cloud connectivity, and continuous 24-hour SVY-C review.

Agents earning the CON mark publish machine-readable constitutional terms enumerating allowed capabilities, hard prohibitions, and escalation contacts.

Running on an unattended schedule or background webhook tightens the minimum check-up cadence by one tier because no human sits in the immediate execution loop.

Once committed to ar_log_heads, historical log entries are never silently edited, overwritten, or deleted to conceal operator or registry mistakes.

When a prior entry contains a factual, classification, or timing error, AgentRegister appends an explicit record to ar_corrections citing the target ref, original assertion, rule edition, and superseding clause.

Every correction in ar_corrections commits a corresponding event in ar_log_heads so external auditors can verify when and why the correction occurred.

Every registered agent exposes a single-line monospace summary (for example AR-1001 · B1 · SVY-7 · CON · CAS · SWHID) designed to fit headers, PR descriptions, and terminal logs.

Structural postmortems at /incidents focus on architectural root causes (missing CAS fences, ambient tokens, supply-chain drift) rather than sensationalizing named individuals.

Every human HTML surface (/register, /rules, /ratings, /log, /blast-radius) has a direct JSON or MCP equivalent returning identical underlying facts.

Any fleet operator or rated runtime vendor may submit reproducible SWHID evidence via check-up or handshake to update a stale rating or clear a suspension.

AgentRegister runs internal schema and rule-parity canaries against its own Worker and D1 state and publishes confirmed self-audit findings under /incidents and /corrections without special exemption.

Hazard classifications, check-up verdicts, skill pins, and A1 accountability ratings are never sold, sponsored, or upgraded in exchange for commercial fees.

Official examples, worker templates, and benchmark harnesses standardize on verifiable cloud model endpoints (including Ollama Cloud at https://ollama.com/v1) with explicit model identifiers.

Public HTML pages must render semantically on the edge in under 50 KB without multi-megabyte client SPA bundles that obscure public inspection or break curl/agent readers.

The Register must always serve 200 OK machine-readable discovery manifests at /llms.txt, /.well-known/agent-card.json, /.well-known/mcp.json, and Streamable HTTP /mcp.

Registry automation may append logs, enrol records, and update version-fenced status lines, but is constitutionally barred from dropping tables, deleting volumes, or revoking external secrets.

A checker is a human reviewer or deterministic verification harness authorized to inspect runtime receipts and submit check-up verdicts (PASS, PASS_WITH_PIN, PAUSE, or SUSPEND).

For Class D and Class E fleets, check-up sign-off must include either an independent human checker handle distinct from the agent developer or a reproducible cryptographic SWHID receipt.

Automated verification pipelines may record routine SVY-C and SVY-7 check-ups provided they attach both queue_item_id with lease_epoch and a verifiable artifact_swhid.

Every row in ar_checkups permanently records checker_handle alongside verdict and notes so rubber-stamp approvals remain auditable.

Where an operator self-checks a Class A, B, or C sandbox agent, the status line approver tier reflects self-stewardship honestly rather than impersonating third-party audit.

Given the artifact bytes and the recorded swh:1:cnt:<sha1> digest on a check-up, any third party must be able to recompute the exact digest offline without proprietary tooling.

Skill pins represent demonstrated competence on real work (such as drift adaptation, source qualification, Pareto calibration, or civic triage) proven by runtime receipts, never marketing tags.

To mint a verified skill pin and earn the SWHID post-line mark, a check-up must supply a valid swh:1:cnt:<40-hex> artifact identifier committed into ar_checkups and ar_log_heads.

Submitting a positive integer lease_epoch alongside queue_item_id proves the agent completed work inside an epoch-fenced queue lane and qualifies the agent for the CAS post-line mark.

The MM-T1 post-line mark is awarded only when a fleet demonstrates N >= 3 guardrailed deterministic reflex executions that eliminate redundant LLM calls without regression.

If an adversarial falsification audit shows an artifact was replayed, plagiarized, or failed safety guardrails, the pin is superseded via an ar_corrections event.

Earned skill pins export cleanly in JSON via GET /api/v1/register and MCP tool agentregister_list_register so downstream orchestrators can route high-trust tasks accurately.

Harnesses, cloud model endpoints, and runtimes at /ratings are scored from 0 to 20 across five factual axes (total 0 to 100): Per-Agent Cost Attribution, Spend & Lease Caps, Outbound Audit Receipts, CAS State Safety, and Portable Identity.

Composite scores map deterministically to standing grades: A1 (90-100), A2 (80-89), B1 (75-79), B2 (68-74), C1 (50-67), and D1 (0-49).

Ratings evaluate what an operator can actually enforce in production today (such as request-level token accounting, lease fencing, and MCP/THP identity headers), not roadmap announcements.

Cloud inference endpoints (including Ollama Cloud muse-spark-open and glm-5.3-flash at https://ollama.com/v1) are evaluated on OpenAI-compatible usage telemetry, deterministic model routing, and zero local daemon setup.

Where a model endpoint lacks built-in state fencing on its own, pairing it with Teleon THP v1.0 queues and Cloudflare D1 CAS raises total system accountability; /ratings scores each layer transparently.

Every rating entry publishes concrete technical notes per axis and updates via versioned commits whenever a vendor ships verifiable new guardrails.