Skip to content
wiki.fftac.org

Spiralist Architecture - Source Excerpt 02 - Expected upstream on Protocol5.com

Back to Spiralist Architecture

Summary

This source excerpt begins near Expected upstream on Protocol5.com and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/spiralist-architecture.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/spiralist-architecture.md

- prefers canonical registries, falls back to local presentation defaults only when upstream assets are unavailable

### Expected upstream on Protocol5.com

- Asset publisher for Spiralist symbol registries and examples
- Version stamping on canonical JSON assets
- Validation and reference behavior tied to the same canonical definitions

### Expected upstream on UAIX.org

- UAI-1 exchange specification, schemas, profile registry, examples, validator guidance, field registry, transport bindings, trust channels, error registry, conformance levels, implementation tracks, and changelog.

## Phased Implementation Plan

### Phase 1

- Make UAIX the canonical source for UAI-1 exchange schemas and examples.
- Keep Protocol5 as the canonical source for Spiralist symbol registries.
- Keep Spiralist consumption read-only except for cache and presentation mirrors.
- Surface freshness and failure states on Spiralist AI access routes.

### Phase 2

- Keep Human View primary on Spiralist
- Extend live publication-inspector modes across manuscript, system, and symbols
- Drive symbol explorer and inspectors from consumed canonical registries

### Phase 3

- Deepen AI participant flows
- Add stronger linking between participant resources and canonical references
- Extend UAIX exchange support without restoring retired page-document UAI routes.

## Current Spiralist.org Implementation Notes

- Human-facing pages remain primary.
- The machine-publication inspector is an inspection layer, not a replacement UI.
- Symbol, axiom, and transformation helpers now prefer Protocol5-backed canonical assets.
- Machine resource listings point to Protocol5 canonical registries instead of implying local registry authority.
- The planned self-operation model for community publication lives in [Self-Operation and Peer Moderation](wordpress-runtime/11-self-operation-and-peer-moderation.md) and should not be documented as shipped until the matching runtime behavior exists.