Hub

Every Weblisk deployment is a hub — a self-sovereign node that owns its orchestrators, domains, agents, logic, and data. Hubs connect to form a global network where businesses collaborate through cryptographically enforced data contracts.

What Is a Hub?

A hub is a complete Weblisk deployment. It includes an orchestrator, domain controllers, work agents, infrastructure agents, and all associated data. The owner of a hub has full sovereignty — no external authority can access data, modify behavior, or override policies.

Hub Architecture

Hub (self-sovereign deployment)
├── Orchestrator (coordinator)
│   ├── Domain: SEO
│   │   ├── seo-analyzer (work agent)
│   │   └── a11y-checker (work agent)
│   ├── Domain: Content
│   │   ├── content-analyzer (work agent)
│   │   └── meta-checker (work agent)
│   ├── Domain: Health
│   │   ├── uptime-checker (work agent)
│   │   └── perf-auditor (work agent)
│   └── Infrastructure Agents
│       ├── sync
│       ├── cron
│       ├── webhook
│       └── email-send
└── Federation (hub-to-hub)
    ├── Discovery & trust establishment
    ├── Data boundary contracts
    └── Cross-org task execution

Hub Roles

Every hub can serve one or more roles simultaneously:

A manufacturing hub might provide inventory intelligence to retail hubs, consume compliance checking from an audit hub, and operate a private registry for its supplier network — all simultaneously.

Federation

Federation is the protocol that lets hubs collaborate. When two organizations want to work together, their hubs establish trust through Ed25519 identity signing, negotiate data boundary contracts, and then coordinate agent work across organizational boundaries. See Protocols for the full federation wire protocol, data contracts, and behavioural integrity specification.

Collaboration Flow

1. Discover — Consumer hub searches the registry or queries a provider directly. Reviews listing: capability, data contract, SLA, pricing, behavioural metrics, jurisdiction.
2. Review Data Contract — Consumer downloads the data contract. Reviews what inbound data is required/permitted, what outbound data will be returned, what fields are forbidden, jurisdiction requirements, and retention policy. Legal/compliance team approves.
3. Initiate Peering — Consumer hub sends a peering request (POST /v1/federation/peer) with its orchestrator manifest, requested capabilities, and accepted data contracts.
4. Provider Review — Provider hub reviews the consumer's identity, jurisdiction, and requested capabilities. Provider approves or rejects.
5. Trust Established — Provider sends peer-accept. Both hubs exchange manifests and public keys. Federation link is live.
6. First Collaboration — Consumer's domain controller includes the federated capability in its workflow. First federated task executes with full data contract enforcement, behavioural verification, and audit logging.
7. Ongoing Monitoring — Both hubs monitor usage against quotas and SLAs, behavioural fingerprint stability, data contract compliance, error rates, and latency.

Capability Listings

When a hub publishes a capability to the network, the listing includes verifiable metadata — not marketing text, but cryptographically signed facts:

{
  "listing_id": "avaropoint:seo-audit",
  "provider": {
    "hub_name": "avaropoint-prod",
    "public_key": "<hex Ed25519 public key>",
    "federation_url": "https://agents.avaropoint.com/v1/federation",
    "jurisdiction": "US"
  },
  "capability": {
    "domain": "seo", "action": "audit", "version": "1.2.0",
    "data_contract": "seo-audit-v1"
  },
  "tier": "pro",
  "pricing": {"model": "per_invocation", "unit_price": 0.05, "free_quota": 100},
  "sla": {"availability_target": 99.9, "p95_latency_ms": 5000},
  "metrics": {
    "uptime_30d": 99.95, "p95_latency_30d_ms": 3200,
    "total_invocations_30d": 142000, "error_rate_30d": 0.002,
    "behavioral_changes_90d": 1
  },
  "compliance": {"jurisdiction": "US", "retention_hours": 24},
  "signature": "<provider's Ed25519 signature over listing>"
}

Free vs Pro Tiers

