APTlantis is a personal software ecosystem built around practical, operator-centered computing.

It includes Windows desktop applications, native and cross-platform command tools, archival and integrity systems, structured-data pipelines, dataset and mirror tooling, workspace governance, release standards, IDE and knowledge-work integrations, local infrastructure utilities, and public documentation surfaces.

The projects are not treated as isolated experiments. They increasingly share manifests, schemas, lifecycle records, release evidence, command contracts, integrity practices, visual conventions, and a common governance layer in City Hall.

APTlantis builds tools for doing the work and systems for understanding, governing, verifying, and preserving the work.

The October 2, 2026 evaluation covers 45 projects with an average assessed completion of 81.8%.

The raw complexity totals count every evaluated project independently, which is useful for project-level planning but can overstate how much of the portfolio is made up of unrelated small systems.

In this evaluation, 7 of the 8 Low-complexity projects are members of the SiYuan theme family: Assembly, HolyC, Julia, QBasic, Scratch, TOML, and Zig. BlueSlate, another theme-family member, is assessed as Medium because it also functions as a broader design-system implementation.

These remain separate projects because they are independently packaged, versioned, maintained, and verified. At the portfolio level, however, they are better understood as repeated implementations of a shared theme-production pattern rather than seven unrelated simple projects. The low-complexity count therefore reflects both genuinely bounded work and the payoff from reusable architecture, palettes, generation tooling, and packaging conventions.

A completion percentage is an assessment of how much of the intended project exists. It is not a substitute for lifecycle state, release verification, or governance conformance.

APTlantis therefore keeps four questions separate:

• Completion: How much of the intended system exists?
• Lifecycle: Is the project in progress, paused, maintained, prototyped, planned, or production?
• Verification: Have build, tests, artifacts, installation behavior, hashes, and release evidence been recorded?
• Governance: Does the project satisfy the standards appropriate to what it produces?

City Hall is the workspace-governance system behind the portfolio. Standards are designed as bounded, usable suites rather than generic policy documents.

The practical chain is simple: PPS defines the project → WGS places and governs it → the appropriate delivery standard governs what it produces → integrity and evidence standards preserve what happened.

The GitHub organization is a public projection of a larger local-first workspace. Not every active local project is published here, and repository state should not be treated as a replacement for the evaluated project records.

The current evaluation includes a substantial SiYuan theme family alongside plugins, knowledge-work utilities, the public City Hall website, and supporting design standards.

The theme repositories are intentionally evaluated separately because each is a real maintained artifact with its own package, compatibility surface, palette, generated assets, and runtime-verification needs. They also share enough architecture that they should be read as a project family rather than as eight unrelated applications.

That distinction matters: repeated low-complexity descendants are partly evidence that the harder architectural work has already been captured upstream. Shared palette generation, semantic-role mapping, packaging conventions, and SiYuan integration make additional themes smaller without making them trivial or disposable.

Other evaluated work in this layer includes:

• Code Artifact Intake — In Progress · 90%
• Windows Terminal for SiYuan — In Progress · 85%
• APTlantis City Hall website — In Progress · 85%
• Aptlantis Logos — Paused · 90%

Repositories that are public but absent from the current evaluation are intentionally left without inherited completion scores.

APTlantis currently spans six connected layers:

1. Governance and standards — project proposals, workspace governance, delivery standards, evidence standards, integrity standards, and visual-system governance.
2. Operator applications — interfaces for artifact retention, structured data, commands, archives, operations, technical editing, and system workflows.
3. Command tools and pipelines — bounded utilities that transform source material into reproducible outputs and evidence.
4. Preservation and integrity — hashes, manifests, detached signatures, provenance, release records, and archive verification.
5. Data, research, mirrors, and knowledge systems — reproducible captures, software mirrors, datasets, local analysis, and SiYuan-based exploration.
6. Public explanation — repositories, documentation, websites, schemas, examples, visual systems, and reviewed snapshots that make the work inspectable.

• Local first. Useful capability should not require a hosted service unless the project explicitly calls for one.
• Operator visible. Important actions, state, provenance, and failure conditions should be inspectable.
• Evidence before claims. Build, test, package, install, hash, and release claims should follow recorded verification.
• Structured where it matters. TOML, JSON, JSONL, schemas, manifests, and explicit records are preferred over hidden state.
• Plan first, execute second. Risky or destructive operations should expose intent and boundaries before mutation.
• Preserve the artifact and the context. A file without provenance, integrity evidence, or lifecycle context is less useful over time.
• Standards serve the work. Governance exists to make projects easier to understand, recover, hand off, and verify — not to maximize paperwork.