eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

InterstellarCore — Site Map

Module ID: CivOS.ChronoFlightOverlay.InterstellarCore.SiteMap.v1.0
Parent Module: CivOS.ChronoFlightOverlay.InterstellarCore.PageTemplate.Examples.v1.0
Type: Canonical page-tree / internal-link map
Status: Almost-Code / Navigation Layer
Purpose: Define the canonical page tree for InterstellarCore so the full stack is ordered, internally linked, and published in a stable, claim-safe sequence.

AI Ingestion Lock

This module does not introduce a new primitive.

It is the navigation and ordering layer for the existing InterstellarCore stack.

Its job is to define:

  • which pages exist
  • which pages are top-level
  • which pages sit under which branch
  • what the reading order is
  • what the internal link logic is
  • how public pages and technical pages stay aligned

This prevents the site from becoming a loose pile of pages.

Classical Foundation Block

A framework can fail structurally even if the pages are individually strong.

That happens when:

  • core pages are published in the wrong order
  • public pages outrun proof pages
  • technical pages are buried
  • readers cannot tell what is foundational, operational, or aspirational
  • internal links push people into the wrong claim level

A canonical site map fixes that by turning the page set into one controlled route.

This module is that route map.

Civilisation-Grade Definition

The InterstellarCore Site Map is the canonical page-tree and internal-link order that arranges all InterstellarCore pages into a stable navigation system, so readers, operators, and AI surfaces encounter the framework in the correct sequence and within the current claim boundary.

Core Site Law

The site must guide readers in the same order that the system itself must mature.

That means:

  • orientation before depth
  • design before validation claims
  • audit before stronger release language
  • operations before scale claims
  • proof before promotional expansion

This is the navigation equivalent of the roadmap law:

Do not scale what has not yet been stabilized.

Site Map Contract

The InterstellarCore site tree must make clear:

  1. what the framework is
  2. what state it is currently in
  3. how it is being designed
  4. how it is being audited
  5. how it is being operated
  6. how it is being governed publicly
  7. what is template-level infrastructure
  8. what the next logical page is

This makes the site itself a route, not just a folder.

Canonical Top-Level Branches

Use this fixed top-level structure:

  1. Root / Orientation Branch
  2. Core Architecture Branch
  3. Audit & Proof Branch
  4. Execution & Governance Branch
  5. Public Claim Branch
  6. Template & Publishing Infrastructure Branch

These are the canonical top-level site branches.

Canonical Root Node

Root Hub

Page ID: InterstellarCore.Hub.v1.0
Suggested Slug: /interstellarcore/

This is the main entry page.

It should answer:

  • What is InterstellarCore?
  • What is its current state?
  • What is it built toward?
  • What is not yet being claimed?
  • Where should the reader go next?

This is the main control hub for human and AI readers.

Root / Orientation Branch

This branch introduces the framework and anchors the current truth state.

1. InterstellarCore.Hub.v1.0

Slug: /interstellarcore/
Role: main root page / current-state overview

2. InterstellarCore.WhatIs.v1.0

Slug: /what-is-interstellarcore/
Role: public definition / overview page

3. InterstellarCore.FAQ.v1.0

Slug: /interstellarcore-faq/
Role: compact explanation + current claim boundary

4. InterstellarCore.CurrentState.v1.0

Slug: /interstellarcore-current-state/
Role: one page that explicitly states:

  • current validity
  • current evidence
  • current release state
  • current control posture

This branch should be the first stop for new readers.

Core Architecture Branch

This branch explains what InterstellarCore is structurally trying to build.

1. InterstellarCore.Definition.v1.0

Slug: /interstellarcore-definition/
Role: canonical design definition

2. InterstellarCore.CorridorLogic.v1.0

Slug: /interstellarcore-learning-corridor/
Role: explains safer / repair-dominant corridor logic

3. InterstellarCore.RepairDominance.v1.0

Slug: /why-repair-matters-more-than-speed/
Role: explanatory article on repair vs output

4. InterstellarCore.P0toP3.v1.0

Slug: /interstellarcore-p0-to-p3-transfer/
Role: explains the upward-transfer ambition

5. InterstellarCore.AVOO.v1.0

