Repository

The Atlas explains Zipvilization.

The Repository contains its technical construction.

These are related layers, but they do not have the same publication boundary.

V2 significantly expands the amount and depth of information made public about Zipvilization.

The public documentation now exposes substantially more of the architecture required to understand the project:

  • canonical rules;
  • system relationships;
  • Territory;
  • Zips;
  • Time;
  • History;
  • Civilization;
  • SolumTools;
  • SolumWorld;
  • SolumView;
  • the dApp model;
  • Chapters;
  • the Trinomial;
  • Genesis;
  • Smart Contract behavior;
  • project status;
  • authority boundaries;
  • defined, derived, experimental, representational, and unresolved states.

This expansion is deliberate.

Zipvilization should be understandable without requiring access to its private development environment.

But transparency does not require indiscriminate publication of every internal technical artifact.

The private Repository contains a different layer:

implementation detail

↓

internal architecture

↓

development tooling

↓

operational structures

↓

experimental material

↓

technical know-how

Some of that material is sensitive because it represents accumulated engineering knowledge, internal methods, implementation strategies, tooling, and project-specific know-how.

Publishing it would not necessarily make Zipvilization more understandable or its public claims more verifiable.

V2 makes more of Zipvilization public.

It does not make every internal implementation detail public.

The V2 publication boundary

The V2 publication model is not:

[ Private\ Today \rightarrow Public\ Everything\ Tomorrow ]

Nor is it:

[ Private\ Implementation \rightarrow Trust\ Us ]

The intended boundary is:

[ Public\ Architecture + Public\ Canon + Public\ Relationships + Externally\ Relevant\ Behavior + Verifiable\ Claims ]

while:

[ Internal\ Implementation + Internal\ Tooling + Operational\ Structures + Experimental\ Material + Technical\ Know\text{-}how ]

may remain protected where their disclosure is not required for public verification.

The objective is simple:

Make the system understandable.

Make relevant claims auditable.

Protect internal know-how where publication adds no necessary verification.

More public information in V2

The separation between public documentation and private implementation should not be interpreted as a reduction in transparency.

V2 moves in the opposite direction.

A substantially larger part of Zipvilization’s conceptual and operational architecture is documented publicly.

The public Atlas is designed to explain not only what the project presents to the user, but also how its major systems relate to one another and where their authority comes from.

For example, V2 publicly distinguishes:

[ Blockchain\ Evidence ]

from:

[ Canonical\ Interpretation ]

from:

[ Deterministic\ State ]

from:

[ Representation ]

from:

[ Experience ]

It also documents boundaries such as:

[ Current\ State \neq History ]

[ Representation \neq Truth ]

[ Participation \neq Control ]

[ Implemented \neq Canonical ]

[ Experimental \neq Live ]

[ Possibility \neq Promise ]

These distinctions are part of the public architecture because they are necessary to understand Zipvilization correctly.

The private Repository does not exist to hide those relationships.

It exists to contain the engineering environment used to implement, operate, test, and extend them.

Why some implementation remains private

Zipvilization has evolved through multiple stages of development.

Its technical environment contains more than the current public architecture.

It includes material such as:

  • implementation strategies;
  • internal system architecture;
  • development tooling;
  • indexing methods;
  • operational procedures;
  • internal automation;
  • experimental systems;
  • intermediate models;
  • abandoned approaches;
  • internal AI context;
  • reconstruction methods;
  • data-processing structures;
  • simulation components;
  • development utilities;
  • project-specific technical methods.

Some of this material represents technical know-how developed specifically for Zipvilization.

Its value is not primarily documentary.

Its value lies in how the system is built, reconstructed, operated, tested, or extended.

Making the public architecture auditable does not require publishing every mechanism used internally to achieve those functions.

There is therefore no assumption that all protected Repository material will eventually become public.

Public understanding and private know-how can coexist.

The relevant question is not:

Is every file public?

The relevant questions are:

Can the public system be understood?

Can externally relevant claims be verified?

Are authority boundaries visible?

Can public canonical state be traced to appropriate evidence?

If those conditions require publication of a technical component, that requirement should be considered explicitly.

If they do not, the implementation may remain protected.