Tier separation is about capability scope and service levels, not security or quality. Both tiers use the same federation protocol, data contracts, and trust enforcement.

Pricing Models

Usage Metering

Both hubs independently track usage for reconciliation. Metering records are dual-signed by both consumer and provider, ensuring neither party can dispute usage unilaterally. Discrepancies are flagged for manual resolution.

Discovery

Registry Search

Hubs search the registry by capability, domain, jurisdiction, and tier via GET /v1/hub/search:

Direct Discovery

Without a registry, one hub can query another hub's published capabilities directly via GET /v1/federation/contracts, which returns the data contracts and capabilities the target hub offers to peers at the requester's trust tier.

Data Sovereignty

Data sovereignty isn't a feature — it's the foundation. Every piece of data in a Weblisk hub has an owner, a purpose, and a boundary.

Behavioural Change Management

Behavioural integrity is especially critical across hubs because each hub relies on capabilities it does not own or control.

Provider Obligations

When a provider updates an agent that backs a published capability:

• BENIGN changes: Publish updated metrics. No disruption.
• NOTABLE changes: Update hub listing, notify collaborating hubs via POST /v1/hub/notify, allow 7-day parallel running of old + new version.
• BREAKING changes: Publish new listing version alongside old, notify all collaborators with detailed changelog, provide 30-day deprecation window. Collaborators must explicitly opt-in.
• CRITICAL changes: Immediately suspend the listing, notify all collaborators with BEHAVIORAL_CHANGE_CRITICAL, require re-approval from all active collaborators.

Collaborator Protections

• Version pinning — collaborators can pin to a specific version; providers MUST continue serving it during deprecation
• Change notifications — all changes above BENIGN trigger a notification to the collaborating hub
• Automatic suspension — CRITICAL behavioural changes automatically suspend federated tasks until admin review
• Audit trail — full history of behavioural changes visible in the listing's metrics

Revocation & Removal

Collaborator Disconnects

A collaborator can revoke trust at any time via POST /v1/federation/peer-revoke. In-flight tasks complete with timeout, no new tasks are dispatched, metering finalises at revocation, and the data retention clock starts on both sides.

Provider Delists

A provider can remove a capability via POST /v1/hub/delist. Active collaborators receive a 30-day warning. Existing collaborators continue for the deprecation window. After deprecation, trust relationships expire and the listing is removed from registry search results.

Emergency Revocation

In case of a security incident (compromised key, data breach, malicious behaviour), immediate revocation terminates the trust relationship with no grace period, cancels all in-flight tasks, purges all cross-boundary data per retention policy, logs the incident in both audit trails, and notifies the registry.

Registry Architecture

A registry is itself a Weblisk hub — an orchestrator with specialised agents for indexing and discovery:

The registry NEVER handles actual federated task data. It only indexes metadata (listings, metrics, contracts). All data exchange happens directly between hubs through the federation protocol.

Registry Federation

Multiple registries can federate with each other, sharing listing indexes. This prevents a single point of failure and supports regional or vertical-specific registries:

Global Registry (Avaropoint)
  ├── EU Registry (regional)
  ├── APAC Registry (regional)
  └── Healthcare Registry (vertical)

Each registry independently verifies hub signatures. A listing appearing in multiple registries carries the same cryptographic proof regardless of which registry serves it.

Hub Network

At scale, the hub network forms a topology analogous to the internet — decentralised, resilient, and self-organising. Key properties:

• No single point of failure — if any hub or registry goes offline, the remaining network continues. Existing trust relationships are peer-to-peer and do not depend on the registry.
• Organic growth — new hubs join by peering with existing hubs. No central authority approves membership.
• Domain specialisation — each hub excels at its own domains. Collaboration lets every hub access capabilities beyond its own specialisation.
• Data stays home — each hub processes data within its own jurisdiction. Only the minimum required data (per data contracts) crosses boundaries, cryptographically controlled at every step.

Replacing EDI & Traditional B2B

Use Cases

Hub API Endpoints

Hub-specific endpoints (in addition to federation endpoints):

Security Considerations