Developer Standards

Official Definition

These standards establish a common implementation layer without requiring every participating system to use the same internal database, software framework, hosting provider, or application architecture.

Conformance is determined by observable behavior, required record properties, canonical resolution, validation outcomes, and adherence to the public boundaries stated in this volume.

Purpose

This volume enables independent systems to produce and consume records that remain structurally consistent, machine-readable, traceable, and resolvable across time.

Technical Architecture

A conforming implementation is organized around distinct functional layers. A deployment MAY combine these layers operationally, but it MUST preserve their logical separation.

Implementation Principles

1. Canonicality: one authoritative URI MUST identify each canonical registry record.
2. Separation of concerns: entities, claims, evidence, verification, authority, and recognition MUST remain distinguishable.
3. Traceability: material assertions SHOULD link to supporting evidence or declared authority.
4. Continuity: material changes MUST be represented as lifecycle events rather than silent substitution.
5. Minimal disclosure: public records MUST exclude restricted data not required for resolution.
6. Transport independence: internal systems MAY vary while external representations remain conformant.
7. Failure transparency: resolution and validation failures MUST return explicit machine-readable errors.

Conformance Language

Identifier Requirements

Each registered entity MUST be assigned a globally unique, persistent Resolution Identifier.

Requirements

• The identifier prefix MUST be 360WSE.
• The prefix MUST be followed by one hyphen.
• The suffix MUST contain six decimal digits.
• Alphabetic characters MUST be uppercase.
• Identifiers MUST NOT be reassigned after issuance.
• Deprecated identifiers MUST continue to resolve to their lifecycle status.

^360WSE-[0-9]{6}$

360WSE-000283

360WiSE-000283

Canonical URI Requirements

Every Resolution Identifier MUST map to one HTTPS canonical URI. The URI MUST remain stable for the lifetime of the record.

https://360wise.com/resolve/360WSE-000283

• The URI MUST use HTTPS.
• The URI path MUST preserve the identifier exactly.
• The canonical URI MUST NOT depend on session state.
• The URI MUST return or negotiate a conforming representation.
• Alternate URLs SHOULD declare or redirect to the canonical URI.
• Redirects MUST preserve the meaning and identity of the record.

Entity Record Model

The Entity Record identifies the person, organization, institution, brand, project, public body, or other recognized subject represented by the Registry.

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

Claim Record Model

A Claim Record expresses a discrete assertion about an entity. Claims MUST remain distinguishable from the evidence, authority, and verification records that may support them.

{
  "claimId": "claim-0001",
  "subject": "360WSE-000283",
  "predicate": "foundingDate",
  "value": "2015-01-01",
  "status": "asserted",
  "evidence": [
    "evidence-0001"
  ],
  "createdAt": "2026-07-18T00:00:00Z"
}

• Each claim MUST have a unique claim identifier.
• The subject MUST resolve to a registered entity.
• The predicate MUST have a defined meaning.
• The value MUST use a documented datatype.
• A disputed or corrected claim MUST retain its prior state.

Relationship Record Model

A Relationship Record connects two resolvable subjects through a typed and time-bounded relationship.

{
  "relationshipId": "relationship-0001",
  "source": "360WSE-000283",
  "relationshipType": "parentOrganization",
  "target": "360WSE-000284",
  "validFrom": "2026-01-01",
  "validUntil": null,
  "status": "active"
}

Relationship records MUST NOT imply ownership, authorization, endorsement, or legal control unless the relationship type and supporting evidence expressly establish that meaning.

Authority Record Model

An Authority Record identifies the party, role, jurisdiction, or documented basis under which an assertion, verification, or correction was made.

{
  "authorityId": "authority-0001",
  "authorityType": "entityRepresentative",
  "holder": "360WSE-000283",
  "scope": [
    "identity",
    "officialDomains",
    "organizationalProfile"
  ],
  "validFrom": "2026-01-01",
  "status": "active"
}

Verification Record Model

A Verification Record documents a completed verification action, its scope, method, result, responsible authority, and completion time.

{
  "verificationId": "verification-0001",
  "subject": "360WSE-000283",
  "verificationType": "identity",
  "method": "document-and-domain-control",
  "result": "verified",
  "verifiedBy": "authority-0001",
  "verifiedAt": "2026-07-18T00:00:00Z",
  "expiresAt": null
}