Repository architecture

The technical environment is organized around several major areas.

Documentation

Technical and canonical specifications describing the systems behind Zipvilization.

This layer can include documentation for:

  • Project architecture;
  • Solum;
  • SolumTools;
  • SolumWorld;
  • SolumView;
  • Zipvilization;
  • Chapters;
  • Trinomial;
  • technical relationships between systems.

Where documentation is necessary to understand public architecture or canonical behavior, the relevant information belongs in the public documentation layer.

Internal notes do not become authoritative merely because they exist.

Code

The operational layer.

Its purpose is to contain the implementation required for the documented architecture.

Core principle:

If it does not exist operationally in code, documentation alone does not make it implemented.

The Code layer can include areas such as:

  • AI Onboarding;
  • Code Layer;
  • Deployment Notes;
  • Indexer;
  • Shared components;
  • internal services;
  • development tooling.

Some code may require public inspection because it directly establishes public behavior that must be independently verified.

Other code may remain protected because its publication is not necessary to verify the externally relevant behavior of the system.

The boundary is determined by function and auditability.

Not by an assumption that all source code must eventually become public.

AI Onboarding

Machine-oriented context for Artificial Intelligence.

Its purpose is to help AI systems understand:

  • repository structure;
  • authority boundaries;
  • canonical relationships;
  • implementation status;
  • terminology;
  • navigation;
  • source hierarchy.

V2 already exposes substantial machine-oriented structure publicly through the Atlas and AI Canon.

The private technical environment may contain additional AI-oriented context related to implementation, development, tooling, or internal operation.

These are not necessarily the same artifact.

Artificial Intelligence must not treat access to internal material as permission to convert implementation detail into Canon.

Code Layer

Implementation-oriented material.

This is where conceptual architecture approaches executable form.

The distinction remains important:

documented

is not necessarily:

implemented

And:

implemented

is not automatically:

canonical

Public claims about implementation should remain verifiable where verification is relevant.

That does not require exposing unrelated internal mechanisms or project know-how.

Deployment Notes

Technical material related to deployment and operational configuration.

This layer exists to preserve the distinction between:

  • source;
  • configuration;
  • deployment;
  • live state.

A deployment should never be inferred solely from the existence of source code.

Likewise, public deployment facts do not require every internal deployment procedure to be disclosed.

Indexer

Infrastructure for reading and organizing public state.

The Indexer can support systems that need to reconstruct or expose information derived from blockchain activity.

Its role is observational.

Indexing state does not create state.

A private Indexer must not become an unverifiable source of canonical truth.

Where an Indexer exposes derived state:

[ Evidence + Canonical\ Rules \rightarrow Derived\ State ]

should remain the governing relationship.

The implementation used to perform that reconstruction may contain protected technical know-how.

The canonical result must still remain grounded in the appropriate evidence and rules.

Shared

Common structures and components used across technical layers.

Shared infrastructure exists to reduce unnecessary duplication while preserving explicit relationships between systems.

Shared implementation does not acquire canonical authority merely because multiple systems depend on it.

Atlas and Repository

The Atlas and Repository are complementary.

Atlas

Designed primarily for:

  • understanding;
  • navigation;
  • public explanation;
  • canonical relationships;
  • system boundaries;
  • transparency;
  • Human interpretation;
  • machine interpretation.

Repository

Designed primarily for:

  • implementation;
  • engineering;
  • internal technical architecture;
  • deployment;
  • indexing;
  • development tooling;
  • operational infrastructure;
  • experimentation;
  • technical know-how.

The Atlas should make Zipvilization understandable.

The Repository should make Zipvilization buildable and operable.

Where technical verification is necessary, the relevant evidence or implementation should be exposed through the appropriate public layer.

But the Atlas does not need to reproduce the private engineering environment.

And the private Repository does not replace the public Atlas as the explanation of what Zipvilization is.

Authority

The existence of a file inside the technical environment does not automatically make that file canonical.

Repository material must be interpreted according to its role and status.

For example:

CURRENT

IMPLEMENTATION

REFERENCE

HISTORICAL

LEGACY

SUPERSEDED

EXPERIMENTAL

INTERNAL

