01
Available
Renkan ID
Universal identity boundary for Renkan services.
Open surface ↗Renkan / coordination layer
One current.
Many surfaces.
Renkan keeps connected projects moving together without turning them into one application, product or brand.
Renkan ID remains the sole persistent identity authority.
R
shared
relay
ritual
base
01 / 04 One system, distinct expressions.
System / live public register
A shared current, kept deliberate.
The public manifest makes the available surfaces, future work and identity boundary legible without exposing private account data.
02
Planned
Renkan Registry
Public catalogue of systems and members; private grants remain in Renkan ID.
Read boundary ↘
03
Planned
Renkan Council
Future governance surface with explicit roles and audit boundaries.
Read boundary ↘
04
Reference
Renkan Rewards
Canonical programme name; status and balances remain subject-scoped.
Open surface ↗Surfaces / current members
Distinct work, one readable path.
Each project keeps its own domain, identity and purpose. Renkan coordinates the seams and records the decisions that cross them.
01 / member
Ronova
base / silver
Personal work, practice and the public point of departure.
02 / member
Triluna
order / precise
Institutional identity, privacy services and durable records.
03 / member
Relay
movement / directional
Private transfers with a clear path through the Triluna-owned boundary.
04 / member
Gekka Harae
ritual / distinct
A creative world that stays its own while the shared shell connects.
Identity / boundary
One identity. Clear ownership.
Renkan is an orchestration layer, not a replacement for the projects it coordinates. The boundary is part of the product.
Renkan ID
The universal identity subject continues across account and Rewards without a second account system.
Project ownership
Domains, services, player data and institutional records remain owned by their respective projects.
Explicit coordination
Cross-project work is routed, recorded and checked at the integration boundary instead of being silently merged.
Public by default, private by design
The manifest is public. Account profile, membership grants, balances and authorisation remain behind their owning surfaces.
Developer API / qualification path
Bring another project to Renkan ID.
Qualified developers may offer Renkan ID as a login option through either a submitted declaration or an owner-gifted invite for an exact registered client.
Rewards / reference model
Recognition without authority.
Renkan Rewards can describe participation and recognition, but it never grants access to another project's private systems. Personal status is resolved by the existing Rewards adapter.
01
Subject-scoped
Status follows the universal Renkan ID subject.
02
Adapter-owned
Balances and tier detail stay on the Rewards surface.
03
Non-authoritative
Recognition does not change project permissions or ownership.
Path / current state
The work stays traceable.
A small register for decisions that should remain visible as the network grows.
Identity authority
Renkan ID
single persistent boundary
Visual contract
TDS / Option 1
shared public shell
Current phase
Mainpage groundwork
root surface separated from dossier
Devlog
30 August 2026
developer API intake prepared
Devlog / 30 August 2026
The identity boundary opens by review.
A declaration form or an owner-gifted invite now opens the path for a qualified developer to offer Renkan ID as a login option. Declarations are browser-encrypted for Triluna review; gifted invites qualify one exact registered client and are consumed once rather than becoming another account credential.
Return to the top ↑