Provenance Record Model

Provenance records describe where a record, claim, evidence object, or representation originated and how it entered the system.

{
  "provenanceId": "provenance-0001",
  "object": "claim-0001",
  "sourceType": "entitySubmission",
  "sourceUri": "https://example.org/official-record",
  "receivedAt": "2026-07-17T20:00:00Z",
  "ingestedAt": "2026-07-18T00:00:00Z",
  "processingActions": [
    "normalized",
    "validated",
    "registered"
  ]
}

Continuity Event Model

A Continuity Event records a material transition in the lifecycle of an entity or record.

Recognition Event Model

A Recognition Event records a dated, reproducible observation of how an external system represented, retrieved, attributed, or resolved an entity or claim.

{
  "recognitionEventId": "recognition-0001",
  "subject": "360WSE-000283",
  "system": "External AI System",
  "observationType": "entity-resolution",
  "query": "Example neutral query",
  "observedResult": "Entity correctly resolved",
  "observedAt": "2026-07-18T00:00:00Z",
  "reproducible": true,
  "evidence": [
    "evidence-0002"
  ]
}

Recognition records MUST describe observed behavior and MUST NOT imply control over, partnership with, certification by, or permanent treatment from an external system.

Recognition Level Model

Recognition Levels summarize documented external observations. A level MUST be calculated from recorded events and defined thresholds rather than assigned as an unsupported promotional label.

Evidence Record Model

An Evidence Record describes an artifact used to support, reproduce, contextualize, or challenge a claim, verification, authority record, recognition event, or correction.

{
  "evidenceId": "evidence-0001",
  "evidenceType": "official-document",
  "title": "Official Registration Record",
  "sourceUri": "https://example.org/document",
  "capturedAt": "2026-07-18T00:00:00Z",
  "contentHash": {
    "algorithm": "sha-256",
    "value": "9f2c..."
  },
  "accessStatus": "public"
}

• Evidence MUST be described independently of the claim it supports.
• A source URI SHOULD be supplied when lawful and publicly accessible.
• Captured evidence SHOULD include a timestamp and integrity value.
• Restricted evidence MUST NOT be exposed through a public resolver.

Correction Record Model

A Correction Record documents an identified error, the affected object, the corrected value or interpretation, and the authority responsible for the correction.

{
  "correctionId": "correction-0001",
  "affectedObject": "claim-0001",
  "reason": "Incorrect founding date",
  "previousValue": "2016-01-01",
  "correctedValue": "2015-01-01",
  "correctedBy": "authority-0001",
  "correctedAt": "2026-07-18T00:00:00Z",
  "status": "applied"
}

Corrections MUST preserve an auditable relationship to the prior state. Implementations MUST NOT erase a material historical claim merely because its current status changed.

Registry Record Model

The Registry Record is the canonical envelope that associates an identifier with the entity record and its related technical objects.

{
  "registryVersion": "1.0",
  "id": "360WSE-000283",
  "canonicalUri": "https://360wise.com/resolve/360WSE-000283",
  "status": "active",
  "entity": {
    "type": "Organization",
    "name": "Example Organization"
  },
  "claims": [],
  "relationships": [],
  "authorities": [],
  "verifications": [],
  "provenance": [],
  "continuityEvents": [],
  "recognitionEvents": [],
  "evidence": [],
  "corrections": [],
  "createdAt": "2026-07-18T00:00:00Z",
  "updatedAt": "2026-07-18T00:00:00Z"
}

JSON Representation

Every public registry record MUST be available as valid UTF-8 JSON. Property names are case-sensitive and MUST use the names defined by the applicable schema.

Objectives

• Provide a deterministic machine-readable representation.
• Preserve explicit distinction among record types.
• Support validation before publication or exchange.
• Allow independent systems to consume registry data.

Canonical Record Envelope

{
  "registryVersion": "1.0",
  "id": "360WSE-000283",
  "canonicalUri": "https://360wise.com/resolve/360WSE-000283",
  "status": "active",
  "record": {
    "type": "Organization",
    "name": "Example Organization"
  },
  "createdAt": "2026-07-18T00:00:00Z",
  "updatedAt": "2026-07-18T00:00:00Z"
}