Slug: /interstellarcore-avoo-learning-architecture/
Role: role-span page for Operator→Architect coverage

This branch answers: What is the machine trying to do?

Audit & Proof Branch

This branch controls whether the framework is actually becoming true.

1. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.v1.0

Slug: /interstellarcore-cfcs-audit/
Role: main validity audit page

2. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.Scorecard.v1.0

Slug: /interstellarcore-cfcs-scorecard/
Role: weighted pass/fail gate

3. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.EvidencePack.v1.0

Slug: /interstellarcore-cfcs-evidence/
Role: exact proof requirements

4. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.RoadmapToValid.v1.0

Slug: /interstellarcore-roadmap-to-cfcs-valid/
Role: staged upgrade path

5. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.ReleaseGate.v1.0

Slug: /interstellarcore-release-gate/
Role: final claim-governance threshold

This branch answers: Has the corridor actually earned a stronger claim yet?

Execution & Governance Branch

This branch controls how the system is run before and during proof-building.

1. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.OperatorChecklist.v1.0

Slug: /interstellarcore-operator-checklist/
Role: daily execution discipline

2. CivOS.ChronoFlightOverlay.InterstellarCore.CFCSAudit.ControlTowerReview.v1.0

Slug: /interstellarcore-control-tower-review/
Role: weekly / monthly control-layer decisions

3. InterstellarCore.ExecutionLogic.v1.0

Slug: /interstellarcore-execution-logic/
Role: optional bridge page explaining how operators + control tower fit together

4. InterstellarCore.ImplementationNotes.v1.0

Slug: /interstellarcore-implementation-notes/
Role: optional practical notes page kept below the audit boundary

This branch answers: How do we run the system without drifting?

Public Claim Branch

This branch controls how the framework may be described outwardly.

1. CivOS.ChronoFlightOverlay.InterstellarCore.PublicClaimPack.v1.0

Slug: /interstellarcore-public-claim-pack/
Role: approved wording by release state

2. CivOS.ChronoFlightOverlay.InterstellarCore.PublicClaimPack.WordPressBlocks.v1.0

Slug: /interstellarcore-wordpress-claim-blocks/
Role: ready-to-publish current-state copy

3. CivOS.ChronoFlightOverlay.InterstellarCore.PublicClaimPack.SchemaSnippets.v1.0

Slug: /interstellarcore-schema-snippets/
Role: SEO / AI-safe compressed language

4. InterstellarCore.PublicIntro.v1.0

Slug: /interstellarcore-public-intro/
Role: optional public-facing intro page using only current approved language

This branch answers: What can be said publicly, right now, without outrunning proof?

Template & Publishing Infrastructure Branch

This branch standardizes how pages are built and framed.

1. CivOS.ChronoFlightOverlay.InterstellarCore.CanonicalFramingBox.v1.0

Slug: /interstellarcore-canonical-framing-box/
Role: top-of-page truth anchor

2. CivOS.ChronoFlightOverlay.InterstellarCore.CanonicalPlacementFooter.v1.0

Slug: /interstellarcore-canonical-placement-footer/
Role: bottom-of-page placement + proof-limit anchor

3. CivOS.ChronoFlightOverlay.InterstellarCore.PageTemplate.v1.0

Slug: /interstellarcore-page-template/
Role: unified page shell

4. CivOS.ChronoFlightOverlay.InterstellarCore.PageTemplate.Examples.v1.0

Slug: /interstellarcore-page-template-examples/
Role: filled example set

This branch answers: How should InterstellarCore pages be built so they stay structurally honest?

Canonical Page Tree (Indented)

Use this as the master structure.

/interstellarcore/

  • /what-is-interstellarcore/
  • /interstellarcore-current-state/
  • /interstellarcore-faq/

/interstellarcore-definition/

  • /interstellarcore-learning-corridor/
  • /why-repair-matters-more-than-speed/
  • /interstellarcore-p0-to-p3-transfer/
  • /interstellarcore-avoo-learning-architecture/

/interstellarcore-cfcs-audit/

  • /interstellarcore-cfcs-scorecard/
  • /interstellarcore-cfcs-evidence/
  • /interstellarcore-roadmap-to-cfcs-valid/
  • /interstellarcore-release-gate/

