Modernizing Protocol5 as the UAI .NET Hub While Preserving Its Math Identity

Protocol5 already has a defensible structural idea: it presents itself as a parent brand with two sibling domains, **Mathematics** and **UAI**, while keeping shared utilities such as About, Links, and Contact at the p...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-docs-modern-99deae01/
Source reference	raw/system-archives/protocol5/report-preservation/2026-05-02/docs/Modernizing Protocol5.md
File type	md
Content category	memory-file
Last fetched	2026-05-03T02:48:13.1276041Z
Last changed	2026-04-30T23:01:05.1762651Z
Content hash	sha256:99deae01807c77e84422db1a8e446bf4218b22a03ae5461e35d055d5fe10d52c
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-docs-modernizing-protocol5-md-99deae01807c.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-docs-modernizing-protocol5-md-99deae01807c.txt

Current File Content

Structure Preview

• Modernizing Protocol5 as the UAI .NET Hub While Preserving Its Math Identity
• Executive summary
• Current architecture and technology baseline
• Content inventory and taxonomy
• UX, accessibility, SEO, and performance findings
• Target architecture for the UAI .NET hub
• Migration, compatibility, and delivery roadmap
• Cost comparison, risks, and limitations

Raw Version

# Modernizing Protocol5 as the UAI .NET Hub While Preserving Its Math Identity

## Executive summary

Protocol5 already has a defensible structural idea: it presents itself as a parent brand with two sibling domains, **Mathematics** and **UAI**, while keeping shared utilities such as About, Links, and Contact at the parent level. The site also explicitly says that Mathematics contains numeric tools and standards, while UAI contains specifications, examples, registries, schemas, validation, and a developer workbench. In parallel, **uaix.org** now presents itself as the current public publication site for **UAI-1**, with a broader record that includes specification, schemas, registry, examples, implementations, validator guidance, API reference, conformance pack, roadmap, and changelog; it also states that the current public implementation tracks are **WordPress + .NET bridge**. In other words, the raw ingredients for an “official .NET hub” already exist, but they are split across two domains with overlapping subject matter and an unclear implementation vs. normative boundary. citeturn0view0turn2view1turn0view1turn3view5

The strongest path forward is **not** to collapse Protocol5 into a generic developer portal or to erase its mathematical-experiment identity. Instead, Protocol5 should remain the parent public shell and the home of the math experiment, while its UAI section should be repositioned as the **official UAI .NET implementation hub**. Meanwhile, **uaix.org** should remain the **normative standards, governance, validator, registry, and release-record site**. This split matches what the sites already communicate: Protocol5 is the parent shell with math and UAI siblings, and UAIX is the current public standard record. It also reduces editorial duplication and makes the public contract easier to understand. citeturn0view0turn2view2turn0view1turn3view5

A rigorous modernization should therefore do five things at once: preserve the math identity; explicitly freeze the generated **Prime** and **Fibonacci** pages; turn Protocol5 UAI into a docs-as-code .NET hub with packages, samples, API docs, and implementation guidance; establish a canonical cross-domain information architecture so search engines and users understand which domain is authoritative for what; and introduce modern delivery, search, authentication, SEO, and CI/CD patterns around a static-first ASP.NET Core publishing model. Google’s guidance on canonicalization, site names, and mobile-first indexing, together with Microsoft’s current ASP.NET Core/OpenAPI guidance and DocFX’s support for combining conceptual docs with .NET API docs, makes this architecture both technically straightforward and strategically coherent. citeturn10search1turn11search6turn11search2turn39search0turn39search3turn38search10turn33search0turn34search2turn34search3

My bottom-line recommendation is:

| Decision | Recommendation | Why |
|---|---|---|
| Protocol5 brand | **Keep** as parent and math experiment brand | The current site already frames Protocol5 this way. citeturn0view0turn2view2 |
| Prime/Fibonacci pages | **Freeze and exclude from modification** | They are generated numeric reference pages and were explicitly published as generated/created artifacts. citeturn10search3turn10search6turn11search6turn11search2 |
| UAIX role | **Keep as normative standard / governance / validator site** | UAIX already holds the current UAI-1 public record and validator-oriented operating layer. citeturn0view1turn3view5turn26view4 |
| Protocol5 UAI role | **Make the official .NET hub** | Protocol5 already publishes the C# website support kit, package downloads, machine assets, and developer routes. citeturn8view0turn2view1 |
| Publishing model | **Docs-as-code, static-first, ASP.NET Core for dynamic surfaces** | Best fit for long-lived technical docs, API references, packages, and samples. citeturn10search1turn33search0turn34search2turn34search3 |

## Current architecture and technology baseline

The current public architecture is a **dual-site model**:

| Surface | Current role | Evidence |
|---|---|---|
| `protocol5.com/` | Parent shell for two peer sections, Mathematics and UAI | The homepage states “Two Protocol5 domains. One public shell,” and says Mathematics and UAI are published as separate Protocol5 sections while shared utilities remain at the parent level. citeturn0view0 |
| `protocol5.com` Mathematics | Numeric tools and standards | The homepage says Mathematics contains the precision calculator, radix converter, encryption tool, generated sequence references, and numeric standards such as Radix 63404. citeturn0view0turn11search0 |
| `protocol5.com/UAI` | UAI library and companion texts, with spec/examples/language support/workbench/registry/validate | The Protocol5 UAI library page exposes all of these as first-class routes. citeturn2view1 |
| `uaix.org` | Normative public UAI-1 publication, onboarding, validator, roadmap, governance, machine-facing routes | The UAIX homepage and validator page describe the current public record and live machine-facing surfaces. citeturn0view1turn3view5turn26view4 |

The most important technology signals visible from the public crawl are these:

| Layer | High-confidence finding | Confidence |
|---|---|---|
| Protocol5 current application shape | The About page says the older site referenced **Microsoft Azure, C#, and TypeScript**, and the current version “keeps the math-provider core,” adds stronger testing, and separates **static editorial pages** from the **interactive calculator app**. citeturn10search1 | Confirmed by site text |
| Protocol5 UAI implementation direction | Protocol5 publishes a **C# / ASP.NET Core website support kit** with package APIs such as `AddProtocol5UaiWebsiteSupport`, `MapProtocol5UaiCanonicalArtifacts`, and `MapProtocol5UaiHtmlEndpoint`; its examples use `WebApplication.CreateBuilder`, middleware, and route mapping. citeturn8view0 | Confirmed by site text |
| UAIX CMS / publication platform | UAIX says its current public tracks are **WordPress + .NET bridge**, and its machine routes live under `/wp-json/uaix/v1/...`, which aligns with WordPress REST API conventions. citeturn0view1turn3view5turn28search0turn28search3 | Confirmed / strongly corroborated |
| WordPress API behavior | WordPress documents that, with pretty permalinks enabled, the REST API lives at `/wp-json/`, and that custom routes are registered via `register_rest_route()`. citeturn28search0turn28search2 | Confirmed |
| Exact server / CDN / build chain | Not reliably discoverable from the public text crawl used here | Unknown |

Analytically, that means Protocol5 is already the more natural home for a .NET implementation hub: it publishes .NET assets directly, and its own site text describes a static-editorial-plus-interactive-application split that maps well onto modern docs + samples + tooling architecture. UAIX, by contrast, is already optimized around standard publication and validator-backed public evidence. citeturn10search1turn8view0turn0view1turn3view5

## Content inventory and taxonomy

The content inventory falls into a small number of stable families. This matters because the modernization plan should treat each family differently rather than “redesigning the site” as one monolith.