Envelope Requirements

JSON-LD Representation

A conforming implementation SHOULD publish a JSON-LD representation for semantic interoperability.

{
  "@context": [
    "https://schema.org",
    "https://360wise.com/ns/context/v1"
  ],
  "@id": "https://360wise.com/resolve/360WSE-000283",
  "@type": "Organization",
  "identifier": "360WSE-000283",
  "name": "Example Organization",
  "mainEntityOfPage": {
    "@id": "https://360wise.com/resolve/360WSE-000283"
  }
}

• The @id value MUST equal the canonical URI.
• The context MUST use HTTPS.
• Terms MUST resolve to stable documented meanings.
• JSON and JSON-LD representations MUST describe the same canonical record.

Schema Requirements

Public record representations MUST be governed by published, versioned machine-readable schemas.

• Schemas MUST declare a unique version.
• Required properties MUST be explicit.
• Enumerated values MUST be closed unless extensibility is expressly permitted.
• Unknown critical properties MUST cause validation failure.
• Schema changes MUST follow the versioning requirements in this volume.
• Schema documents SHOULD be retrievable through stable HTTPS URIs.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://360wise.com/schema/registry-record/1.0",
  "title": "360WiSE Registry Record",
  "type": "object",
  "required": [
    "registryVersion",
    "id",
    "canonicalUri",
    "status",
    "record",
    "createdAt",
    "updatedAt"
  ],
  "properties": {
    "registryVersion": {
      "type": "string"
    },
    "id": {
      "type": "string",
      "pattern": "^360WSE-[0-9]{6}$"
    },
    "canonicalUri": {
      "type": "string",
      "format": "uri"
    }
  }
}

API Requirements

A conforming Registry API MUST expose predictable resource behavior and machine-readable responses.

Registry REST API

General API Behavior

• Public read operations MUST be safe and idempotent.
• Responses MUST declare a media type.
• Timestamps MUST use RFC 3339.
• Error responses MUST use the standard error object.
• Rate limits SHOULD be communicated through response headers.
• Restricted operations MUST require authorization.

Resolution Responses

A resolution response communicates the status and canonical representation associated with a Resolution Identifier.

Successful Resolution Response

{
  "resolutionStatus": "resolved",
  "id": "360WSE-000283",
  "canonicalUri": "https://360wise.com/resolve/360WSE-000283",
  "record": {
    "type": "Organization",
    "name": "Example Organization",
    "status": "active"
  },
  "resolvedAt": "2026-07-18T00:00:00Z"
}

Returned Properties

Resolution Status Values

Validation Requirements

A record MUST pass syntactic, structural, semantic, identifier, and referential validation before it is published as conforming.

{
  "valid": true,
  "schemaVersion": "1.0",
  "errors": [],
  "warnings": []
}

Versioning

Published schemas, contexts, APIs, and record formats MUST declare a version. Version identifiers MUST remain immutable after publication.

Implementations SHOULD support at least the current major version and the immediately preceding major version during a documented transition period.

Integrity and Hashing

Implementations SHOULD generate cryptographic integrity values for canonical records and evidence artifacts whose unchanged state must be independently verifiable.

• The hashing algorithm MUST be explicitly declared.
• SHA-256 or a stronger approved algorithm SHOULD be used.
• Canonicalization MUST occur before hashing structured data.
• Hash values MUST be represented using a documented encoding.
• A changed canonical representation MUST generate a new integrity value.
• Hashing MUST NOT be described as proof that a claim is factually true.

{
  "algorithm": "sha-256",
  "canonicalization": "RFC8785",
  "encoding": "hex",
  "value": "9f2c3f5a..."
}

Error Handling

HTTP Status Codes

Error Objects

{
  "error": {
    "code": "INVALID_IDENTIFIER",
    "message": "The supplied identifier is invalid.",
    "details": {
      "value": "360WiSE-000283",
      "expectedPattern": "^360WSE-[0-9]{6}$"
    },
    "timestamp": "2026-07-18T00:00:00Z"
  }
}

Required Properties

Standard Error Codes

Record Not Found Example

