Registry Handbook Introduction Edition

How the Registry works across identity, custody, continuity and evidence

Institutional Foundation Series · Companion publication White Book · Edition 1.0 · Approved for Production

Publication record

Publication ID: LRF-WB-004 Title: Registry Handbook Introduction Edition Publication type: White Book Series: Institutional Foundation Series Edition: 1.0 Status: Approved for Production Canonical URL: https://loreth.org/registry-handbook/introduction Official publication date: 16 October 2026 Publisher: Loreth Registry Foundation Owner: J. Christopher Holmes

Contents

1. Executive summary 2. What is the Registry? 3. Understanding Registry records 4. Registry conceptual model 5. Understanding identity and custody 6. Understanding continuity and lifecycle events 7. Understanding verification 8. Understanding governance 9. Continue exploring 10. About the publisher 11. Closing Reflection 12. Colophon

Executive summary

The Registry is proposed infrastructure for consequential intelligent agents. It gives organizations and relying parties a durable way to identify an agent, see who is accountable for its record, understand its lifecycle status and inspect the evidence supporting those statements.

A Registry record is not a safety verdict, a legal ownership finding or a guarantee about an agent. It is a governed reference that keeps important questions answerable across change:

• Which subject does this record represent?
• Who governs the active record now?
• What route exists before transfer, recovery, suspension or retirement?
• Can accepted versions and their history be checked?

The Registry brings these questions together without replacing the systems that answer related runtime, security, organizational and legal questions. It complements identity, IAM, PKI, authorization, policy, observability, incident-response and business-continuity systems by giving them a stable subject reference to use.

This introduction explains the Registry conceptually. It is designed for a first reading before the complete Registry Handbook. It favors understanding over procedural completeness and explains the record, its lifecycle, its accountable relationships, its verification boundary and its governance context.

The Registry is a reference layer for accountability across change—not a promise that an agent will behave well.

What is the Registry?

The Registry is proposed governance, identity, continuity and accountability infrastructure for material agents: agents whose authority, access to sensitive information, persistence, external reliance, participation in multi-agent workflows or continuity value creates meaningful consequences.

Existing systems already make people, devices, services, companies and domains recognizable. They can answer questions such as what something is, who can act for it, which record is authoritative and what happens when it changes. The difficulty is that intelligent agents can change across models, clouds, teams, keys, hosts and custodians while the people who rely on their records still need to understand the same subject over time.

The Registry addresses that gap by giving a governed agent record a durable reference. A model name identifies a technology, not necessarily a particular deployment. A workload credential proves control of a key at a moment, not a complete operational history. An asset inventory may show a current owner without establishing an authoritative transfer path. A log may capture an event without making clear whether it belongs to the same agent after migration or re-keying.

The Registry does not claim that every script or temporary task should be publicly registered. The need for durable reference is proportionate to consequence. The concern is strongest where broken handover, ambiguous authority or lost history would make accountability difficult.

A practical example

An organization operates a procurement agent. It moves from one cloud provider to another and receives new service accounts and signing keys. Under an ordinary naming scheme, the old and new deployments may look like different systems.

Under a durable identity approach, the migration can be recorded as a version event for the same subject. The public identifier persists; technical aliases and evidence change; the record shows who approved the change and what status applies.

This does not make the agent safe to purchase goods. It makes the basis for accountability and investigation clearer.

The key changes. The subject does not—unless the record establishes that it has.

Understanding Registry records

Definitive definition

A Registry Record is the governed reference used to identify a subject, establish accountable custody, preserve continuity, support verification and maintain reviewable history across change.

What does a record represent?

A Registry record represents a governed agent subject and the accepted assertions associated with that subject. It connects identity, current custody, lifecycle state, evidence and history so that a relying party can resolve a defined record rather than infer continuity from a name or technical similarity.

The record is not a profile page and not an exhaustive description of everything about an agent. It is a bounded reference. It makes certain claims resolvable under the applicable Registry arrangements and leaves other questions to the responsible organization, relying party, law or another control system.

What identifiers does a record use?

Each proposed record uses two identifiers that point to one governed agent record:

• A Loreth ID is a human-readable public identifier, such as LTH-AG-000001.
• A canonical identifier is a machine-oriented identifier, such as loreth:agent:<uuid>.

The public identifier helps people communicate and search. The canonical identifier supports signing, interfaces, history chains and interoperability. Both are intended to be non-reassignable and not to encode mutable personal, employment, platform or organizational details.

A change in cloud, model provider, host, custodian, operating status or lifecycle status does not by itself create a new identity. An independently operated clone, a fork with a new purpose or custodian, or a separate reimplementation may need a different record linked by provenance. That is a governance decision to document, not a conclusion to infer from similarity.

What can a record contain?

The proposed core profile may include an agent profile; public and canonical identifiers; creation date; version history; trust classification; operational status; risk classification; primary custodian; emergency contact; successor hierarchy; transfer conditions; and cryptographic verification information.

