Reference
Implementation™

Official Definition

Reference Implementation™ is the canonical example architecture through which the functional requirements of the 360WiSE Official Canon are demonstrated in a working, testable, and deployable system.

Purpose

Engineering Principles

1. Canonical identity is immutable.
2. Records are versioned, not silently overwritten.
3. Claims remain distinguishable from evidence and verification outcomes.
4. Public and restricted data are separated by design.
5. Services are independently testable.
6. Resolution is optimized for reliable read access.
7. Every material state change creates an auditable event.

System Architecture

Reference Components

Registry Service

The Registry Service creates, versions, publishes, suspends, deprecates, and retires canonical records.

POST   /v1/registry/records
GET    /v1/registry/records/{id}
PATCH  /v1/registry/records/{id}
POST   /v1/registry/records/{id}/publish
POST   /v1/registry/records/{id}/deprecate
GET    /v1/registry/records/{id}/history

Identity Service

The Identity Service assigns and resolves persistent identifiers for individuals, organizations, authorities, channels, programs, applications, and other Canon entities.

{
  "id": "360WiSE-000283",
  "type": "Organization",
  "canonicalName": "Example Organization",
  "status": "active",
  "aliases": ["Example Org"],
  "canonicalUri": "https://360wise.com/resolve/360WiSE-000283"
}

Resolution Service

The Resolution Service provides a stable, cacheable public response containing the current canonical state and links to related public records.

GET /v1/resolve/360WiSE-000283

{
  "id": "360WiSE-000283",
  "status": "active",
  "recordVersion": "1.4.0",
  "updatedAt": "2026-07-18T00:00:00Z",
  "links": {
    "json": "/v1/records/360WiSE-000283",
    "history": "/v1/records/360WiSE-000283/history",
    "verification": "/v1/records/360WiSE-000283/verification"
  }
}

Verification Service

The Verification Service evaluates evidence within a defined scope. It MUST record what was checked, what evidence was used, the outcome, the verifier, and the effective time.

{
  "scope": ["identity", "domain-control"],
  "status": "verified",
  "verifiedAt": "2026-07-18T14:10:00Z",
  "evidenceIds": ["360WiSE-EV-009114"],
  "limitations": ["Ownership of all published media assets not evaluated"]
}

Provenance Service

The Provenance Service maintains claim-to-evidence lineage and prevents source assertions from being presented as independent verification.

Continuity Service

The Continuity Service records renames, ownership changes, platform migrations, corrected claims, superseded evidence, status transitions, and other material changes.

{
  "eventType": "canonical-name-changed",
  "recordId": "360WiSE-000283",
  "from": "Former Name",
  "to": "Current Name",
  "effectiveAt": "2026-07-18T00:00:00Z"
}

Recognition Service

The Recognition Service stores dated observations showing how AI systems, search systems, or other public systems resolved an entity at a specific time.

Broadcast Infrastructure Service

The Broadcast Infrastructure Service manages broadcast services, channels, programs, episodes, events, schedules, streams, playback objects, and distribution records.

API Gateway

• Routes versioned requests.
• Applies authentication and rate limits.
• Enforces request-size and content-type constraints.
• Generates correlation identifiers.
• Separates public, partner, and administrative endpoints.

Database Architecture

Object Storage

Object storage MAY contain evidence files, archived JSON, signed canonical payloads, schema releases, media metadata, and public verification receipts.

Canonical Serialization

Canonical records SHOULD be serialized using RFC 8785 JSON Canonicalization Scheme before hashing or signature generation.

canonical_bytes = JCS(record)
digest = SHA-256(canonical_bytes)

JSON Schemas

All externally published record types SHOULD have versioned JSON Schema definitions. Schema IDs MUST remain stable for a published version.

https://360wise.com/schemas/entity-1.0.json
https://360wise.com/schemas/verification-1.0.json
https://360wise.com/schemas/continuity-event-1.0.json
https://360wise.com/schemas/broadcast-channel-1.0.json

REST API

GET  /v1/registry
GET  /v1/identity/{id}
GET  /v1/resolve/{id}
GET  /v1/verification/{id}
GET  /v1/provenance/{id}
GET  /v1/continuity/{id}
GET  /v1/recognition/{id}
GET  /v1/broadcasts
POST /v1/claims
POST /v1/evidence
POST /v1/verification-requests
POST /v1/validation

Event Pipeline

Claim Created
    ↓
Schema Validation
    ↓
Evidence Linked
    ↓
Verification Review
    ↓
Registry Version Created
    ↓
Continuity Event Written
    ↓
Resolver Cache Refreshed
    ↓
Recognition Monitoring Updated

Queue Architecture

Asynchronous tasks SHOULD be used for evidence processing, hash generation, notifications, cache invalidation, recognition checks, media inspection, and report generation.

Authentication

The reference implementation supports authenticated administrative access using short-lived tokens, API keys for controlled integrations, and optional multi-factor authentication for privileged operators.

Authorization

Logging

Logs SHOULD include timestamp, actor, request ID, record ID, action, result, latency, and service name. Sensitive values MUST be redacted.

Monitoring

High Availability

Production deployments SHOULD use redundant application instances, managed database failover, replicated object storage, health checks, and automated recovery.

Horizontal Scaling

Public read services SHOULD remain stateless where practical. Shared state SHOULD reside in managed databases, caches, queues, or object storage.

Security

• Encrypt data in transit and at rest.
• Use least-privilege roles.
• Rotate secrets and API keys.
• Separate public and restricted evidence.
• Log privileged actions.
• Validate all inbound payloads.
• Protect against replay, injection, and enumeration attacks.

Performance

Deployment Architecture

DNS / Edge Security
        ↓
CDN / Web Application Firewall
        ↓
Load Balancer
        ↓
API Gateway
        ↓
Stateless Application Services
        ↓
PostgreSQL · Cache · Queue · Object Storage
        ↓
Monitoring · Logging · Backup · Recovery

Testing

• Positive schema validation tests.
• Negative malformed-record rejection tests.
• Identifier uniqueness tests.
• Canonical serialization tests.
• Hash reproducibility tests.
• Resolver status behavior tests.
• Continuity-chain tests.
• Authorization boundary tests.
• API compatibility tests.

Compliance

Reference Implementation™ conformance indicates architectural alignment with the Canon. It does not constitute government certification, legal compliance certification, security accreditation, copyright clearance, or a warranty of platform approval.

Implementation Notes

Implementers MAY begin as a modular monolith and separate services as scale and operational complexity increase. Canonical data boundaries are more important than premature service fragmentation.

Future Extensions

• Federated registries.
• Selective disclosure proofs.
• Third-party verifier interoperability.
• Automated recognition observation pipelines.
• Additional broadcast and device profiles.
• Signed correction receipts.

Related Canon

Revision History