These classifications describe documentary or implementation status.

They do not independently create canonical authority.

The objective is not to erase the development history of Zipvilization.

The objective is to prevent:

  • development history;
  • experiments;
  • intermediate models;
  • implementation detail;
  • internal tooling;
  • obsolete structures;

from being mistaken for current truth.

Canonical priority

Public documentation, public implementation, and protected implementation may describe different layers of the same system.

Where they conflict, the contradiction must be investigated according to the relevant authority boundary.

An internal artifact must not silently override established Canon.

A public document must not claim implementation that does not exist.

An implementation must not be interpreted beyond the behavior it actually establishes.

And privacy must never be used to conceal a contradiction between what Zipvilization publicly claims and what its public systems actually do.

Contradiction should be exposed.

Not silently resolved.

Auditability

Auditability is not measured by the number of public files.

It depends on whether relevant claims can be traced to appropriate authority and evidence.

For a public claim:

[ Claim \rightarrow Authority \rightarrow Evidence \rightarrow Verification ]

should remain recoverable wherever technically possible.

For blockchain-derived state:

[ Blockchain\ Evidence + Canonical\ Rules \rightarrow Deterministic\ State ]

must not become:

[ Private\ Service \rightarrow Unverifiable\ Truth ]

This boundary is fundamental.

Protected implementation may assist:

  • reconstruction;
  • indexing;
  • caching;
  • simulation;
  • representation;
  • experience;
  • internal automation;
  • development.

It must not silently become the sole authority for a public canonical fact.

Publication model

Repository publication is selective rather than all-or-nothing.

Material should be public when publication is necessary or materially useful for:

  • understanding the architecture;
  • understanding canonical behavior;
  • verifying deployed contract behavior;
  • reproducing deterministic derivations where required;
  • understanding public interfaces;
  • validating externally relevant implementation claims;
  • distinguishing current truth from historical or experimental material.

Material may remain protected when it consists of:

  • internal development tooling;
  • sensitive implementation detail;
  • project-specific technical know-how;
  • experimental implementations;
  • intermediate architecture;
  • internal automation;
  • operational infrastructure;
  • non-authoritative working material;
  • methods whose disclosure is not required for public verification.

The boundary may evolve.

A protected component may later become public when there is a reason to expose it.

A public artifact may become historical or superseded.

A new public claim may require additional evidence to be published.

The publication model therefore follows the architecture rather than a predetermined promise to release everything.

V2 Repository Principle

V2 establishes a clearer separation than previous versions.

More information about Zipvilization belongs in the public layer.

More of the system should be understandable without access to the development environment.

At the same time, the private Repository increasingly contains material whose value lies precisely in its implementation:

  • accumulated technical knowledge;
  • internal methods;
  • engineering decisions;
  • development infrastructure;
  • operational processes;
  • project-specific know-how.

These two developments are compatible.

[ More\ Public\ Knowledge \not\Rightarrow No\ Private\ Know\text{-}how ]

Instead:

[ \boxed{ Public\ Understanding + Public\ Auditability + Protected\ Know\text{-}how } ]

form the V2 Repository boundary.

Current Repository Status

The public documentation architecture has expanded substantially in V2.

The internal technical environment remains protected except where publication is required or deliberately chosen.

Repository material continues to be classified according to:

  • authority;
  • implementation status;
  • historical status;
  • operational role;
  • publication boundary.

The existence of protected implementation does not mean that the architecture is secret.

Likewise, the existence of extensive public documentation does not mean that every described capability has already been implemented.

PUBLIC V2 DOCUMENTATION ... EXPANDED

REPOSITORY ARCHITECTURE .... DEFINED

PUBLIC ARCHITECTURE ........ AVAILABLE

AUDITABLE EVIDENCE ......... EXPOSED WHERE REQUIRED

PROTECTED IMPLEMENTATION ... MAINTAINED

TECHNICAL KNOW-HOW ......... PROTECTED WHERE APPROPRIATE

AUTHORITY BOUNDARIES ....... EXPLICIT

Atlas explains the system.

V2 exposes substantially more of Zipvilization.

The Repository protects the implementation and know-how that do not need to be public for the system to remain understandable and auditable.