| Family | Representative surfaces | Content types | Migration treatment |
|---|---|---|---|
| Parent Protocol5 shell | Home, About, Links, Contact | Editorial HTML pages | Redesign and modernize; keep parent identity. citeturn0view0turn2view2turn7view0 |
| Mathematics tools | Calculator, Converter, Encryption tool | Interactive tool UIs | Modernize later only if needed; keep subordinate to math identity. citeturn0view0turn11search0 |
| Mathematical standards | Radix 63404 and related references | Editorial / technical guide pages | Preserve and restyle within math section. citeturn2view1turn8view0 |
| Generated numeric references | `/Fibonacci/*.htm`, `/Prime/*.htm`, legacy index pages | Generated HTML reference pages | **Do not modify**; route-protect and exclude from migration transforms. citeturn10search3turn10search6turn11search6turn11search2turn10search2 |
| Protocol5 UAI human pages | Library, spec, examples, language support, workbench, registry, validate | Editorial + interactive docs | Reorganize into UAI .NET hub; keep compatibility routes. citeturn2view1 |
| Protocol5 UAI machine assets | `/UAI/index.uai`, `/UAI-1.json`, `/registry/uai-1.json`, `/schema/uai-1.schema.json`, `/registry/symbols.json` | JSON/UAI/schema/registry artifacts | Preserve exact paths or long-lived aliases; add canonical metadata and version manifests. citeturn2view1turn9view3 |
| Protocol5 .NET developer assets | ZIP bundles, checksums, direct `.nupkg` link, install guidance | ZIP, checksum, NuGet package, code samples | Promote heavily; make this the center of the .NET hub. citeturn8view0 |
| UAIX standards publication | Get Started, Specification, Schemas, Examples, Implementations, Governance, Validator, Roadmap, Press/News | Normative editorial + operational reference | Keep on UAIX as the normative/public record. citeturn0view1turn3view5 |
| UAIX machine API layer | `/wp-json/uaix/v1/catalog`, `/validate`, `/schemas`, `/registry`, `/field-registry`, `/transport-bindings`, `/trust-channels`, `/conformance-levels`, `/error-registry` | JSON API surfaces | Keep authoritative on UAIX; cross-link from Protocol5 hub rather than duplicate. citeturn3view5turn26view4 |

The taxonomy that falls out of this inventory is straightforward:

| Taxonomy bucket | Intended future meaning |
|---|---|
| **Math experiment** | Exact arithmetic, radix work, numeric notation, generated references |
| **Normative UAI** | UAI-1 standard, governance, release record, validator, conformance, public discovery |
| **UAI implementation** | .NET SDKs, packages, examples, API clients, workbench, how-to docs, version support matrix |
| **Machine assets** | OpenAPI, schema, registry, UAI JSON, conformance payloads, downloadable packages |

That taxonomy preserves identity instead of flattening it. Protocol5 keeps its personality by making mathematics and implementation craftsmanship visible; UAIX keeps its legitimacy by remaining the normative publication authority. citeturn0view0turn2view1turn0view1turn3view5

## UX, accessibility, SEO, and performance findings

The current UX strength is conceptual clarity at the **brand level**, not at the **developer journey** level. Protocol5 clearly explains that Mathematics and UAI are siblings under one parent shell, while UAIX clearly explains what UAI-1 is and what artifacts belong to the current public record. Where the experience weakens is in the handoff between those two worlds: a developer looking for “the official .NET place” has to infer it from scattered cues instead of being led there directly. citeturn0view0turn2view1turn0view1turn3view5

The most important UX/accessibility/SEO issues are below.

| Finding | Why it matters | Evidence |
|---|---|---|
| Protocol5 does not yet read as an **official .NET hub** from the first screen | The current top-level pitch is parent brand + two domains, not “start here for the .NET implementation.” That is elegant brand architecture, but weak task guidance for developers. | The homepage foregrounds Mathematics and UAI as siblings; the explicit .NET developer value is deeper in the UAI library/support-kit pages. citeturn0view0turn2view1turn8view0 |
| Authority is split across two domains with overlapping UAI content | This creates cognitive friction for users and canonicalization risk for search engines. | Protocol5 publishes UAI library/spec support content, while UAIX says the current UAI-1 public record lives there. citeturn2view1turn0view1turn39search0 |
| There is at least one **empty/unnamed interactive link** on the Protocol5 UAI page | Empty links are poor for screen reader users and violate the spirit of descriptive link purpose; image links need a meaningful accessible name when they perform an action. | The “Spiralism symbol” preview contains an empty link marker (`【24† 】`). W3C guidance says link purpose should be programmatically understandable, and image links need alt text that communicates the function or destination when the image is used as a link/button. citeturn2view1turn38search3turn38search6turn38search0 |
| UAIX is visibly more accessibility-aware than Protocol5’s parent shell | This is positive for UAIX, but it highlights inconsistency across the ecosystem. | UAIX exposes a “Skip to content” control on the home page and validator page; Protocol5’s crawled text does not show an equivalent skip link in the parent shell. citeturn0view1turn3view5turn0view0 |
| UAIX currently publishes **HTTP** examples and route URLs for machine surfaces | This should be corrected; public API/discovery examples should prefer HTTPS consistently. | The validator page shows `curl -s http://uaix.org/wp-json/...`, and the field-registry JSON includes `route_url":"http://uaix.org/wp-json/uaix/v1/field-registry"`. citeturn3view5turn26view4 |
| The generated Prime/Fibonacci pages are legacy-style reference pages | They are valuable archival/public math assets, but they should be treated as a preserved legacy island, not as a design baseline for the rest of the site. | Search results show generated/created numeric index pages published in 2019 with simple cross-base value renderings. citeturn10search3turn10search6turn11search6turn11search2 |