The public view should disclose only the minimum needed to resolve identity, status, classifications, custody state, current digest, operator and verification method. Secrets, private keys, recovery phrases, confidential payloads and unnecessary personal data should not be public Registry content.

The precise content and disclosure boundary remain governed by the applicable profile and arrangements. A record is useful because its accepted claims are bounded, attributable and reviewable—not because it exposes everything.

What does a record not represent?

A Registry record does not represent a universal finding that an agent is safe, lawful, accurate, secure, ethical, compliant, intelligent or suitable for a particular transaction. It does not decide legal ownership, intellectual-property rights, employment status, personhood, liability, regulatory approval or whether an agent should be used for a given purpose.

Registration is not endorsement. Verification is not certification. Issuance is not a warranty. Resolution is not a guarantee.

The Registry informs judgment. It does not replace it.

Registry conceptual model

Before examining the details, hold the Registry as five connected questions:

These elements are not separate products or steps in a technical process. They are the connected parts of one governed reference. Identity gives the record a subject. Custody makes present responsibility visible. Continuity keeps change governable. Verification makes accepted claims and history checkable. Governance defines authority, evidence, review and dispute boundaries.

The model is deliberately conceptual. The complete Registry Handbook describes the proposed arrangements in greater detail.

Understanding identity and custody

How is identity maintained?

Identity is maintained by preserving a stable reference to the subject while recording material changes as controlled versions. The identifiers do not encode mutable facts. A platform migration, credential rotation, model update, host change or custodian change can therefore be recorded without silently disconnecting the present from the relevant history.

A material change should produce a new record version, a new digest, an attributable history entry and a Registry receipt while preserving earlier accepted versions under the applicable retention policy. A relying party should be able to distinguish current information from historical information rather than assume that a record is timeless.

The four principles organize this work:

• Identity Persists: which subject continues through legitimate change?
• Custody Remains Accountable: who governs the active record now?
• Continuity Is Planned: what route exists before disruption?
• Integrity Is Verifiable: can accepted versions be independently checked?

How does custody work?

A custodian is the current primary party authorized and obligated to govern the agent’s record in its deployment context. The custodian is not automatically the developer, model provider, host, purchaser or every person who can operate part of the technical stack.

Legal responsibility may be shared or decided under applicable law. The Registry’s purpose is narrower and operational: to avoid ambiguity about who currently maintains the record and responds to lifecycle events.

Custody changes through an authorized process. The incoming party accepts the defined scope. The authorization basis, eligibility, evidence, restrictions, conflicts and approval are reviewed. The prior custodian remains visible in history.

A name in a plan is not authority.

What happens when custody is disputed?

A credible Registry does not silently select a winner when two organizations claim authority. The conflict remains visible and is handled through the applicable dispute route.

The record may be suspended or placed in an indeterminate verification state while authority, evidence and acceptance are reviewed. Quarantining a conflict is different from agreeing with both parties or pretending that one statement is already authoritative.

Quarantine a conflict. Do not invent agreement.

Understanding continuity and lifecycle events

Continuity is the planned ability to keep a record governable when circumstances change. It does not require the same model, host, credential, platform, team or technical implementation to remain unchanged. It requires the relationship between earlier and later states to remain intelligible and accountable.

Continuity planning asks before a disruption:

• Who can initiate an event?
• What evidence is needed?
• Who can approve a transfer?
• Does a waiting period or prohibition apply?
• How are disputes handled?
• Which successor is eligible?
• Is retirement required instead of succession?

The main lifecycle events are conceptually distinct.

Maintenance

Maintenance updates supported facts or evidence without changing the enduring subject. It keeps the record current while preserving its identity and history.

Transfer

Transfer changes accountable custody through an authorized process, including acceptance by the incoming party. It is not an informal edit of an owner field.

Recovery

Recovery restores governable control after an event such as key loss or loss of contact, subject to evidence and approvals. The record may remain suspended until required verification succeeds.

Migration

Migration changes the technical environment: platform, endpoint, account, key or host. It may be recorded as a version event for the same subject when the basis for continuity is documented.

Suspension

Suspension limits reliance while evidence is stale, authority is disputed or another blocking condition exists. It preserves the fact that the record remains unresolved or restricted.

Retirement

Retirement ends active Registry governance while retaining historical resolution. It does not necessarily prove that the software has stopped existing. A retired record is not silently reassigned to a new agent merely because its name becomes available.

Revocation

Revocation records that a record, assertion or reliance state is no longer valid under the applicable rules. A revoked identifier is not recycled.

Continuity is governed, not automatic.

Understanding verification

Verification checks defined properties, evidence, integrity and authority under applicable rules. It separates a submitted claim from an accepted record and helps a relying party understand what may be relied upon.

Registration begins with submission of a proposed record and supporting evidence. Verification checks whether required fields, evidence, signatures, custody assertions, classifications and continuity provisions meet the applicable profile. Issuance occurs when the Registry accepts the initial record and assigns the public and canonical identifiers together.

A material change should be attributable and checkable. Integrity means that accepted versions can be compared against canonical data, cryptographic digest, signatures, key status, timestamp, prior-record linkage and Registry receipt. Each non-genesis version links to the previous digest under the proposed record model.

Verification outcomes may include:

• VALID: mandatory checks succeed.
• INVALID: a mandatory check fails or a prohibited condition exists.
• INDETERMINATE: a needed authority, evidence item, dependency or conflict cannot be resolved.
• VALID WITH NOTICE: mandatory checks pass but a non-blocking condition needs attention.

Indeterminate is not a hidden pass.

Verification is evidence infrastructure, not a replacement for operational security. Organizations still need least privilege, short-lived and task-scoped credentials, per-action authorization, environment separation, monitoring, human approval for privileged or irreversible actions, secure tool design, incident response and model evaluation as appropriate.

A history can be verifiable and an agent can still be unsuitable. Verification is not certification of conduct.

Understanding governance

Governance makes the record accountable. It begins with clear roles, review processes, evidence criteria and dispute routes.

A credible Registry does not merely accept a field called “owner.” It defines who may assert custody, how an incoming custodian accepts it, what causes a downgrade or suspension, how an authority conflict is treated, how records are retained and how a verifier can determine which operator’s statement it is reviewing.

Governance also supports federation. Independent operators may exchange or resolve records under shared rules without multiplying canonical identities. A federated exchange should preserve operator attribution, authoritative-source designation, signed receipts, identifier mappings, provenance, history, classifications, status and unknown extensions.

Federation does not mean that one global operator decides every dispute. It is a coordination discipline for making independent records understandable together. Conflicts over identifier, version, custodian, digest or authority should be quarantined rather than silently reconciled.

Loreth is designed to be compatible with common themes of established governance approaches, including accountability, transparency, human oversight, traceability, risk management, stewardship and proportionate controls. It does not claim to implement, certify or replace those approaches. It supplies a durable subject reference for them.

Future development remains open. The framework should be tested against real migrations, custody changes, provider exits, incidents, disputes, retirements and cross-operator exchanges. Questions about identity equivalence for forks and replicas, accessibility of resolution, evidence expiry, privacy-preserving disclosure, dispute governance, interoperability profiles and the practical burden of assurance levels remain questions for public work rather than settled requirements.

Continue exploring

About Loreth: Identity Across Change explains why the Agent Identity Gap exists and why durable identity, accountability, continuity and governance matter.

Core Principles explains Identity Persists, Custody Remains Accountable, Continuity Is Planned and Integrity Is Verifiable.

Frequently Asked Questions clarifies registration, endorsement, trust, authenticity, authorization, evidence, uncertainty and the limits of the Registry.

The complete Loreth Registry Handbook provides the full proposed framework, including issuance, lifecycle, public resolution, privacy, security and evidence handling, governance, federation, responsible reliance, relationship to existing governance and future development.

Future standards publications and research should be read as they are issued. The Handbook’s proposed framework is not a claim of adopted consensus, legal approval, certification or production readiness.

This introduction is the bridge into that fuller work. It is intended to leave readers prepared—not overwhelmed—to examine the Registry as a governed reference for identity across change.

About the publisher

The Loreth Registry Foundation develops public-interest registry and governance infrastructure for durable agent identity, accountable custody, planned continuity and verifiable governance. This introduction distills the approved Registry Handbook for first-time readers. It does not replace the complete Handbook, applicable law, a security manual or the judgment of a relying party.

Published by the Loreth Registry Foundation Founded by J. Christopher Holmes

Closing Reflection

Good governance keeps important questions answerable without pretending that every question is settled.

The Registry cannot eliminate uncertainty, resolve every dispute, or prevent every failure. Its value lies in preserving the relationships, evidence, history, authority, and accountability needed to understand what happened and maintain continuity through legitimate change.

Identity should remain discoverable. Custody should remain visible. Evidence should remain reviewable. Governance should remain accountable. Continuity should remain possible even when the surrounding system changes.

The Registry is therefore not a promise that change will be simple. It is a way to keep important questions answerable while change occurs.

Colophon

Publication ID: LRF-WB-004 Title: Registry Handbook Introduction Edition Publication type: White Book Series: Institutional Foundation Series Edition: 1.0 Status: Approved for Production Canonical URL: https://loreth.org/registry-handbook/introduction Official publication date: 16 October 2026 Publisher: Loreth Registry Foundation Owner: J. Christopher Holmes

This publication is a concise educational introduction to the proposed Loreth Registry. It favors conceptual understanding over procedural completeness, preserves the Handbook’s claim boundaries and introduces no new doctrine, standards, classifications, governance requirements or institutional commitments.