{
  "error": {
    "code": "RECORD_NOT_FOUND",
    "message": "No registry record was found.",
    "details": {
      "id": "360WSE-999999"
    },
    "timestamp": "2026-07-18T00:00:00Z"
  }
}

Access Denied Example

{
  "error": {
    "code": "ACCESS_DENIED",
    "message": "The requested representation is restricted.",
    "timestamp": "2026-07-18T00:00:00Z"
  }
}

Privacy and Restricted Data

Public resolution records MUST be limited to information appropriate for lawful public disclosure and technical resolution.

• Sensitive personal data MUST NOT be included unless legally authorized and operationally necessary.
• Authentication secrets, private keys, access tokens, and internal credentials MUST never appear in public records.
• Restricted evidence MUST be represented by metadata rather than exposed content.
• Access decisions SHOULD follow least-privilege principles.
• Data retention MUST be proportionate to the purpose of the record.
• Correction and removal requests MUST be handled according to applicable governance and law.

Security Requirements

• All public and restricted API traffic MUST use HTTPS.
• Administrative operations MUST require authenticated authorization.
• Implementations MUST validate all externally supplied input.
• Output encoding MUST prevent injection into consuming systems.
• Secrets MUST be stored outside public source code and public records.
• Material administrative actions SHOULD be auditable.
• Rate limiting and abuse controls SHOULD protect public endpoints.
• Dependencies SHOULD be reviewed and updated according to a documented security process.
• Backups MUST be protected against unauthorized alteration or disclosure.

Security Boundary

Conformance with this volume does not guarantee that an implementation is immune from compromise. Each operator remains responsible for secure deployment, monitoring, incident response, and compliance with applicable law.

Accessibility

Human-readable registry and resolver interfaces SHOULD be usable by people relying on assistive technologies.

• HTML interfaces SHOULD use semantic headings and landmarks.
• Interactive controls MUST be keyboard accessible.
• Text and interface elements SHOULD maintain sufficient contrast.
• Status and error information MUST not rely on color alone.
• Tables MUST include meaningful headers.
• Images containing meaningful information MUST include appropriate text alternatives.
• Machine-readable endpoints MUST remain available independently of visual presentation.

Interoperability

Implementations SHOULD use established public standards whenever those standards accurately represent the required semantics.

Proprietary extensions MUST NOT redefine the meaning of normative fields. Extensions SHOULD use a clearly documented namespace.

Conformance Classes

An implementation MAY claim one or more conformance classes. It MUST NOT claim capabilities it does not implement and test.

Conformance claims SHOULD identify the software version, supported specification version, test date, and applicable conformance class.

Reference Implementations

A reference implementation demonstrates one conforming method of implementing the Canon. It does not prohibit alternative technical designs.

Reference Implementation Requirements

• Identify the supported specification and schema versions.
• Publish a conformance statement.
• Provide reproducible positive and negative test cases.
• Document known implementation limitations.
• Separate required behavior from optional implementation choices.
• Retain traceability between requirements and validation tests.

Governance

The 360WiSE Canon is governed through documented publication, revision, correction, and deprecation procedures.

• Normative changes MUST be versioned.
• Material corrections MUST be recorded in revision history.
• Deprecated technical requirements SHOULD remain accessible.
• Breaking changes MUST include migration guidance.
• Canonical documents MUST identify their publication status.
• Interpretive guidance MUST NOT silently modify normative requirements.

Public Boundaries

The Developer Standards define technical representation and resolution behavior. They do not expand the meaning of verification, recognition, evidence, or registry participation beyond the public Canon.

• Registration is not certification of every claim made by an entity.
• Verification is limited to the recorded verification scope.
• Recognition events are observations, not guarantees of future AI behavior.
• Resolution does not establish legal ownership by itself.
• Integrity hashes establish content consistency, not factual truth.
• Reference implementation status is not exclusivity.
• Conformance does not constitute governmental, regulatory, or professional accreditation.

Related Canon

Volume XI SHOULD be interpreted together with the other official volumes governing identity, authority, evidence, verification, recognition, continuity, provenance, correction, resolution, and public governance.

Revision History

Official Publication

The authoritative version of Volume XI is the version published by 360WiSE® through its official Canon infrastructure. Copies, excerpts, mirrors, or implementation documentation MUST NOT be represented as superseding the canonical publication.