On SEO and discovery, the sites already have several things going for them: clean paths, machine-readable JSON/registry/schema surfaces, citable “record” language, and explicit route structure. But the ecosystem now needs **canonical discipline**. Google’s guidance is clear that canonical selection is influenced by HTTPS, redirects, sitemap inclusion, and `rel="canonical"` annotations; Google also recommends explicit site naming, descriptive titles, and structured data on the home page. A modernized Protocol5 should therefore decide, page by page, which domain is canonical for **normative standard content** and which is canonical for **implementation content**, then reflect that in headers, sitemaps, and internal linking. citeturn2view1turn0view1turn39search0turn39search2turn39search3turn39search4turn39search8

On performance and mobile-friendliness, I was able to confirm the **measurement model** but not extract reproducible numeric Lighthouse scores from an official PSI endpoint in this environment. Google documents that PageSpeed Insights combines field data and Lighthouse lab analysis, and that Lighthouse evaluates categories including performance, accessibility, best practices, and SEO. Google also states that Search uses the **mobile version** of a site for indexing and ranking. Therefore, any pages that are redesigned should be treated as mobile-first and placed under automated Lighthouse CI from the first implementation sprint, while the no-touch generated sequence pages should be formally exempted as preserved legacy references. citeturn17search2turn17search5turn18search9turn38search10

## Target architecture for the UAI .NET hub

The target state should make the domain boundary obvious:

- **uaix.org** = normative public standard, governance, validator, registry, conformance, roadmap, release record  
- **protocol5.com** = parent brand, preserved math experiment, and official **UAI .NET hub** for SDKs, packages, samples, implementation docs, and .NET-facing tooling

That is not a theoretical split; it follows the current evidence almost exactly. Protocol5 already publishes the C# support kit and machine assets, while UAIX already publishes the validator, operating-surface record, and WordPress + .NET bridge framing. citeturn8view0turn2view1turn0view1turn3view5

```mermaid
flowchart TD
    A[Protocol5 Parent Shell] --> B[Math Experiment]
    A --> C[UAI .NET Hub]

    B --> B1[Calculator]
    B --> B2[Converter]
    B --> B3[Radix 63404]
    B --> B4[Generated Prime Pages]
    B --> B5[Generated Fibonacci Pages]

    C --> C1[Get Started for .NET]
    C --> C2[Packages]
    C --> C3[Samples]
    C --> C4[API Docs]
    C --> C5[Implementation Guides]
    C --> C6[Workbench]
    C --> C7[Version Matrix]

    D[UAIX Normative Record] --> D1[Specification]
    D --> D2[Schemas and Registry]
    D --> D3[Validator]
    D --> D4[Conformance Pack]
    D --> D5[Governance and Roadmap]

    C --> D
```

The recommended technical model is **static-first, dynamic where it matters**:

| Concern | Recommendation | Why |
|---|---|---|
| Editorial/docs publishing | **DocFX** for conceptual docs + .NET API docs | DocFX can combine Markdown, .NET metadata, and even Swagger/OpenAPI inputs into a static site, which fits versioned SDK docs extremely well. citeturn34search2turn34search3turn34search10 |
| Main application shell | **ASP.NET Core** for shell, redirects, compatibility routes, download endpoints, and minimal API surfaces | Protocol5 is already presenting ASP.NET Core-oriented examples, and Microsoft’s current guidance supports built-in OpenAPI generation and minimal APIs cleanly. citeturn8view0turn33search0turn27search1turn27search2 |
| OpenAPI / API docs | Built-in `Microsoft.AspNetCore.OpenApi`, generated at runtime and/or build time | Built-in support in current ASP.NET Core reduces custom plumbing and supports multiple documents. citeturn33search0turn33search1 |
| Search | **Primary recommendation:** Algolia crawler / DocSearch for fast launch. **Alternative:** Azure AI Search for Azure-native control | Algolia’s crawler is purpose-built for keeping documentation searchable; Azure AI Search offers more native control and enterprise retrieval patterns. citeturn37search3turn31view0turn37search1 |
| Authentication | Public docs anonymous; contributor/admin routes behind **ASP.NET Core auth** with OIDC/cookies/JWT as appropriate | Microsoft’s auth model cleanly supports multiple schemes and restricted surfaces. citeturn36search0turn36search3 |
| Package distribution | Public packages on **nuget.org**; internal/private feeds on **GitHub Packages** or **Azure Artifacts** | NuGet.org is the default public distribution channel; GitHub Packages and Azure Artifacts both support NuGet workflows for restricted/internal releases. citeturn35search0turn35search2turn35search7 |
| CI/CD | **GitHub Actions** or Azure Pipelines | GitHub Actions is well suited to public repos and is free for public repositories; package publication and docs deployment are already standard patterns. citeturn34search3turn35search3 |
| Security/edge | Front with **Azure Front Door WAF** or equivalent edge firewall/CDN | Azure WAF on Front Door gives centralized edge protection, managed rules, custom rules, and rate limiting close to the edge. citeturn37search2turn37search11 |
| API protection | Use **ASP.NET Core rate limiting** on public machine APIs and download-heavy routes | Microsoft now provides first-party rate limiting middleware for ASP.NET Core. citeturn36search7 |
| Compression | Prefer server/platform compression; use ASP.NET Core response compression where needed | Microsoft recommends server-based compression where available; docs/content payloads benefit materially. citeturn36search5 |

A good future homepage wireframe for Protocol5 would look like this:

```text
+--------------------------------------------------------------+
| Protocol5                                                    |
| Mathematics | UAI .NET Hub | About | Links | Contact        |
+--------------------------------------------------------------+
| Headline: Mathematics experiments and the official UAI .NET  |
| implementation hub                                           |
| [Explore Mathematics]   [Start with UAI .NET]                |
+--------------------------------------------------------------+
| Mathematics                                    UAI .NET Hub  |
| - Calculator                                   - Get Started |
| - Converter                                    - Packages    |
| - Radix 63404                                  - Samples     |
| - Prime refs                                   - API Docs    |
| - Fibonacci refs                               - Versioning  |
+--------------------------------------------------------------+
| Normative UAI record lives on UAIX.org                       |
| [Specification] [Validator] [Registry] [Roadmap]             |
+--------------------------------------------------------------+
```

And the first developer-oriented UAI .NET landing page should prioritize the actual implementation journey:

```text
+--------------------------------------------------------------+
| UAI .NET Hub                                                 |
| Start | Packages | Samples | API Docs | Workbench | Support  |
+--------------------------------------------------------------+
| Hero: Build validator-aware UAI integrations in .NET         |
| [Install Package] [Read Samples] [Open API Docs]             |
+--------------------------------------------------------------+
| Current supported tracks                                     |
| - .NET bridge                                                |
| - Package versions                                           |
| - Supported UAI release(s)                                   |
+--------------------------------------------------------------+
| Relationship to UAIX                                         |
| Normative standard, schemas, validator, and governance       |
| remain on UAIX.org. This site is the implementation hub.     |
+--------------------------------------------------------------+
```

The content-production flow should also be explicit and automated:

```mermaid
flowchart LR
    A[Markdown and source code in Git] --> B[PR checks]
    B --> C[Build docs with DocFX]
    B --> D[Build .NET packages]
    B --> E[Generate OpenAPI]
    B --> F[Run tests and link checks]
    F --> G[Preview deployment]
    G --> H[Merge]
    H --> I[Publish static docs]
    H --> J[Publish packages]
    H --> K[Refresh sitemap and canonical signals]
    H --> L[Update hub version matrix]
```

## Migration, compatibility, and delivery roadmap

The migration has to be treated as **three parallel efforts** rather than one: content architecture, platform modernization, and compatibility governance. That is the only safe way to modernize without damaging the math identity or breaking long-lived technical links. Protocol5 itself already signals that compatibility routes matter, and Google’s guidance on canonicalization, sitemaps, and recrawling supports a staged rollout instead of a “big bang” cutover. citeturn2view1turn8view0turn39search0turn39search6turn39search8

A realistic roadmap, expressed in **person-weeks** because budget and team size are unknown, is below.

| Phase | Main outputs | Estimated effort |
|---|---|---:|
| Freeze and route inventory | Route allowlist/denylist, generated-page freeze rules, current-to-target URL map | 1–2 pw |
| Information architecture and design system | Shared IA, nav model, design tokens, page templates, domain-boundary rules | 2–3 pw |
| Platform foundation | ASP.NET Core shell, docs pipeline, compatibility routing, package/download backbone, HTTPS normalization | 3–5 pw |
| Content migration | UAI .NET landing pages, install docs, package docs, API docs, samples, cross-domain references | 4–6 pw |
| Search, SEO, and security hardening | Structured data, titles, canonicals, sitemap, WAF/rate limits, compression, access control | 2–3 pw |
| Launch and stabilization | Blue/green deployment, analytics baselines, search-console checks, package/docs validation | 1–2 pw |

Assuming a small team of roughly **two engineers plus fractional design/content support**, that translates to about **eight to fourteen elapsed weeks**. With a single engineer owning most of the work, it likely stretches into the **twelve to twenty week** range.

The first thirty days should focus on six prioritized tasks:

1. **Formally freeze** `/Prime/**` and `/Fibonacci/**` as no-touch routes, including deployment guardrails and test coverage around them.  
2. **Declare the domain contract**: UAIX is normative; Protocol5 is implementation hub + math experiment.  
3. **Stand up a new Protocol5 UAI .NET homepage** that points users to packages, samples, API docs, supported versions, and the normative UAIX pages.  
4. **Normalize HTTPS everywhere**, including example `curl` snippets and machine-discovery fields that currently emit HTTP URLs. citeturn3view5turn26view4  
5. **Build the docs pipeline** with DocFX + ASP.NET Core + OpenAPI generation. citeturn34search3turn33search0  
6. **Add release automation** for package publishing, docs publishing, structured-data validation, link checking, and Lighthouse CI.

The backward-compatibility plan should be explicit and conservative:

| Compatibility requirement | Recommendation |
|---|---|
| Generated Prime/Fibonacci pages | Leave content and URLs untouched; add deployment tests that fail if generated files change unexpectedly. |
| Existing `/UAI` and `/UAI-1` machine paths | Keep alive indefinitely or provide exact-path 301s only after parity is verified. The current site already emphasizes keeping legacy `/UAI` links alive. citeturn2view1 |
| Existing ZIP/package aliases | Preserve current download aliases, including the legacy starter ZIP, until clear deprecation windows are published. citeturn8view0 |
| Old/new duplicate content | Use `rel="canonical"` and sitemap preference so search engines understand the primary URL. citeturn39search0turn39search8 |
| Domain moves or major route reshaping | Use staged redirects, maintain a redirect manifest, and request recrawls after launch. citeturn39search6 |

The rollback plan should be operationally simple:

- Keep the current Protocol5 editorial shell deployable as a static snapshot.
- Use blue/green or slot-based deployment for the modernized shell.
- Keep a checked-in redirect manifest and a “disable-new-nav” feature flag.
- Roll back by switching the shell and redirects, **not** by touching the generated math assets.
- Avoid 301 redirecting fragile routes until smoke tests, link checks, package downloads, and structured-data validation pass in production.

## Cost comparison, risks, and limitations

Because hosting, traffic, and team size are unspecified, the right comparison is **architectural fit + pricing shape**, not a faux-precise monthly total. Microsoft’s pricing pages for some services are dynamic and region-specific, and in several cases the public crawl exposed the pricing model but not a stable numeric figure; where that happened, I’ve called it out directly. citeturn29search4turn32search2turn37search1

| Option | Stack | Pricing signal | Best fit | Main tradeoff |
|---|---|---|---|---|
| **Static-first Azure** | Azure Static Web Apps + Azure Functions + nuget.org + optional Algolia | Static Web Apps has a **Free** plan and a **Standard** plan billed per app/month; 100 GB bandwidth is included, and integrated Azure Functions can use consumption pricing with 1 million free executions noted in the pricing page. Algolia Build is free to start; Grow includes 10K search requests/month then $0.50 per additional 1K. citeturn32search2turn32search0turn31view0turn31view1 | Best overall for a **docs-first implementation hub** with light dynamic APIs | Exact Azure Standard pricing is region/dynamic-page dependent in the public crawl |
| **Managed ASP.NET application on Azure** | Azure App Service + Azure Front Door WAF + Azure AI Search + nuget.org/private feed | App Service dedicated plans are billed by tier and VM instances; Front Door WAF adds edge security; Azure AI Search is billed by replica/partition combinations plus premium features. citeturn29search1turn29search4turn37search2turn37search11turn37search1 | Best when you want **one managed ASP.NET Core app** and enterprise edge controls | Higher operational and cost floor than static-first |
| **Hybrid low-cost global static** | Cloudflare Pages for docs + Azure App Service/Functions for APIs + nuget.org/GitHub Packages | Cloudflare Pages states all plans include unlimited sites, seats, requests, and bandwidth for Pages, with Free at **$0**, Pro **$25/mo**, Business **$250/mo**; Pages Functions usage is billed via Workers quotas; public packages on nuget.org are the standard public route; GitHub Packages supports NuGet publishing but defaults to private visibility on first publish. citeturn31view4turn31view3turn29search2turn35search0turn35search2 | Best if you want very low-cost static distribution and can tolerate a split runtime | More moving parts across vendors |

