Campaign Structure

The work in the platform is organized in campaigns. It is the operational unit that defines rules, budget, eligibility, and delivery requirements for a set of tasks. Campaigns support HVO campaigns (direct outputs) and HVD dataset campaigns (aggregated datasets). Both use the same routing and validation workflow.

The core campaign fields currently supported are:

Campaign ID

Unique campaign identifier.

Campaign Mode

HVO or HVD Dataset mode. This determines whether outputs are delivered as individual task results or assembled into a dataset artifact.

Requester ID

Identity of the requester funding and receiving outputs.

Title and Summary

A short human-readable description of the campaign’s goal.

Task Template Reference

Reference to the task template(s) used in the campaign. Campaigns may use one template or a small set of templates.

Cohort Requirements

Eligibility rules for contributors, currently based on reputation state, Account Trust/runtime policy, cohort requirements, and quality-tier constraints. Future versions may support additional eligibility mechanisms.

Quality Tier Configuration

Defines verification strength through validator quorum requirements (Q0-Q3 tiers). Additional verification features are planned for future development.

Acceptance Criteria

What constitutes an acceptable output, currently based on validator consensus. For dataset campaigns, this includes basic quality metrics.

Privacy Mode

Defines confidentiality rules. Currently supports standard, restricted, and confidential modes as configuration options. Full enforcement is planned for future development.

Budget and Economics

Total budget and payout rules. Currently supports basic budget allocation with planned economic features for future development.

Dispute and Arbitration Configuration

Defines whether disputes and arbitration are enabled. These features are configured but not yet implemented in the current platform.

Timeline and Termination Rules

Campaign completion conditions. Additional timeline controls are planned for future development.

Delivery Configuration

How outputs are delivered. Currently supports private delivery to requesters. Additional delivery modes are planned for future development.

Service Policy

Defines service operator selection and redundancy. This is a planned feature for future decentralized service infrastructure.

Assistance Policy

Policy governing AI/tool assistance. Currently configurable but enforcement is planned for future development.

Protocol Roadmap: The sections below describe planned dataset licensing and versioning features. On-chain licensing records, cryptographic hash commitments, royalty policies, and distribution-layer access control are not yet active in the current platform. They are documented here to define the target protocol architecture.

Dataset Campaign Extensions

Dataset campaigns support additional configuration for packaging and reuse. Current implementation provides basic dataset assembly.

Dataset Schema and Format

Target dataset format (for example JSON, Parquet) plus schema versioning.

Target Sample Size and Sampling Strategy

Required sample counts and any stratification requirements. Dataset QA Metrics Metrics to compute and report, such as agreement rate, audit rate, deduplication rate, timestamp distribution, and coverage measures.

Licensing Constraints (Dataset Mode)

For dataset campaigns, “licensing constraints” are not a vague label. They are a declared rights configuration that controls access via the Distribution Layer, and produces a Dataset Licensing Record that is referenced on-chain. The protocol does not attempt to replace legal enforceability; it creates cryptographically verifiable commitments to the license terms used for access control, auditability, and downstream traceability.

Dataset Licensing Record

A Dataset Licensing Record is an immutable record describing the usage rights attached to a dataset artifact produced by a campaign. The full license text/terms are stored off-chain (e.g., in the Distribution Layer storage), while the protocol commits a Dataset Licensing Record hash reference on-chain. Required fields:

• dlr_id : unique identifier for the licensing record campaign_id : campaign that produced the dataset dataset_artifact_hash : hash of the packaged dataset artifact license_template_id : identifier for a standard license template (optional but recommended) license_terms_hash : hash commitment to the full license terms document usage_rights (structured): allowed_uses (e.g., internal evaluation, research, commercial, ○ training, redistribution) prohibited_uses (e.g., resale, re-identification, model training, ○ derivative datasets) derivative_rights (allowed / restricted / forbidden) ○ redistribution_rights (none / permitted / permitted with ○ constraints) attribution_required (yes/no + attribution string if applicable) ○ exclusivity (non-exclusive / time-limited exclusive / exclusive) ○ territory (global or specific jurisdictions) ○ term (start date + expiry, or perpetual) ○ privacy_and_compliance_flags (structured): whether the dataset is subject to additional constraints (e.g., “no personal data”, “restricted cohort”, “confidential mode only”) issuer_signatures : requester signature (and optionally curator/DAO signature if governance requires)

Optional (but strongly recommended) fields:

• royalty_policy_id / royalty_policy_hash (if resale/subscription is enabled)

• revocation_policy (when allowed; otherwise explicitly state “irrevocable”)

• audit_rights (whether buyer access is logged; what can be audited)

Default rule: dataset campaigns must declare at least: allowed uses, prohibited uses, redistribution rights, attribution requirement, and term. Campaigns that omit these fields are invalid and can’t be published or distributed. On-chain, the protocol records (campaign_id, dataset_artifact_hash, license_terms_hash, dlr_id, issuer_signature) as the licensing reference.

Versioning and Update Policy

Rules for dataset revisions and subscription updates.