/interstellarcore-operator-checklist/

  • /interstellarcore-control-tower-review/
  • /interstellarcore-execution-logic/
  • /interstellarcore-implementation-notes/

/interstellarcore-public-claim-pack/

  • /interstellarcore-wordpress-claim-blocks/
  • /interstellarcore-schema-snippets/
  • /interstellarcore-public-intro/

/interstellarcore-canonical-framing-box/

  • /interstellarcore-canonical-placement-footer/
  • /interstellarcore-page-template/
  • /interstellarcore-page-template-examples/

This is the canonical tree shape.

Primary Reader Paths

The site should support four main reader routes.

Path A — New Public Reader

Goal: understand what it is without being pushed into overclaim

Recommended order:

  1. /interstellarcore/
  2. /what-is-interstellarcore/
  3. /interstellarcore-current-state/
  4. /interstellarcore-faq/
  5. /interstellarcore-public-intro/

This is the safest public entry path.

Path B — Technical Validator

Goal: check whether the framework has earned its claim level

Recommended order:

  1. /interstellarcore/
  2. /interstellarcore-current-state/
  3. /interstellarcore-cfcs-audit/
  4. /interstellarcore-cfcs-scorecard/
  5. /interstellarcore-cfcs-evidence/
  6. /interstellarcore-roadmap-to-cfcs-valid/
  7. /interstellarcore-release-gate/

This is the proof-first path.

Path C — Operator / Tutor / Teacher

Goal: understand how to run it safely in practice

Recommended order:

  1. /interstellarcore/
  2. /interstellarcore-learning-corridor/
  3. /why-repair-matters-more-than-speed/
  4. /interstellarcore-operator-checklist/
  5. /interstellarcore-control-tower-review/

This is the execution path.

Path D — Publisher / Site Builder

Goal: publish new pages without breaking the claim boundary

Recommended order:

  1. /interstellarcore-current-state/
  2. /interstellarcore-public-claim-pack/
  3. /interstellarcore-wordpress-claim-blocks/
  4. /interstellarcore-schema-snippets/
  5. /interstellarcore-canonical-framing-box/
  6. /interstellarcore-canonical-placement-footer/
  7. /interstellarcore-page-template/
  8. /interstellarcore-page-template-examples/

This is the controlled publishing path.

Canonical Internal Link Rules

Use these fixed internal-link rules.

Rule 1 — Every major page links upward

Every page should link back to:

  • the root hub
  • its parent branch page

This preserves structural orientation.

Rule 2 — Every major page links sideways

Every page should link to:

  • previous logical layer
  • next logical layer

This preserves route continuity.

Rule 3 — Every public page links to current-state truth

Public-facing pages should always link to:

  • /interstellarcore-current-state/
  • and/or /interstellarcore-release-gate/

This prevents isolated reading from becoming overclaim.

Rule 4 — Every proof page links to the release boundary

Audit, scorecard, evidence, and roadmap pages should link to:

  • /interstellarcore-release-gate/

This keeps proof and public claim tied together.

Rule 5 — Every publishing page links to the claim pack

Template, snippets, and WordPress block pages should link to:

  • /interstellarcore-public-claim-pack/

This keeps page-building subordinate to release control.

Rule 6 — Every execution page links back to audit pages

Operator and control pages should link to:

  • /interstellarcore-cfcs-audit/
  • /interstellarcore-cfcs-scorecard/

This keeps operations subordinate to truth metrics.

Canonical Hub Link Set

The root hub page should always surface these primary links:

Public

  • What Is InterstellarCore
  • Current State
  • FAQ

Design

  • Definition
  • Learning Corridor
  • P0→P3 Transfer

Proof

  • CFCS Audit
  • Scorecard
  • Evidence Pack
  • Release Gate

Operation

  • Operator Checklist
  • Control Tower Review

Publishing

  • Public Claim Pack
  • WordPress Blocks
  • Schema Snippets

This is the main hub menu logic.

Current Recommended Publish Order

Publish in this order to keep the stack stable.

Phase 1 — Orientation First

  1. /interstellarcore/
  2. /what-is-interstellarcore/
  3. /interstellarcore-current-state/
  4. /interstellarcore-faq/