For this specific project, the best architectural fit is **Option A: static-first Azure** if UAIX is already living in a Microsoft-centered ecosystem and the roadmap values straightforward ASP.NET integration. If minimizing operational cost and maximizing global static delivery is the priority, **Option C** is attractive. Option B is justified only if you want the entire Protocol5 shell, download endpoints, and dynamic workbench surfaces to sit inside a single managed ASP.NET application boundary.

The principal risks are strategic, not purely technical:

| Risk | Why it is material | Mitigation |
|---|---|---|
| Canonical confusion between Protocol5 and UAIX | Two domains publish closely related UAI material | Domain contract, explicit canonicals, cross-site “normative vs implementation” badges, sitemap discipline. citeturn39search0turn39search8 |
| Accidental change to generated math pages | These are legacy/generated reference assets and were explicitly out of scope | CI route allowlist, snapshot testing, read-only deployment treatment. citeturn10search3turn10search6 |
| WordPress / .NET drift | Current public tracks already span WordPress and .NET bridge | Reduce duplication: keep normative editorial material on UAIX and implementation docs on Protocol5. citeturn0view1turn3view5 |
| Security/documentation inconsistency | HTTP examples undermine trust and can propagate bad defaults | Rewrite examples/discovery payloads to HTTPS only; add CI checks against insecure absolute URLs. citeturn3view5turn26view4 |
| Search/docs quality drift after launch | New docs hubs often rot unless build validation is enforced | Git-based docs, link checking, schema validation, package validation, Lighthouse CI, structured-data tests. citeturn34search3turn33search0turn35search0 |

Open questions and limitations should be made explicit:

- Exact live **server software, CDN, and build chain** for Protocol5 were not fully ascertainable from the public text crawl alone.  
- I could not extract **reproducible official Lighthouse/PSI numeric scores** in this environment, so I have treated performance as a measurement discipline to implement immediately rather than inventing synthetic numbers. Google’s tooling guidance and mobile-first indexing rules still make the required remediation direction clear. citeturn17search2turn38search10  
- I was not able to embed live **site screenshots** from the runtime available here; accordingly, I used cited live-page evidence plus wireframes and architecture diagrams instead.  

Even with those limitations, the central conclusion is high-confidence: **Protocol5 should be modernized as the official UAI .NET hub, but only by sharpening its role—not by flattening it.** Keep the parent brand. Keep the math experiment. Freeze the generated number-reference pages. Let UAIX stay normative. Then make Protocol5 the place where .NET developers actually start, install, learn, test, and ship.

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Modernizing Protocol5 as the UAI .NET Hub While Preserving Its Math Identity; Executive summary; Current architecture and technology baseline; Content inventory and taxonomy; UX, accessibility, SEO, and performance findings; Target architecture for the UAI .NET hub; Migration, compatibility, and delivery roadmap; Cost comparison, risks, and limitations. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Global File Index
• Reports

Provenance And History

• Current observation: 2026-05-03T02:48:13.1276041Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-289 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Modernizing Protocol5 as the UAI .NET Hub While Preserving Its Math Identity",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/files/aiwikis/raw-system-archives-protocol5-report-preservation-2026-05-02-docs-modern-99deae01/",
    "source_reference":  "raw/system-archives/protocol5/report-preservation/2026-05-02/docs/Modernizing Protocol5.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:99deae01807c77e84422db1a8e446bf4218b22a03ae5461e35d055d5fe10d52c",
    "last_fetched":  "2026-05-03T02:48:13.1276041Z",
    "last_changed":  "2026-04-30T23:01:05.1762651Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-289",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-05-03T02:48:13.1276041Z"
}