# Workspace Governance Standard

Keeps workspace placement, manifests, lifecycle state, and authority legible.

Catalog: active · v0.2.7 · reviewed 2026-09-23

Source maturity: candidate · Explanation reviewed 2026-10-01

Applies to: Workspace roots, containers, projects, services and standards that need recoverable human and agent navigation.

[Public page](https://aptlantis.net/city-hall/wgs)

<a id="purpose-and-applicability"></a>

## Purpose and applicability

A folder name does not tell a future maintainer which records own a project or how to resume it. WGS connects physical placement, identity, authority and lifecycle.

Workspace roots, containers, projects, services and standards that need recoverable human and agent navigation.

<a id="how-it-works"></a>

## How it works

Use an entity-named manifest with manifest, entity and domain tables. Preserve the exact containing directory name. Traverse parent records and instructions toward the project, then follow its read map and authoritative documents.

Outputs include one canonical entity manifest per governed directory, parent/child relationships, lifecycle and known gaps, plus Project-README.md and PROJECT-READMAP.toml for project roots.

<a id="in-practice"></a>

## In practice

This relative tree is a synthetic workspace. The record names match their containers; the project read map points a reader toward intent before command behavior.

### Workspace and entity records

illustrative · teaching example, not a verification result

Sanitized synthetic tree with record relationships; not a copy of the live workspace.

Source: `WGS/Manifest-Conventions.md`

```text
workspace/
├─ Development.manifest.toml      # root identity
└─ tools/
   ├─ tools.manifest.toml         # container authority
   └─ ManifestAudit/
      ├─ ManifestAudit.manifest.toml
      ├─ AGENTS.md
      ├─ Project-README.md
      └─ PROJECT-READMAP.toml     # proposal → command contract

Project entity: ManifestAudit
Parent: tools
Lifecycle: concept
Known gap: command contract not yet validated
```

[Inspect Workspace and entity records](/city-hall/standards/wgs/example-1.txt)

<a id="adopt-one-part"></a>

## Adopt one part

Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.

1. Inventory one project’s exact name and current records without renaming it.

2. Reconcile its entity manifest, parent link and read map; preserve superseded records with recovery references.

3. Check schema and link resolution, and record missing authority or lifecycle evidence before broad work.

<a id="sources-and-limits"></a>

## Sources and limits

The relative tree is for public teaching. Canonical WGS records may require absolute paths in an actual private workspace; this excerpt does not replace that requirement. The v2.4 schema and template need full validation after filling. No inventory of the visitor’s machine is performed.

These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.

- `WGS/WGS.manifest.toml`
- `WGS/Adoption-Guide.md`
- `WGS/Validation-Checklist.md`
- `WGS/Manifest-Conventions.md`
- `WGS/EntityManifest-v2.4.schema.json`
- `WGS/templates/ProjectName.manifest.toml`

[Reviewed manifest facts](/city-hall/components/wgs.md)

## Related responsibilities

- [Project Proposal Standard](/city-hall/pps): Records project intent and readiness before implementation.
- [Standards Framework Development Standard](/city-hall/sfds): Maintains standard suites; WGS governs their placement and identity.