City Hall is the standards and governance center for the Aptlantis workspace. It explains how the drive is organized, how projects begin, how standards mature, how releases are evidenced, and how future humans or agents recover context.
The point is not paperwork. The point is fewer mysteries.
For a first pass through the Aptlantis workshop:
- City Hall: governance and standards. Start with this README, then
WGS/README.mdandSFDS/README.md. - FileCabinet: local artifact vault and preservation workflow.
- AegisDesktop: cryptographic keyring manager.
- SESM: SVG embedded semantic metadata standard. Start with
SESM/README.md. - Clone-Cratesio: high-performance crates.io mirror tooling.
For the guided project tour, read WORKSHOP-MAP.md.
D:\010-CITY-HALL is the canonical home for:
- Workspace governance.
- Standards and frameworks.
- Project proposal rules.
- Release and delivery standards.
- Integrity and preservation standards.
- Agent and evaluation standards.
- Design language and semantic metadata standards.
- Preserved planning references.
The drive-level workspace manifest lives at D:\WORKSPACE.manifest.toml.
City Hall's root manifest lives at 010-CITY-HALL.manifest.toml.
flowchart TB
CityHall["Aptlantis City Hall"]
Governance["Governance and orientation"]
Creation["Project creation"]
Delivery["Delivery standards"]
Integrity["Integrity and preservation"]
Agents["Agent and analysis records"]
Visuals["Visual semantics"]
CityHall --> Governance
CityHall --> Creation
CityHall --> Delivery
CityHall --> Integrity
CityHall --> Agents
CityHall --> Visuals
Governance --> WGS["WGS"]
Governance --> SFDS["SFDS"]
Creation --> PPS["PPS"]
Delivery --> DRS["DRS"]
Delivery --> CTS["CTS"]
Delivery --> SIS["SIS"]
Delivery --> WDS["WDS"]
Delivery --> DDS["DDS"]
Integrity --> ARHS["ARHS"]
Integrity --> AAMHS["AAMHS"]
Agents --> ATS["ATS"]
Agents --> AAS["AAS"]
Visuals --> SESM["SESM"]
Visuals --> NeonInk["NeonInk"]
Visuals --> AADR["AADR"]
| Folder | Standard | Version | Maturity | Role |
|---|---|---|---|---|
WGS |
Workspace Governance Standard | 0.2.7 | Candidate | Workspace constitution: roots, manifests, lifecycle visibility, services, agent orientation, responsibility boundaries, and suite audits. |
SFDS |
Standards Framework Development Standard | 1.0.0 | Stable | Governs how City Hall standards are written, structured, validated, versioned, adopted, and preserved. |
PPS |
Project Proposal Standard | 0.2.2 | Candidate | Governs project intent before broad implementation: mission, boundaries, success, failure, constraints, risks, roadmap, and proposal examples. |
DRS |
Desktop Application Release Standard | 1.0.2 | Reference | Reference suite for desktop release notes, manifests, artifacts, hashes, verification, and release evidence. |
CTS |
Command Tool Standard | 0.2.1 | Candidate | Governs CLI contracts, output streams, JSON output envelopes, exit codes, automation compatibility, and destructive command safety. |
SIS |
Service and Infrastructure Standard | 0.1.0 | Candidate | Governs local-first services, daemons, local APIs, shared infrastructure, health checks, ports, logs, resource bounds, and recovery procedures. |
WDS |
Website Development Standard | 0.2.1 | Candidate | Governs website manifests, deployment records, accessibility, metadata, route checks, rollback, monitoring, and site schemas. |
DDS |
Dataset Development Standard | 0.2.1 | Candidate | Governs datasets, provenance, licensing, validation, splits, integrity, usage constraints, schemas, and release readiness. |
ATS |
Agent Task Standard | 0.2.1 | Candidate | Governs agent task records, handoffs, validation summaries, blockers, replayable context, and task-record schemas. |
AAS |
Aptlantis Analysis Standard | 0.2.1 | Candidate | Governs analysis manifests, evaluation run records, metrics, comparisons, interpretation boundaries, schemas, and credibility evidence. |
ARHS |
APTlantis Release Hashing Standard | 0.2.1 | Candidate | Governs minimum release-artifact hashes, release hash records, and SHA256, BLAKE3, and KangarooTwelve evidence. |
AAMHS |
Aptlantis Archive Multi-Hash Standard | 1.0.3 | Candidate | Governs archive preservation integrity records, hash manifests, validation procedures, schemas, and detached signature policy. |
AADR |
Application as Data Representation Standard | 1.0.3 | Candidate | Governs application-as-data representation records, component maps, relationships, schemas, compatibility, and validation limits. |
SESM |
SVG Embedded Semantic Metadata | 0.3.0 | Candidate | Governs semantic metadata embedded in SVG assets, safe-profile review, privacy/conformance framing, schema validation, tooling, fixtures, and non-authoritative agent-readable visual context. |
NeonInk |
NeonInk | 0.1.6 | Candidate | Governs semantic color, visual intent, theme behavior, app surfaces, web surfaces, UI language, and SESM-aligned visual metadata examples. |
For workspace-level work:
010-CITY-HALL.manifest.tomlWGS/README.mdWGS/Workspace Governance Standard.mdWGS/Agent-Startup-Procedure.mdWGS/Governance-Responsibility-Matrix.mdWGS/Documentation-Suite-Roadmap.md
For creating or reviving a project:
PPS/README.mdPPS/Project Proposal Standard.md- The delivery standard for the project class: DRS, CTS, SIS, WDS, or DDS.
- Any supporting standard named by the project: ARHS, AAMHS, AAS, ATS, SESM, NeonInk, or AADR.
flowchart LR
Idea["Project idea or revival"]
PPS["PPS: intent, boundaries, success"]
WGS["WGS: location, manifest, registration"]
Delivery{"Delivery class"}
Desktop["DRS: desktop app"]
CLI["CTS: command tool"]
Service["SIS: service or infrastructure"]
Website["WDS: website or web app"]
Dataset["DDS: dataset"]
Evidence["Release, validation, and preservation evidence"]
Idea --> PPS --> WGS --> Delivery
Delivery --> Desktop --> Evidence
Delivery --> CLI --> Evidence
Delivery --> Service --> Evidence
Delivery --> Website --> Evidence
Delivery --> Dataset --> Evidence
For writing or revising a standard:
SFDS/README.mdSFDS/Standards Framework Development Standard.mdSFDS/examples/DRS-Reference-Suite.mdSFDS/templates/DRS/README.mdas the mature reference suite pattern.
City Hall uses entity-named TOML manifests.
- Workspace root:
D:\WORKSPACE.manifest.toml. - City Hall root:
010-CITY-HALL.manifest.toml. - Standard directories:
{FolderName}.manifest.toml, such asWGS/WGS.manifest.toml. - Projects:
{ProjectName}.manifest.toml, such asFileCabinet.manifest.toml. - Templates use placeholder names such as
StandardName.manifest.tomlandDirectoryName.manifest.toml.
Generic STANDARD.manifest.toml and DIRECTORY.manifest.toml are not the active naming convention.
As of 2026-06-11:
- SFDS is stable at
v1.0.0. - DRS is the reference implementation for a mature practical standard suite.
- Every standard directory has a README, primary specification, changelog, validation checklist, adoption guide, examples or reference material, and an entity-named manifest.
- README, adoption, and validation docs distinguish standard-suite conformance from adopter/domain readiness.
- WGS coordination docs track current maturity, responsibility boundaries, and next standard-suite work.
pie title Standards by maturity
"Candidate" : 13
"Stable" : 1
"Reference" : 1
Each standard owns a different kind of decision.
When responsibilities overlap, use WGS/Governance-Responsibility-Matrix.md.
Short version:
- WGS decides where things live and how the workspace describes itself.
- PPS decides why a project exists and what success or failure means.
- SFDS decides what makes a standard adoptable.
- DRS, CTS, SIS, WDS, and DDS decide delivery rules for project classes.
- ARHS decides minimum release-artifact hashes.
- AAMHS decides archive preservation integrity records.
- ATS records agent work and handoff context.
- AAS records analysis credibility and interpretation boundaries.
- NeonInk and SESM govern visual semantics and embedded asset metadata.
- AADR governs application-as-data representation records.
flowchart TD
Question["Decision or ambiguity"]
Location{"Where does it live?"}
Intent{"Why does it exist?"}
StandardShape{"Is it a standard suite?"}
DeliveryKind{"What kind of artifact ships?"}
EvidenceKind{"What evidence is needed?"}
VisualKind{"Is visual metadata involved?"}
Question --> Location --> WGS["WGS"]
Question --> Intent --> PPS["PPS"]
Question --> StandardShape --> SFDS["SFDS"]
Question --> DeliveryKind
DeliveryKind --> DRS["DRS"]
DeliveryKind --> CTS["CTS"]
DeliveryKind --> SIS["SIS"]
DeliveryKind --> WDS["WDS"]
DeliveryKind --> DDS["DDS"]
Question --> EvidenceKind
EvidenceKind --> ARHS["ARHS"]
EvidenceKind --> AAMHS["AAMHS"]
EvidenceKind --> ATS["ATS"]
EvidenceKind --> AAS["AAS"]
Question --> VisualKind
VisualKind --> SESM["SESM"]
VisualKind --> NeonInk["NeonInk"]
VisualKind --> AADR["AADR"]
Planning history and older drafts are preserved under standard-specific references/ folders.
The long planning conversations that shaped this system are preserved under:
WGS/references/conversations/
Those files are context and lineage, not active standards unless a suite explicitly cites them.
Canonical repository:
git@github.com:APTlantis/CityHall.git