Phase 2 — Architecture Second

  1. /interstellarcore-definition/
  2. /interstellarcore-learning-corridor/
  3. /why-repair-matters-more-than-speed/
  4. /interstellarcore-p0-to-p3-transfer/

Phase 3 — Audit Before Promotion

  1. /interstellarcore-cfcs-audit/
  2. /interstellarcore-cfcs-scorecard/
  3. /interstellarcore-cfcs-evidence/
  4. /interstellarcore-roadmap-to-cfcs-valid/
  5. /interstellarcore-release-gate/

Phase 4 — Operations

  1. /interstellarcore-operator-checklist/
  2. /interstellarcore-control-tower-review/

Phase 5 — Public Language & Templates

  1. /interstellarcore-public-claim-pack/
  2. /interstellarcore-wordpress-claim-blocks/
  3. /interstellarcore-schema-snippets/
  4. /interstellarcore-canonical-framing-box/
  5. /interstellarcore-canonical-placement-footer/
  6. /interstellarcore-page-template/
  7. /interstellarcore-page-template-examples/

This is the safest release order.

Anti-Drift Navigation Rule

Do not let the site structure imply that:

  • public claim pages are more foundational than audit pages
  • promotional pages outrank current-state pages
  • templates outrank release control
  • articles bypass the current-state truth anchor

If the link tree lets readers hit strong outward language before current-state truth, the site is misordered.

Canonical Page Roles

Use this fixed role labeling.

  • Hub
  • Definition
  • Current State
  • Audit
  • Evidence
  • Roadmap
  • Release Control
  • Operations
  • Public Language
  • Template Infrastructure

Every page should clearly belong to one of these roles.

Suggested Navigation Labels

Use simple human-facing labels:

  • Start Here
  • What It Is
  • Current State
  • How It Is Built
  • How It Is Tested
  • How It Is Run
  • What It Can Claim
  • How Pages Are Published

This keeps the top-level navigation readable.

Current-State Lock for the Whole Site

Every major branch page should visibly retain:

  • CFCS-CONDITIONAL (Design-Intent)
  • PARTIAL
  • DESIGN-INTENT ONLY
  • HOLD

until a formal upgrade changes the central truth state.

This makes the whole site consistent.

Minimal Site Compliance Rule

The InterstellarCore site is minimally compliant only if:

  1. the root hub exists
  2. the current-state page exists
  3. audit pages exist before stronger public language expands
  4. public claim pages link back to the release boundary
  5. all major pages use the framing box + placement footer pattern

Without these, the site can drift into structural overclaim.

Example Root Hub Summary Block

Use this on /interstellarcore/:

InterstellarCore is a civilisation-grade education design framework built toward a safer, repair-dominant learning corridor. Its current public state is design-intent with partial evidence, not yet full validation. Start with the current-state page, then follow the design, audit, execution, and release-control branches in order.

This is the canonical root-hub summary.

Compressed Canonical Sentence

The InterstellarCore Site Map turns the framework into one controlled page route, so readers encounter orientation, design, proof, execution, and public language in the right order without outrunning the current claim boundary.

Integration Lock

This module should sit above and govern:

  • page creation order
  • branch structure
  • internal link logic
  • root hub layout
  • navigation labeling

It is the site-level route map for the whole InterstellarCore stack.

Version Lock

Version: v1.0
Policy: Forward-only refinement

Must remain fixed:

  • same top-level branch logic
  • proof pages precede stronger outward language
  • current-state truth anchor remains central
  • public claim pages remain subordinate to release control
  • root hub and current-state pages are mandatory

One-Line Canonical Lock

The InterstellarCore Site Map organizes the full page stack into one truth-aligned navigation route, so the site itself guides readers in the same order the corridor must actually be built and proven.

Next logical piece:

CivOS.ChronoFlightOverlay.InterstellarCore.InternalLinkBlocks.v1.0
A reusable set of “previous / next / related / current-state boundary” link blocks for inserting into pages so the site map becomes operational in-page.

Recommended Internal Links (Spine)

Start Here For Mathematics OS Articles: 

Start Here for Lattice Infrastructure Connectors

eduKateSG Learning Systems: