Fundatio Trilunae Independent public-interest initiative in formation
Language
Menu
Development status

Development and publication work have resumed. Service APIs remain unavailable unless explicitly documented as live.

Custodia · TDS 1.0

One standard for every document.

The Triluna Document Standard (TDS) is the current Version 1.0 document system used across Triluna, RENKAN, and Gekka Harae. It governs the document itself, not only the format it is delivered in: mainly PDF, and also HTML, Python source, Markdown, and other managed outputs.

Scope

Documents have a type, not just a file extension.

A PDF, an HTML page, and a Python source file may have different delivery rules, but each can be managed as a TDS document. TDS records what the document is for, who is responsible for it, which version is being read, what evidence it contains, and whether it is draft, reviewed, canonical, or superseded.

PDF is the primary official-publication form. HTML can carry the same reading order and metadata on the web. Python and other source files can be managed when they are part of a document, reproducible record, template pack, or release package. The extension does not decide the document’s authority.

Version 1.0 is used across the Triluna family. Shared rules stay shared; a project may add its own content, accent, or release context without creating a separate document standard.

Foundation

A document is composed before it is exported.

Document composition

  • Title and purpose come first, followed by TDS metadata, status, scope, and route.
  • One reading order carries the prose, tables, notes, and evidence markers.
  • Tables hold exact mappings and registers; prose carries reasoning and caveats.
  • Missing evidence remains visible as a finding such as [EVIDENCE REQUIRED].

Shared expression

  • The shared TDS foundation declares Yuji Syuku as the current local typeface for the public Triluna shell.
  • Typography, glyph coverage, geometry, color, spacing, and responsive behavior are recorded as document inputs.
  • Triluna may use its restrained violet expression and double-rule motif without changing the shared contract.
  • Project identity and authorization remain outside the document standard; Renkan ID remains the universal identity boundary.

Document contract

The same questions follow every output.

Geometry
TDS records page geometry and layout constraints for the output being made, including Ronova Legacy page geometries where a reviewed profile exists. RL-144, RL-233, and RL-377 are not claimed as active profiles on this page because no canonical geometry definitions for those identifiers are present in the public Triluna source.
Typeface and glyph coverage
The declared typeface and the characters it must cover are checked together. Missing glyphs, unsupported punctuation, or an unrecorded language range remain preflight findings; a silent fallback font is not a resolution.
Template packs
A reusable pack joins the metadata header, body order, table patterns, notes, naming rules, and output instructions. Templates are working material until their status says otherwise.
Metadata, naming, and versioning
Each document identifies its title, type, version, date, language, responsible project or steward, source, status, visibility, canonical status, related release, and verification state. File names and revisions must agree with those fields.
Preflight and no fallback
Preflight checks the declared geometry, typeface and glyph coverage, metadata, links, assets, privacy boundary, and unresolved evidence. A required failure blocks an official output instead of being hidden by a fallback or placeholder.
Official-release PDF
An official PDF must carry the reviewed version and reading order, pass its geometry and glyph checks, contain the required metadata, clear unresolved release findings, and retain its public provenance. A checksum identifies bytes; it does not by itself make a document approved or cryptographically signed.

Release discipline

Official means a document can be read and traced.

The release path is deliberately short. A document moves from source to reviewed output only when its purpose, status, responsible steward, version, language, geometry, typeface and glyph coverage, evidence, and public route are legible together.

  1. 1Compose
  2. 2Declare metadata and status
  3. 3Run preflight
  4. 4Review the rendered output
  5. 5Publish or retain as working material

Downloads · English source

Start with a document that declares its own state.

These are reusable working materials for TDS 1.0. They are not an official release PDF, do not create a canonical archive record, and do not make Ronova Syuku available.

Component status

Ronova Syuku is not ready for use.

Ronova Syuku is planned as a TDS component for type and glyph work across the Ronova family. It remains under development. No release, font package, download, or production availability is claimed here.

Under development · not ready