Architecture

The Agents of the System

The protocol coordinates multiple agents and entities, both human and automated, to produce HVOs and HVD datasets.

Requester

A third party (corporation, individual, or AI agent acting for a principal) that funds and specifies work. It creates task or dataset campaigns and receives outputs via the Distribution Layer. It defines schema, acceptance criteria, cohort requirements, privacy mode, quality tier, budget, target accepted outputs, and delivery mode.

Contributor

Humans that resolve tasks, prompts, and questions to generate requested work or datasets. Contributors provide the underlying human judgment, knowledge, preference, or analysis that the protocol is designed to verify.

Validator

Validators review contributor outputs under the declared rubric. They produce the approve/reject decisions that feed PHK finality, and may participate in audits, escalations, or arbitration where enabled. Validators can surface suspicious patterns or integrity concerns, but they do not become truth authorities outside PHK.

Curators

Curators gather knowledge, detect reusable patterns, and generate dataset formats, task specs, or rubrics. They can create reusable templates, task/dataset designs, and recurring structures for protocol demand.

Arbitrator

A specialized validator quorum for disputes and high-risk cases. They handle escalations, disagreement, and dispute resolution where the campaign enables arbitration, and they produce the final arbitration decision state that PHK references.

The Protocol Foundation

The Lioth Protocol Foundation is focused on infrastructure, open-source coordination, and public participation. Its core responsibilities are:

• Maintaining core infrastructure (web app, APIs, SDKs, tooling).
• Coordinating open-source development and security review.
• Managing documentation, research, and public communications.
• Supporting ecosystem growth, partnerships, and integrations.
• Operating reference endpoints and services during bootstrap/testnet, when needed to accelerate growth and keep the network usable.

Bootstrap Authority (Time-Bound)

During bootstrap and testnet, the Foundation may publish initial defaults, operate reference infrastructure, and use audited operational controls required to keep the network usable while participation is still bootstrapping.

Implementation note: Current live bootstrap controls are documented in App Status.

Post-Bootstrap/Testnet

After the protocol transitions to governance, parameter authority moves to the Lioth DAO. The Foundation remains an implementer and coordinator, maintaining reference clients, documentation, research, and ecosystem support.

Non-Interference Guarantee

The Foundation does not participate in data generation and does not control individual task outcomes. It may operate reference infrastructure and publish defaults, but canonical accepted/rejected truth is still produced only by PHK. Bootstrap/testnet operational controls, when present, remain separate from PHK finality and do not rewrite canonical outcomes.

Transition to governance occurs when DAO activation criteria are met after testnet and minimum readiness thresholds are satisfied.

Automated Agents and Protocol Services

The protocol uses off-chain automated software agents to run high-frequency workflows such as routing, integrity scoring, packaging, and delivery while keeping sensitive content and heavy computation off-chain. These agents do not make discretionary human decisions about task truth. Final outcomes are determined by validator review, audits, dispute/arbitration rules, and PHK finality. Protocol services are mandatory workflow functions but are not intended to be a single hosted backend. They can be operated as:

• reference services maintained by the Foundation during bootstrap/testnet; or
• independent Protocol Service Operators (PSOs) running spec-compliant implementations.

PSO Selection, Redundancy and Failover (Normative)

Protocol Service Operators (PSOs) provide spec-compliant implementations of mandatory off-chain services such as orchestration, integrity checks, packaging, and delivery. PSOs do not decide truth outcomes. They provide availability, performance, and interoperability under published rules.

PSO Registry and Discovery

The protocol maintains, on-chain or via verifiable registry commitment, a registry of PSOs including:

• PSO identity (public key) and service types offered;
• supported service specification hashes;
• supported Parameter Registry versions and optional stake/bond if enabled; and
• off-chain endpoint descriptors.

A PSO must emit signed service events that reference the campaign configuration hash and relevant service spec hashes so outputs remain auditable across operators.

Selection Modes

Each campaign declares a Service Policy defining how PSOs are selected for each service type:

• Requester-selected PSOs (default): the requester chooses a primary PSO and one or more backups per service type.
• Protocol-selected PSOs (optional): PSOs are selected deterministically from the eligible PSO set based on published policy, operator eligibility, and verifiable randomness where required.
• Enterprise-hosted mode (confidential/enterprise): the requester or enterprise provides controlled execution environments. The protocol still produces receipts and settlement while service execution occurs inside enterprise infrastructure.

Failover and Reassignment

If a PSO fails to respond within a tier-defined timeout, the client or protocol switches to the next eligible backup PSO, or deterministically reselects from the eligible PSO set under campaign Service Policy. Failover must be recorded as a signed service event referencing the old PSO, new PSO, and workflow identifiers.

Redundancy Requirements

For delivery/storage-sensitive workflows, campaigns may require redundancy:

• encrypted objects (payloads, bundles, manifests) are replicated across multiple PSOs;
• replication factor is tier-defined; and
• delivery receipts reference the artifact/manifest hash so integrity can be checked independently of which PSO served delivery.

This does not claim perfect censorship resistance of off-chain services. It provides auditability, deterministic switching rules, and redundancy under committed parameters.

Task Orchestrator

An automated routing agent with the following tasks:

• validates campaign configuration (eligibility rules, cohort proofs, rate limits, tier configuration);
• assigns tasks to eligible contributors;
• assigns submissions to validators under the current routing policy; and
• emits signed routing events and, where used, references to randomness proofs.

The task orchestrator cannot accept or reject outputs. It only routes work under published rules.

Validation Guard

An automated integrity service that computes fraud and integrity signals (e.g. similarity/duplication indicators, anomaly patterns, timing outliers, or rubric-compliance checks where deterministic). It produces flags, confidence scores, and operational posture for validators and operators. The Validation Guard does not finalize outcomes and is not a source of truth by itself.

Its integrity posture can contribute to routing restrictions, readiness limits, or increased audit pressure, but these remain operational restrictions rather than confirmed fraud findings.

Dataset Assembler

An automated packaging agent that transforms validated outputs into dataset artifacts when a campaign is in dataset mode. It normalizes and formats outputs, enforces schema and versioning, computes dataset-level QA summaries defined by the campaign, and produces:

• a dataset artifact;
• a manifest with counts, provenance references, and hashes; and
• delivery/receipt metadata for requester-facing completion.

Distribution Gateway

An automated delivery agent that manages encryption, access control, entitlement checks for private delivery, subscriptions, delivery logging and receipts, and integration delivery (APIs, feeds) when enabled. The Distribution Gateway delivers outputs but does not change PHK verification outcomes or override validator finality.

Distribution Gateway behavior is constrained by a service specification referenced by hash. Protocol Service Operators emit signed service events, such as delivery receipts, that reference the campaign configuration hash, relevant service spec hashes, and associated workflow identifiers. This allows multiple PSOs to provide delivery services while remaining verifiable and interoperable under the same protocol rules.

Protocol Service Operators and Spec Compliance

Protocol services are constrained by service specifications referenced by hash. PSOs emit signed service events that reference:

• the campaign configuration hash;
• relevant service spec hashes; and
• associated workflow identifiers (tasks, outputs, bundles).