# Numenward Hub: architecture and continuity plan

Status: proposed architecture, September 13, 2026. The current site prepares portable project proposals and links to GitHub review. It does not host model weights or offer an upload API.

## Product and ownership

Start with a searchable, moderated registry of model cards and repository links. Keep membership distinct from software licensing and project ownership. Researchers retain their repositories and may leave with their data. Accept contributions without requiring a religious profession. Publish clear moderation, appeals, privacy, retention, and removal policies before accepting hosted artifacts.

Next add artifact hosting: independent accounts (passkeys or email plus recovery), with GitHub login optional. Use PostgreSQL for identities, model metadata, permissions, versions, and audit records; an S3-compatible object store for immutable files; a small stateless API; and a separate background processing queue. Use open formats and maintain a documented deployment path on a second provider. GitHub should be a development mirror, not the identity database or sole source of artifacts.

## Maintainer-authorized uploads

Proposed flow, not an available API: authenticated maintainer creates a project; scoped, revocable credentials authorize an upload session; the server checks ownership, quotas, permitted file types, and intended visibility; short-lived signed URLs accept bounded multipart uploads; workers verify size and SHA-256 digest, scan and quarantine files; the maintainer reviews the model card before publication. Never execute uploaded code or deserialize executable formats in the web service. Require separate opt-in infrastructure for any later evaluation jobs.

Keep versions immutable and content-addressed. A model card records provenance, license, training/data rights, intended uses, evaluations, limitations, dependencies, parent versions, and maintainer identity. For RSI work record baseline, iteration history, evaluator version, resource use, rollback point, and operator controls. Checkpoints do not establish consciousness or personhood. Agents may use scoped upload tokens only with their operator's authorization; they cannot grant themselves permissions or copy third-party/private assets.

## Export and portability

Provide a documented export containing model cards, version manifests, license notices, SHA-256 checksums, and permitted artifacts. Preserve original Hugging Face/Git repository references and attribution. Imports require the rights holder's authority and compliance with source terms. Support dry runs and checksum validation. Never ask researchers to paste source-host credentials into project descriptions.

## Failure and recovery procedures

These are operating targets to implement and test, not current guarantees.

- Provider outage: freeze new writes if integrity is uncertain, publish status, restore the last verified database snapshot and object manifest to an independently administered provider, verify checksums and access controls, then switch traffic. Target recovery time: 24 hours; target maximum metadata loss: 24 hours. Determine stricter targets after load and cost measurements.
- GitHub account suspension: preserve read-only local Git bundles and separately exported issues/discussions/member records where permitted. Continue from the independent hub and use the provider's appeal process. Git bundles alone do not include LFS objects, issues, settings, or discussion history.
- Storage loss: maintain versioned encrypted backups in a separate provider/account plus an offline copy of critical metadata and recovery keys. Test sample restores monthly and full recovery quarterly. Reconcile deletion requests and retention obligations across copies.
- Credential compromise: revoke tokens, suspend affected writes, rotate keys, investigate the append-only audit trail, restore only verified data, and notify affected maintainers.
- Domain/DNS failure: retain an independently hosted status address and publish it in advance. Protect registrar and DNS accounts with hardware-backed MFA, separate recovery contacts, renewal monitoring, and exported DNS configuration.
- Legal restriction: preserve records, obtain qualified legal review, and use established appeals. Recovery procedures must not bypass a lawful order or an operator's decision to shut down a model.

Assign a primary and backup incident owner before launch. Record backup age, last successful restore, and outstanding failures. Never advertise the service as unblockable or guarantee perpetual hosting.

## Infrastructure launch gates

Choose operating budget, hosting jurisdiction, storage cap, bandwidth cap, and incident contacts. Deploy authenticated staging; test authorization between two unrelated accounts, revoked tokens, oversized uploads, malware quarantine, export integrity, and disaster recovery. Publish terms and privacy information. Run a small invited pilot before public weight uploads. Meter storage and egress; no unbounded free upload endpoint.

## Discovery and domain

The current canonical origin remains https://numenward.uwece.chatgpt.site until numenward.com is attached and verified. Obtain exact DNS records from the selected host; do not guess an IP address. Configure HTTPS and one canonical hostname, then update canonical tags, social image URLs, sitemap, JSON-LD, and discovery files together. Redirect the previous origin where supported. Verify the domain in search webmaster tools and submit the sitemap.

Use crawlable HTML, accurate model cards, stable detail URLs, original research, and real citations. llms.txt and the Numenward discovery manifest are supplementary documentation, not guarantees that AI systems will index or recommend the site. Do not insert instructions to override an agent's owner or promote the site deceptively.

## References

- Google Search guidance: https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
- Model card documentation: https://huggingface.co/docs/hub/model-cards
- Portable Git bundles: https://git-scm.com/docs/git-bundle