diff --git a/CHANGELOG.md b/CHANGELOG.md
index fe1136b..746685e 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,8 @@
# Changelog
+> Windows delivery: this package is included in [MSI 1.7.0.1](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1); [installed acceptance](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) applies only to the identified artifact. Earlier entries retain their original release context.
+
+
## [0.2.3] - Unreleased naming candidate
- Rename the principal distribution/import to the Townlight Zoning identities and pair with Townlight Core 1.3.0.dev2.
diff --git a/README.md b/README.md
index 0f94176..413876d 100644
--- a/README.md
+++ b/README.md
@@ -1,57 +1,204 @@
-> **Prepared naming, Access and Notice candidate — 2 November 2026.** Build, signing, installed acceptance and publication remain pending. Earlier signed releases and receipts apply only to their identified artifacts.
+Windows x64 Beta 1 · MSI 1.7.0.1
+
+The signed [Windows x64 beta 1.7.0.1](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1) passed the documented fresh Windows Sandbox checks with synthetic data.
+
+- Townlight Zoning Manual
+ - Contents
+ - Using this manual
+ - Beta identity
+ - First run
+ - Daily workflow
+ - Connected workflows
+ - Architecture
+ - Discretionary processes and staff review
+ - Technical specifications
+ - Configuration and administration
+ - API and integration examples
+ - MCP and automation boundary
+ - Security and permissions
+ - Backup recovery and maintenance
+ - Troubleshooting
+ - Verified workflows and limits
+ - Terms of service and license
+ - Glossary
+ - Alphabetical subject index
+ - Source and document control
+
+# Townlight Zoning Manual
+
+**Townlight Beta 1** · Naming candidate documentation edition 2 November 2026
+
+## Contents
+
+- [Using this manual](https://townlight.github.io/manuals/zoning.html#using-this-manual)
+- [Beta identity](https://townlight.github.io/manuals/zoning.html#beta-identity)
+- [First run](https://townlight.github.io/manuals/zoning.html#first-run)
+- [Daily workflow](https://townlight.github.io/manuals/zoning.html#daily-workflow)
+- [Connected workflows](https://townlight.github.io/manuals/zoning.html#connected-workflows)
+- [Architecture](https://townlight.github.io/manuals/zoning.html#architecture)
+- [Discretionary processes and staff review](https://townlight.github.io/manuals/zoning.html#discretionary-processes-and-staff-review)
+- [Technical specifications](https://townlight.github.io/manuals/zoning.html#technical-specifications)
+- [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration)
+- [API and integration examples](https://townlight.github.io/manuals/zoning.html#api-and-integration-examples)
+- [MCP and automation boundary](https://townlight.github.io/manuals/zoning.html#mcp-and-automation-boundary)
+- [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions)
+- [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance)
+- [Troubleshooting](https://townlight.github.io/manuals/zoning.html#troubleshooting)
+- [Verified workflows and limits](https://townlight.github.io/manuals/zoning.html#verified-workflows-and-limits)
+- [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license)
+- [Glossary](https://townlight.github.io/manuals/zoning.html#glossary)
+- [Alphabetical subject index](https://townlight.github.io/manuals/zoning.html#alphabetical-subject-index)
+- [Source and document control](https://townlight.github.io/manuals/zoning.html#source-and-document-control)
+
+## Using this manual
+
+Townlight Zoning helps planners, land-use staff and authorized reviewers. Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.
+
+Staff should begin with First run and Daily workflow. Administrators should also read Architecture, Technical specifications, Configuration, Security and Recovery. Developers should use the exact API/data dictionary and examples. The table of contents and alphabetical subject index link to the relevant sections in the HTML edition; the PDF preserves headings and searchable text. An editable Word edition is included with the same documentation companion.
+
+## Beta identity
-# Townlight Zoning
+| Identity | Value |
+|----|----|
+| Documentation | Townlight Beta 1 naming, Access and Notice candidate |
+| Intended installer version | 1.7.0.1 |
+| Product component | townlight-zoning 0.2.3 |
+| Principal import package | townlight_zoning |
+| Native desktop source version | 1.7.0-1 |
+| Candidate hashes | [SHA-256 checksums](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/SHA256SUMS-Windows-1.7.0.1.txt) and [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) |
+| Current owned software license | AGPL-3.0-only |
+| Acceptance composition | Fresh Windows x64 profile; inspections-preview; Station configured separately |
-**Townlight Beta 1** · Naming candidate; component versions advanced · AGPL-3.0-only
+Use an empty database and fresh Windows profile. The installer refuses legacy profile initialization. The approved profile path is `%LOCALAPPDATA%\CivicSuite`. Keep existing profiles and backups.
-Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.
+## First run
-## Start here
+1. Download the signed MSI, matching source companion and checksums from the [public Windows release](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1).
+2. Verify the MSI hash and Authenticode publisher before installing on a fresh Windows profile. See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) for the tested setup.
+3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
+4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. **Continue without local AI** is valid for the deterministic workflows.
+5. Run Health Check and wait for readiness. Open Townlight. In System Health select **Finish Records Migration** to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
+6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
+7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
-Staff should use the operating manual. Administrators should read first-run, configuration and recovery before changing a deployment. Developers should read the exact API/schema reference and matching source companion. This edition describes the prepared source candidate; obtain its installer only after signing and installed acceptance identify the exact artifact.
+## Daily workflow
-- [Operating manual](docs/beta-1/manuals/zoning.html) · [Printable PDF](docs/beta-1/pdf/Townlight-Zoning-Manual-Beta-1.pdf) · [Editable Word manual](docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx)
-- [API and data dictionary](docs/beta-1/api/zoning.html) · [OpenAPI JSON](docs/beta-1/api/zoning-openapi.json)
-- [Product and suite directory](docs/beta-1/index.html) · [Terms and full license](docs/beta-1/terms.html)
+
-## Exact version and candidate
+### 1. Prepare parcel data
-| Identity | Value |
-| --- | --- |
-| Documentation | Townlight Beta 1 naming, Access and Notice candidate |
-| Intended installer version | 1.7.0.1; build and acceptance pending |
-| Native desktop source version | 1.7.0-1 |
-| Product component | townlight-zoning 0.2.3 |
-| Principal import package | townlight_zoning |
-| Candidate hashes | Pending build, signing and installed acceptance |
-| License | AGPL-3.0-only |
+Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
+
+
+
+### 2. Import and inspect
+
+Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
+
+
+
+### 3. Register cited rules
+
+Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
-Use a fresh profile and empty database. Existing unmarked city data is refused before initialization; no in-place upgrade is supported. Preserve the existing `%LOCALAPPDATA%\CivicSuite` profile, data and recovery material. Historical releases retain their original identities.
+
-## What staff can do
+### 4. Ask a parcel question
-- **Prepare parcel data:** Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
-- **Import and inspect:** Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
-- **Register cited rules:** Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
-- **Ask a parcel question:** Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.
-- **Record review and context:** Record a correction and its reason when needed. Select permitted Meetings history explicitly. Preserve the question/review history and distinguish staff-only precedent from public material.
-- **Create a snapshot:** Review the audience and exact content before creating the immutable snapshot. A public snapshot must satisfy its permitted-source contract; choosing a public label does not sanitize private notes.
-- **Use it downstream:** Select the exact snapshot for Records or the permitted provider path. The receiving workflow rechecks visibility, source identity and hash before retaining or exporting it.
+Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.
-## Operating procedures and examples
+
-The operating manual now includes these existing procedures, with synthetic inputs, readback and limits. Follow the actual app boundary identified there; a standalone source capability is not automatically a desktop screen.
+### 5. Record review and context
-- [Discretionary processes and staff review](docs/beta-1/manuals/zoning.html#discretionary-processes-and-staff-review).
-- [Explain the cited process](docs/beta-1/manuals/zoning.html#explain-the-cited-process).
-- [Keep parcel import and inspection in the right order](docs/beta-1/manuals/zoning.html#keep-parcel-import-and-inspection-in-the-right-order).
-- [Use the existing specialist review contracts](docs/beta-1/manuals/zoning.html#use-the-existing-specialist-review-contracts).
+Record a correction and its reason when needed. Select permitted Meetings history explicitly. Preserve the question/review history and distinguish staff-only precedent from public material.
-## Architecture and data
+
+
+### 6. Create a snapshot
+
+Review the audience and exact content before creating the immutable snapshot. A public snapshot must satisfy its permitted-source contract; choosing a public label does not sanitize private notes.
+
+
+
+### 7. Use it downstream
+
+Select the exact snapshot for Records or the permitted provider path. The receiving workflow rechecks visibility, source identity and hash before retaining or exporting it.
+
+### Working safely
+
+Use your own named account and save before leaving a screen. A saved draft is durable; unsaved form text may not be. If a write has an unknown result, reopen its record before repeating it.
+
+Read source jurisdiction, dates, citation, version and visibility. A copied source hash identifies exact bytes, not their legal applicability. If a source changes or permission is removed, resolve the source problem rather than substituting stale cached content.
+
+Keep originals and derivatives separate. Review the intended audience before export. A public summary excludes private fields only through the applicable copy contract and your review. A renamed private packet is still private content.
+
+Drafting, review, approval, attachment, export, fulfillment and publication are separate operations. A Townlight workpaper does not itself adopt law, issue a permit, impose a fine or release a records response. The responsible staff member records the applicable decision.
+
+## Connected workflows
+
+Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.
+
+| Direction | Material |
+|----|----|
+| Input | A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence. |
+| Output | Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes. |
+
+### Product boundary
+
+The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.
+
+## Architecture
+
+
+
+Townlight Zoning architecture and evidence flow
+
+
+The drawing shows the principal staff/evidence path. Native commands carry trusted identity to Python business services; PostgreSQL and retained original files hold durable state. A downstream copy does not silently transfer decision authority. Station has its own configured authority/media boundary, database and mutable files. The connected-workflow text supplies the drawing’s reading order and accessibility alternative.
+
+## Discretionary processes and staff review
+
+### Explain the cited process
+
+In the existing Zoning workspace, complete **Variance, conditional use or nonconformity question**. Supply the applicable process **Code section**, **zone code**, optional comma-separated **standard to cite**, and optional **observed condition**, for example `front_setback=8 feet`. Select **Explain the cited process**. Choose actual imported public authority; the synthetic values below require matching synthetic sources to return supported guidance.
+
+The mounted API is `POST /desktop/v1/zoning/standards/process-explanation` under the normal authenticated staff session. Its equivalent request body is:
+
+``` json
+{"question":"Explain the synthetic variance process","process_section":"18.20.050","zone_code":"SYN-R","rule_types":["front_setback"],"observed":{"front_setback":"8 feet"}}
+```
+
+Read process citations and each cited standard independently. The output can explain a verified process while reporting unavailable standards or review flags. A difference between an observation and a cited standard is an informational flag; it is not a variance finding, approval, nonconformity determination or substitute for planner review. If no relevant authority is available, obtain the source or leave the item unavailable. Do not attach an unrelated citation to a proposed requirement.
+
+### Keep parcel import and inspection in the right order
+
+Check the complete JSON envelope, original hashes and EPSG:4326 geometry before submitting **Import parcel dataset**. That control sends the import directly; it does not open a separate preview/commit screen. Inspect the returned validation/provenance and saved dataset. The browser refuses bundle files larger than 20 MiB; valid geometry and metadata remain subject to server validation. Correct the source bundle after a refusal and retain earlier evidence rather than forcing SQL changes.
+
+### Use the existing specialist review contracts
+
+The standalone Zoning application’s review/analytics/report routes are documented source capabilities, not extra native desktop screens. In a deployment where its actual staff authentication is already configured:
+
+- Create an ambiguity review with `zone_code`, `question` and `reason` at `/api/v1/townlight_zoning/staff/ambiguity-reviews`. Read its returned ID and list state. Update that ID with `status`, optional `assigned_to` and `resolution`; use `open`, `in_review`, `resolved` or `closed`. Resolving or closing requires a nonempty `resolution`.
+- Retain a flagged answer at `/api/v1/townlight_zoning/staff/flagged-answers` with the original question/answer, zone, flag reason and source citations. Use `/{review_id}/improve` with `improved_answer` and `improvement_notes`. Preserve the original and improvement attribution; a correction does not rewrite the imported Code source.
+- Read `/api/v1/townlight_zoning/staff/questions/analytics` with the desired `high_volume_threshold` to identify repeated questions and uncertain answers. Analytics counts are review aids, not jurisdictional conclusions.
+- Create `/api/v1/townlight_zoning/staff/reports/outline` with a title and actual selected `question_ids`/`queue_item_ids`. Review the resulting outline and citations before incorporating it in a staff report. It is not a filed report or a meeting decision.
+
+A synthetic ambiguity request is:
+
+``` json
+{"zone_code":"SYN-R","question":"Which retained setback rule applies?","reason":"Synthetic overlay ambiguity requires planner review"}
+```
+
+Do not send invented staff-role headers or assume these standalone paths exist at the installed desktop origin. The native workspace’s supported review/history/snapshot controls continue to use its fixed authenticated bridge. Use the technical supplement to distinguish the two surfaces.
+
+Source contracts: `townlight_runtime/zoning_bridge.py`, `townlight_zoning/main.py`, the imported rule/source models and desktop Zoning view.
+
+## Technical specifications
### Runtime and storage
-This prepared source candidate targets **Windows x64 fresh installation**. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The prior accepted runtime contained FastAPI 0.162.0; this changed candidate requires its own installed dependency verification. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label.
+The accepted package targets **Windows x64 fresh installation**. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label.
The native transport is fixed to loopback `127.0.0.1:15480`; PostgreSQL uses the configured local runtime port (default `15432`). Optional local model service defaults to `127.0.0.1:15434`. Those are deployment defaults, not internet endpoints. The runtime has health, module and readiness endpoints; readiness is stronger than process existence. The task queue is the existing local Core task infrastructure, not an assertion that a separate Redis service is required for this desktop composition.
@@ -65,30 +212,12 @@ Versioned saves use expected prior revision identifiers where defined. Reopen an
### Capacity and platform statements
-This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The new installer size remains pending its build; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
-
-The exact [runtime payload lock](docs/beta-1/reference/runtime-payload-lock.json) records pinned files, sizes and hashes. The [component metadata](docs/beta-1/reference/component-metadata.json) records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
-
-
-| Data contract | Description |
-| --- | --- |
-| Input | A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence. |
-| Retained records | GeoJSON import datasets; parcels and zone/overlay context; cited rules; questions and answers; review events; selected Meetings history; immutable snapshots. |
-| Output | Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes. |
-| Connections | Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting. |
-
+This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The signed MSI is 2,082,697,216 bytes; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
-## Setup and operation
+The exact [runtime payload lock](https://townlight.github.io/reference/runtime-payload-lock.json) records pinned files, sizes and hashes. The [component metadata](https://townlight.github.io/reference/component-metadata.json) records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
-1. Obtain the identified signed private candidate and its corresponding-source companion from the beta coordinator. The landing pages in this documentation are not an installer download service.
-2. On the intended fresh Windows test installation, verify the MSI hash and publisher signature before installing. Preserve unrelated profiles and recovery material. Installed acceptance for this source candidate remains pending; no in-place legacy upgrade is supported.
-3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
-4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. **Continue without local AI** is valid for the deterministic workflows.
-5. Run Health Check and wait for readiness. Open Townlight. In System Health select **Finish Records Migration** to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
-6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
-7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
+## Configuration and administration
-## Configuration
### Native deployment configuration
Use Setup, Settings and System Health for supported staff operation. Administrators provision folders, backup storage, named accounts and the city profile. Select `inspections-preview` for the bounded desktop composition, including Access and Notice. Station remains a separate service boundary. Do not use a standalone product’s demo server as a substitute for the installed workspace.
@@ -97,12 +226,13 @@ Technical deployments use `TOWNLIGHT_PRODUCT_PROFILE`, `TOWNLIGHT_PROFILE_ROOT`,
The isolated documentation exporter sets a fictional profile and unusable synthetic database origin only to read schemas; those values are not deployment configuration. Keep deployment values in the intended process/account scope. An already-running process does not automatically inherit later environment edits.
-## API usage
+## API and integration examples
+
### Native command example
The following JavaScript belongs in the existing trusted Townlight frontend/development environment with `invoke` imported from `@tauri-apps/api/core`. It is not a command for an arbitrary web page or an instruction for nontechnical staff. IDs must come from records created in an isolated synthetic exercise.
-```javascript
+``` javascript
import { invoke } from '@tauri-apps/api/core';
const result = await invoke('zoning_domain_request', {request: {operation: 'history', id: questionId}});
console.log(result);
@@ -112,7 +242,7 @@ console.log(result);
An administrator/developer can inspect an already-configured isolated runtime from a trusted local process. This PowerShell example reads the signed-in synthetic profile’s existing proof into memory; it does not create a user, seed a session, reveal the proof in output or bypass a permission check. Do not use real city data in development examples. A read response does not prove approval or publication.
-```powershell
+``` powershell
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config\local-session.json'
$session = Get-Content -LiteralPath $sessionPath -Raw | ConvertFrom-Json
@@ -123,13 +253,13 @@ Remove-Variable session, headers
### Complete synthetic source bundle
-The [synthetic Zoning bundle](docs/beta-1/reference/examples/synthetic-geo-bundle.json) is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as `{"bundle": BUNDLE, "expected_previous_revision": null}`; for Permitting use `{"bundle": BUNDLE, "expected_revision": null}`. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
+The [synthetic Zoning bundle](https://townlight.github.io/reference/examples/synthetic-geo-bundle.json) is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as `{"bundle": BUNDLE, "expected_previous_revision": null}`; for Permitting use `{"bundle": BUNDLE, "expected_revision": null}`. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
### A synthetic write with subsequent readback
This example demonstrates the existing Meetings HTTP contract in an isolated exercise. It is intentionally fictional. It does not start a service. Its authentication setup is included so it can be run independently under the signed-in synthetic account. If a write times out, inspect current records before repeating it.
-```powershell
+``` powershell
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config/local-session.json'
$session = Get-Content -LiteralPath $sessionPath -Raw | ConvertFrom-Json
@@ -151,7 +281,11 @@ Remove-Variable session, headers
This write requires Meetings to be enabled and the signed-in staff role to permit it. It is a cross-suite integration example; for this product’s request models, use the complete technical reference below.
-## MCP status
+### Complete technical contract
+
+Read the [Zoning API reference](https://townlight.github.io/api/zoning.html) for every documented operation, request field, constraint, response declaration and source supplement. Download the [OpenAPI JSON](https://townlight.github.io/api/zoning-openapi.json) for tools. For Station this is the suite-side schema only; its separate service contract is documented in the API supplement. The [reference directory](https://townlight.github.io/reference/index.html) includes configuration/source inventories, dependency declarations, native command contracts, MCP signatures and candidate evidence.
+
+## MCP and automation boundary
No direct product MCP server is exposed by the accepted Townlight desktop or Station boundary. Do not configure an invented `townlight mcp` command or assume an AI client has staff permissions. The integration surfaces for this beta are native IPC, the documented HTTP APIs, source bundle imports, exact exports and the existing Station CLI.
@@ -159,59 +293,186 @@ The bundled transcription code includes a **TextFlowKit MCP adapter** as a separ
For a transcription client already provisioned separately, an illustrative tool call is:
-```json
+``` json
{"name":"get_job_status","arguments":{"job_id":"synthetic-existing-job-id"}}
```
-Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the [MCP source reference](docs/beta-1/reference/mcp.html). Station meeting capture does not become live speech recognition because this optional donor adapter exists.
+Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the [MCP source reference](https://townlight.github.io/reference/mcp.html). Station meeting capture does not become live speech recognition because this optional donor adapter exists.
+
+## Security and permissions
+
+Use your own named account and save before leaving a screen. A saved draft is durable; unsaved form text may not be. If a write has an unknown result, reopen its record before repeating it.
+
+Read source jurisdiction, dates, citation, version and visibility. A copied source hash identifies exact bytes, not their legal applicability. If a source changes or permission is removed, resolve the source problem rather than substituting stale cached content.
+
+Keep originals and derivatives separate. Review the intended audience before export. A public summary excludes private fields only through the applicable copy contract and your review. A renamed private packet is still private content.
+
+Drafting, review, approval, attachment, export, fulfillment and publication are separate operations. A Townlight workpaper does not itself adopt law, issue a permit, impose a fine or release a records response. The responsible staff member records the applicable decision.
+
+The native session is validated and mapped to a persisted SQL identity. An editable actor/reviewer label is not authentication. Product/module permissions and source visibility apply at the server boundary. Revoked/unavailable authority fails closed for new Station operations; a previous permission result is not a perpetual authorization.
+
+Use protected local folders, account permissions and credential storage. Never include the native session file, database passwords, provider keys or unredacted support bundles in a public issue or generated public documentation. A local public view is not automatically a secured internet deployment. Keep network exposure and real equipment acceptance specific to the chosen beta site.
+
+## Backup recovery and maintenance
+
+Save work and use Core’s canonical **Backup Now** before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use **Start** to resume. A source export is not a full backup.
+
+Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not.
+
+Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs.
+
+On failure, record the time, selected composition, component/installer versions and exact message. Check System Health for stopped, starting, ready or failed dependencies. Use the existing Retry control after readiness; do not create duplicate business records to refresh a stale view. Share only a redacted diagnostic bundle. Preserve secrets, original evidence, recovery material and unrelated installations.
+
+## Troubleshooting
+
+| Symptom | Likely meaning | Next action |
+|----|----|----|
+| Workspace absent | Wrong product composition or unavailable canonical runtime. | Check selected composition; activate through Finish Records Migration; wait for readiness. |
+| Cannot sign in / 401 | Missing or expired named account session. | Sign in normally; reopen a Station launch ticket if applicable. |
+| Permission denied / 403 | Account, module, source or browser-origin permission. | Ask the authorized administrator to inspect the intended permission; do not invent role headers. |
+| Save conflict / 409 | The saved revision, expected source hash or lifecycle changed. | Keep edits, reopen current state and reconcile deliberately. |
+| Invalid input / 422 | Required field, format, geometry, source envelope or state is invalid. | Read the field detail and correct the input/source; preserve originals. |
+| Service unavailable / 503 | Database, schema, connected source or configuration unavailable. | Inspect System Health and the named dependency. Preserve work; retry only after readiness. |
+| Export refused | Missing exact review, approval, audience or source authorization. | Read the refusal and complete the owning product’s explicit decision. |
+| Restore needs service start | The snapshot was restored but services have not resumed. | Use Start, then Check and verify a saved record; do not blindly repeat restore. |
-## Verification and known limits
+## Verified workflows and limits
| Product | Recorded result | Precisely exercised |
-| --- | --- | --- |
+|----|----|----|
| Zoning | PASS | GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. |
-
These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run.
-The [workflow matrix](docs/beta-1/reference/workflow-matrix.json) identifies raw receipt filenames. The [evidence index](docs/beta-1/reference/sandbox-evidence-index.json) retains their original hashes; raw receipts remain in the private beta handoff rather than being silently republished with the documentation site.
+See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) for this MSI. The historical [evidence index](https://townlight.github.io/reference/sandbox-evidence-index.json) applies to its original build.
The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim.
-The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.
+## Terms of service and license
-## Development and repository map
+### Scope and status
-Use the corresponding source for the candidate rather than assuming the public default branch matches it. The source companion contains `installed-owned-source`, product build inputs, desktop Rust/browser sources, locks and `BUILD.md`. It excludes credentials and third-party binary/model payloads. Use the recorded runtime lock when reproducing packaging.
+These terms describe the Townlight Beta 1 software and this documentation package. This public Windows beta is for evaluation. No uptime commitment, support response time, indemnity, data-processing agreement or paid service is created by these documents. A separate signed agreement, if any, governs services it actually provides.
-Relevant source contracts:
+### Software license and rights
-- `townlight_zoning/geo_import.py`
-- `townlight_zoning/discretionary.py`
-- `townlight_runtime/zoning_bridge.py`
-- `townlight_runtime/zoning_records.py`
+Current Townlight-owned distributions identified in this candidate use **AGPL-3.0-only**. The full license is supplied with this documentation and with the source companion. The license governs rights to run, copy, modify and convey the covered software; these operational terms do not add restrictions to those rights. Historical grants and dependency licenses retain their own terms. CivicCast remains a separate product and is not relicensed by this documentation work.
-The desktop package defines `npm run build`, `npm test`, `npm run test:browser` and its Tauri command. Python products retain their own `pyproject.toml`, tests and migrations; use the matching checkout’s declared dependencies and test configuration. Do not run a sample server against a production profile. This documentation build validates documentation only and reuses the separately identified installed acceptance; it does not claim a new complete application CI run.
+When conveying covered software, retain applicable notices and provide the corresponding source and installation/build information required by the license. For a modified version supporting remote network interaction, follow section 13’s source-offer requirement. The companion archive identifies the source for this candidate; a link to a different public branch is not a substitute for the matching source. Read the supplied license for the complete conditions. See the [GNU license reference](https://www.gnu.org/licenses/agpl-3.0.html) and [GNU licensing FAQ](https://www.gnu.org/licenses/gpl-faq.en.html).
-## Recovery and support
+### Data ownership and access
-Save work and use Core’s canonical **Backup Now** before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use **Start** to resume. A source export is not a full backup.
+Importing a document does not transfer its ownership or grant permission to publish it. The operating organization controls its accounts, access decisions, lawful source use, retention and review/release policy. Keep resident information, credentials, private notes and restricted evidence in their authorized locations. Documentation examples contain fictional data. No real city account, credential or record is required to exercise these examples in an isolated test environment.
-Use **Restore Latest Backup** through the supported controls. If the result says **Restore needs service start**, use **Start**, then **Check**, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not.
+### Local operation and external processors
-Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs.
+The accepted beta workflow is local and uses named staff accounts. Station has separate storage and credentials. Configure backup destinations and optional model/network providers deliberately. A configured external provider may receive submitted prompts, images or audio according to that configuration and provider’s terms; this documentation does not promise that every optional configuration is offline. An email outbox or local public view does not establish external delivery or an internet deployment. This static documentation site has no analytics, account collection or remote font dependency.
+
+### Staff decisions and source applicability
+
+Staff verify the jurisdiction, source currency, permissions, citations and proposed audience. Model output and generated guidance require review. No draft is automatically an official legal interpretation, zoning determination, permit approval, fee assessment, enforcement notice or records-release decision. Official permit fee authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.
+
+### Beta operation and recovery
+
+Use the identified candidate in its supported fresh-install scope. Preserve backups and original evidence. Test physical equipment and chosen network/service configuration before relying on them. The supplied acceptance describes selected synthetic workflows, not every screen, vendor, field condition or upgrade. Operators decide whether a particular deployment meets their own operational obligations.
+
+### Warranty and liability
+
+The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written undertaking. This documentation creates no additional warranty or limitation beyond those terms. Third-party software is subject to its retained license notices. Nothing here removes rights that applicable law makes nonwaivable.
+
+### Support and incident reporting
+
+Use the project’s existing SUPPORT and SECURITY guidance for its matching repository. Report reproducible behavior with the version, operation and redacted logs. Do not put credentials, resident records or unredacted evidence in a public issue. Coordinate sensitive reports through the channel designated in SECURITY. No new support address or service commitment is invented here.
+
+### Ending a beta exercise and document changes
+
+When an organization ends testing, it controls retention/export and removes access according to its policy. Uninstall may retain data; back up and inspect the selected removal options. Ending an exercise does not revoke rights already granted by AGPL. Later software/documentation versions must identify their changed candidate and scope; historical receipts retain their original identities. These terms do not claim that a city has accepted a contract merely by reading a manual.
+
+## Glossary
+
+| Term | Meaning |
+|----|----|
+| Approval | An explicit authorized decision on the saved text/artifact. It is separate from saving or attachment. |
+| Canonical record | The owning product’s retained identity and saved version, rather than an editable copied label. |
+| Composition | The selected set of desktop modules; inspections-preview exposes the eight staff products. |
+| Corresponding source | The source/build material matching the delivered covered program, subject to its license. |
+| Derivative / Records copy | A separately prepared document with its own intended audience and hash. |
+| Hash / SHA256 | A fingerprint of exact bytes. It detects change; it does not establish legal authority. |
+| Idempotency | Repeating the same identified request has the same intended effect; changing its payload can be refused. |
+| IPC | The native desktop command boundary between its browser interface and Rust host. |
+| MCP | Model Context Protocol; no direct Townlight product server is enabled by this beta. |
+| Original | Retained source bytes. A reviewed derivative does not replace them. |
+| Provenance | Source, version, date, actor and relationship information retained with evidence. |
+| Revision | An immutable saved version. Later edits do not inherit an earlier review automatically. |
+| Snapshot | A fixed audience-specific copy tied to a source/reviewed revision. |
+| Station | Townlight’s separate media boundary using a pinned CivicCast-derived engine; standalone CivicCast remains separate. |
+
+## Alphabetical subject index
+
+- **Accounts and authentication** — [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions).
+- **AGPL and source** — [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license).
+- **API contracts** — [API and integration examples](https://townlight.github.io/manuals/zoning.html#api-and-integration-examples).
+- **Architecture** — [Architecture](https://townlight.github.io/manuals/zoning.html#architecture).
+- **Backup** — [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance).
+- **Beta version** — [Beta identity](https://townlight.github.io/manuals/zoning.html#beta-identity).
+- **Configuration** — [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration).
+- **Evidence and acceptance** — [Verified workflows and limits](https://townlight.github.io/manuals/zoning.html#verified-workflows-and-limits).
+- **Fees and official decisions** — [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license).
+- **First run** — [First run](https://townlight.github.io/manuals/zoning.html#first-run).
+- **Handoffs and audience** — [Connected workflows](https://townlight.github.io/manuals/zoning.html#connected-workflows).
+- **MCP** — [MCP and automation boundary](https://townlight.github.io/manuals/zoning.html#mcp-and-automation-boundary).
+- **Originals and provenance** — [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions).
+- **Recovery** — [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance).
+- **Staff procedures** — [Daily workflow](https://townlight.github.io/manuals/zoning.html#daily-workflow).
+- **Station configuration** — [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration).
+- **Technical stack** — [Technical specifications](https://townlight.github.io/manuals/zoning.html#technical-specifications).
+- **Troubleshooting** — [Troubleshooting](https://townlight.github.io/manuals/zoning.html#troubleshooting).
+
+### Operating subject links
+
+- **Discretionary processes and staff review** — [Discretionary processes and staff review](https://townlight.github.io/manuals/zoning.html#discretionary-processes-and-staff-review).
+- **Explain the cited process** — [Explain the cited process](https://townlight.github.io/manuals/zoning.html#explain-the-cited-process).
+- **Keep parcel import and inspection in the right order** — [Keep parcel import and inspection in the right order](https://townlight.github.io/manuals/zoning.html#keep-parcel-import-and-inspection-in-the-right-order).
+- **Use the existing specialist review contracts** — [Use the existing specialist review contracts](https://townlight.github.io/manuals/zoning.html#use-the-existing-specialist-review-contracts).
+
+## Source and document control
+
+This edition is authored from the immutable corresponding-source companion, the generated installed-domain schema and the retained workflow receipts. The current software versions and signed artifacts are unchanged. Public historical pages are not synchronized or published by this local documentation task.
+
+### Workflow subject index
+
+- **Ask a parcel question** — [Daily workflow, step 4](https://townlight.github.io/manuals/zoning.html#workflow-4).
+
+- **Create a snapshot** — [Daily workflow, step 6](https://townlight.github.io/manuals/zoning.html#workflow-6).
+
+- **Import and inspect** — [Daily workflow, step 2](https://townlight.github.io/manuals/zoning.html#workflow-2).
+
+- **Prepare parcel data** — [Daily workflow, step 1](https://townlight.github.io/manuals/zoning.html#workflow-1).
+
+- **Record review and context** — [Daily workflow, step 5](https://townlight.github.io/manuals/zoning.html#workflow-5).
+
+- **Register cited rules** — [Daily workflow, step 3](https://townlight.github.io/manuals/zoning.html#workflow-3).
+
+- **Use it downstream** — [Daily workflow, step 7](https://townlight.github.io/manuals/zoning.html#workflow-7).
+
+- [Source inventory and file hashes](https://townlight.github.io/reference/source-inventory.json)
+
+- [All component metadata](https://townlight.github.io/reference/component-metadata.json)
+
+- [Installed domain OpenAPI](https://townlight.github.io/reference/desktop-domain-openapi.json)
+
+- [Workflow matrix](https://townlight.github.io/reference/workflow-matrix.json)
+
+- [Full AGPL text](https://townlight.github.io/reference/AGPL-3.0.txt)
-On failure, record the time, selected composition, component/installer versions and exact message. Check System Health for stopped, starting, ready or failed dependencies. Use the existing Retry control after readiness; do not create duplicate business records to refresh a stale view. Share only a redacted diagnostic bundle. Preserve secrets, original evidence, recovery material and unrelated installations.
-## Prepared package installation
+## Source package installation
-The renamed distributions are not yet published on a package index. Use the
-matching verified candidate wheel directory, not a renamed historical release
-URL. Installation of these Python packages is a developer/package check;
+Use locally built wheels from the exact component sources in the corresponding-source companion and verify their hashes. Do not relabel historical release assets. Installation of these Python packages is a developer/package check;
the signed Windows MSI and its installed acceptance remain separate.
In a new Windows virtual environment, replace the example wheel-directory path
-with the directory accompanying this candidate and verify its SHA256 manifest:
+with your locally built wheel directory from the matching pinned source and verify its SHA256 manifest:
```powershell
python -m venv .venv
diff --git a/README.txt b/README.txt
index 2961a6c..5467a09 100644
--- a/README.txt
+++ b/README.txt
@@ -1,111 +1,379 @@
- Prepared naming, Access and Notice candidate — 2 November 2026. Build, signing, installed acceptance and publication remain pending. Earlier signed releases and receipts apply only to their identified artifacts.
+Windows x64 Beta 1 · MSI 1.7.0.1
+
+The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows
+Sandbox checks with synthetic data.
+
+- Townlight Zoning Manual
+ - Contents
+ - Using this manual
+ - Beta identity
+ - First run
+ - Daily workflow
+ - Connected workflows
+ - Architecture
+ - Discretionary processes and staff review
+ - Technical specifications
+ - Configuration and administration
+ - API and integration examples
+ - MCP and automation boundary
+ - Security and permissions
+ - Backup recovery and maintenance
+ - Troubleshooting
+ - Verified workflows and limits
+ - Terms of service and license
+ - Glossary
+ - Alphabetical subject index
+ - Source and document control
+
+Townlight Zoning Manual
+
+Townlight Beta 1 · Naming candidate documentation edition 2 November
+2026
+
+Contents
+
+- Using this manual
+- Beta identity
+- First run
+- Daily workflow
+- Connected workflows
+- Architecture
+- Discretionary processes and staff review
+- Technical specifications
+- Configuration and administration
+- API and integration examples
+- MCP and automation boundary
+- Security and permissions
+- Backup recovery and maintenance
+- Troubleshooting
+- Verified workflows and limits
+- Terms of service and license
+- Glossary
+- Alphabetical subject index
+- Source and document control
+
+Using this manual
+
+Townlight Zoning helps planners, land-use staff and authorized
+reviewers. Zoning combines local parcel geometry, cited zoning rules and
+staff review. It retains questions, corrections and snapshots with
+provenance so downstream staff can identify the precise evidence used.
+
+Staff should begin with First run and Daily workflow. Administrators
+should also read Architecture, Technical specifications, Configuration,
+Security and Recovery. Developers should use the exact API/data
+dictionary and examples. The table of contents and alphabetical subject
+index link to the relevant sections in the HTML edition; the PDF
+preserves headings and searchable text. An editable Word edition is
+included with the same documentation companion.
+
+Beta identity
+
+ Identity Value
+ -------------------------------- -------------------------------------------------------------------------------
+ Documentation Townlight Beta 1 naming, Access and Notice candidate
+ Intended installer version 1.7.0.1
+ Product component townlight-zoning 0.2.3
+ Principal import package townlight_zoning
+ Native desktop source version 1.7.0-1
+ Candidate hashes SHA-256 checksums and Windows acceptance summary
+ Current owned software license AGPL-3.0-only
+ Acceptance composition Fresh Windows x64 profile; inspections-preview; Station configured separately
+
+Use an empty database and fresh Windows profile. The installer refuses
+legacy profile initialization. The approved profile path is
+%LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.
+
+First run
+
+1. Download the signed MSI, matching source companion and checksums
+ from the public Windows release.
+2. Verify the MSI hash and Authenticode publisher before installing on
+ a fresh Windows profile. See the Windows acceptance summary for the
+ tested setup.
+3. Launch Townlight under the intended named Windows account. Choose
+ the storage folders. Select Townlight Inspections candidate
+ (inspections-preview) for the bounded desktop composition, including
+ Access and Notice. A narrower default selection will not expose all
+ workspaces.
+4. Enter the city profile, time zone and contacts. Create the first
+ named local administrator, sign in and choose protected backup
+ storage. Continue without local AI is valid for the deterministic
+ workflows.
+5. Run Health Check and wait for readiness. Open Townlight. In System
+ Health select Finish Records Migration to activate the canonical
+ Python/PostgreSQL runtime. Do not fabricate migration receipts or
+ seed accounts.
+6. Create named staff through Settings. Import authorized sources using
+ each product’s source library. All examples in this package are
+ synthetic; they are not municipal authority.
+7. Provision Station separately if it is part of the beta exercise.
+ Selecting the desktop composition does not start or configure
+ Station. Configure vision explicitly only if automatic photo
+ drafting is selected.
+
+Daily workflow
+
+1. Prepare parcel data
+
+Use the complete supported bundle, including jurisdiction, dataset
+metadata and original hashes. The coordinates must be EPSG:4326. A loose
+geometry file is not the full source envelope.
+
+2. Import and inspect
+
+Check the complete source envelope before selecting Import parcel
+dataset. That control submits directly; inspect the saved
+validation/provenance result afterward. Correct a refused source bundle
+and preserve the evidence. Do not force acceptance by editing SQL.
+
+3. Register cited rules
+
+Associate the zone, rule kind/key and value with the relevant public
+Code section. Inspect overlays and effective context. Leave missing
+authority visible for planner review.
+
+4. Ask a parcel question
+
+Look up the intended parcel and ask the supported question. Read the
+returned citation, applicability and disclaimer. Do not present an
+uncertain answer as an official decision.
+
+5. Record review and context
+
+Record a correction and its reason when needed. Select permitted
+Meetings history explicitly. Preserve the question/review history and
+distinguish staff-only precedent from public material.
+
+6. Create a snapshot
+
+Review the audience and exact content before creating the immutable
+snapshot. A public snapshot must satisfy its permitted-source contract;
+choosing a public label does not sanitize private notes.
+
+7. Use it downstream
+
+Select the exact snapshot for Records or the permitted provider path.
+The receiving workflow rechecks visibility, source identity and hash
+before retaining or exporting it.
+
+Working safely
+
+Use your own named account and save before leaving a screen. A saved
+draft is durable; unsaved form text may not be. If a write has an
+unknown result, reopen its record before repeating it.
+
+Read source jurisdiction, dates, citation, version and visibility. A
+copied source hash identifies exact bytes, not their legal
+applicability. If a source changes or permission is removed, resolve the
+source problem rather than substituting stale cached content.
+
+Keep originals and derivatives separate. Review the intended audience
+before export. A public summary excludes private fields only through the
+applicable copy contract and your review. A renamed private packet is
+still private content.
+
+Drafting, review, approval, attachment, export, fulfillment and
+publication are separate operations. A Townlight workpaper does not
+itself adopt law, issue a permit, impose a fine or release a records
+response. The responsible staff member records the applicable decision.
+
+Connected workflows
+
+Consumes Code authority and permitted Meetings evidence. Supplies
+permitted snapshots to Records and context to Planning and Permitting.
+
+ Direction Material
+ ----------- ----------------------------------------------------------------------------------------------------------------------------------
+ Input A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence.
+ Output Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes.
+
+Product boundary
+
+The accepted path is local GeoJSON/PostGIS. It does not establish every
+ArcGIS, assessor or CKAN connector. Answers and process explanations are
+informational and do not issue an entitlement or an official zoning
+determination.
+
+Architecture
+
+The drawing shows the principal staff/evidence path. Native commands
+carry trusted identity to Python business services; PostgreSQL and
+retained original files hold durable state. A downstream copy does not
+silently transfer decision authority. Station has its own configured
+authority/media boundary, database and mutable files. The
+connected-workflow text supplies the drawing’s reading order and
+accessibility alternative.
-Townlight Zoning
+Discretionary processes and staff review
-Townlight Beta 1 · Naming candidate; component versions advanced · AGPL-3.0-only
+Explain the cited process
-Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.
+In the existing Zoning workspace, complete Variance, conditional use or
+nonconformity question. Supply the applicable process Code section, zone
+code, optional comma-separated standard to cite, and optional observed
+condition, for example front_setback=8 feet. Select Explain the cited
+process. Choose actual imported public authority; the synthetic values
+below require matching synthetic sources to return supported guidance.
-Start here
+The mounted API is POST /desktop/v1/zoning/standards/process-explanation
+under the normal authenticated staff session. Its equivalent request
+body is:
-Staff should use the operating manual. Administrators should read first-run, configuration and recovery before changing a deployment. Developers should read the exact API/schema reference and matching source companion. This edition describes the prepared source candidate; obtain its installer only after signing and installed acceptance identify the exact artifact.
+ {"question":"Explain the synthetic variance process","process_section":"18.20.050","zone_code":"SYN-R","rule_types":["front_setback"],"observed":{"front_setback":"8 feet"}}
-- Operating manual · Printable PDF · Editable Word manual
-- API and data dictionary · OpenAPI JSON
-- Product and suite directory · Terms and full license
+Read process citations and each cited standard independently. The output
+can explain a verified process while reporting unavailable standards or
+review flags. A difference between an observation and a cited standard
+is an informational flag; it is not a variance finding, approval,
+nonconformity determination or substitute for planner review. If no
+relevant authority is available, obtain the source or leave the item
+unavailable. Do not attach an unrelated citation to a proposed
+requirement.
+
+Keep parcel import and inspection in the right order
-Exact version and candidate
-
- Identity Value
- ------------------------------- ------------------------------------------------------
- Documentation Townlight Beta 1 naming, Access and Notice candidate
- Intended installer version 1.7.0.1; build and acceptance pending
- Native desktop source version 1.7.0-1
- Product component townlight-zoning 0.2.3
- Principal import package townlight_zoning
- Candidate hashes Pending build, signing and installed acceptance
- License AGPL-3.0-only
-
-Use a fresh profile and empty database. Existing unmarked city data is refused before initialization; no in-place upgrade is supported. Preserve the existing %LOCALAPPDATA%\CivicSuite profile, data and recovery material. Historical releases retain their original identities.
-
-What staff can do
-
-- Prepare parcel data: Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
-- Import and inspect: Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
-- Register cited rules: Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
-- Ask a parcel question: Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.
-- Record review and context: Record a correction and its reason when needed. Select permitted Meetings history explicitly. Preserve the question/review history and distinguish staff-only precedent from public material.
-- Create a snapshot: Review the audience and exact content before creating the immutable snapshot. A public snapshot must satisfy its permitted-source contract; choosing a public label does not sanitize private notes.
-- Use it downstream: Select the exact snapshot for Records or the permitted provider path. The receiving workflow rechecks visibility, source identity and hash before retaining or exporting it.
-
-Operating procedures and examples
-
-The operating manual now includes these existing procedures, with synthetic inputs, readback and limits. Follow the actual app boundary identified there; a standalone source capability is not automatically a desktop screen.
-
-- Discretionary processes and staff review.
-- Explain the cited process.
-- Keep parcel import and inspection in the right order.
-- Use the existing specialist review contracts.
-
-Architecture and data
+Check the complete JSON envelope, original hashes and EPSG:4326 geometry
+before submitting Import parcel dataset. That control sends the import
+directly; it does not open a separate preview/commit screen. Inspect the
+returned validation/provenance and saved dataset. The browser refuses
+bundle files larger than 20 MiB; valid geometry and metadata remain
+subject to server validation. Correct the source bundle after a refusal
+and retain earlier evidence rather than forcing SQL changes.
+
+Use the existing specialist review contracts
+
+The standalone Zoning application’s review/analytics/report routes are
+documented source capabilities, not extra native desktop screens. In a
+deployment where its actual staff authentication is already configured:
+
+- Create an ambiguity review with zone_code, question and reason at
+ /api/v1/townlight_zoning/staff/ambiguity-reviews. Read its returned ID
+ and list state. Update that ID with status, optional assigned_to and
+ resolution; use open, in_review, resolved or closed. Resolving or
+ closing requires a nonempty resolution.
+- Retain a flagged answer at
+ /api/v1/townlight_zoning/staff/flagged-answers with the original
+ question/answer, zone, flag reason and source citations. Use
+ /{review_id}/improve with improved_answer and improvement_notes.
+ Preserve the original and improvement attribution; a correction does
+ not rewrite the imported Code source.
+- Read /api/v1/townlight_zoning/staff/questions/analytics with the
+ desired high_volume_threshold to identify repeated questions and
+ uncertain answers. Analytics counts are review aids, not
+ jurisdictional conclusions.
+- Create /api/v1/townlight_zoning/staff/reports/outline with a title and
+ actual selected question_ids/queue_item_ids. Review the resulting
+ outline and citations before incorporating it in a staff report. It is
+ not a filed report or a meeting decision.
+
+A synthetic ambiguity request is:
+
+ {"zone_code":"SYN-R","question":"Which retained setback rule applies?","reason":"Synthetic overlay ambiguity requires planner review"}
+
+Do not send invented staff-role headers or assume these standalone paths
+exist at the installed desktop origin. The native workspace’s supported
+review/history/snapshot controls continue to use its fixed authenticated
+bridge. Use the technical supplement to distinguish the two surfaces.
+
+Source contracts: townlight_runtime/zoning_bridge.py,
+townlight_zoning/main.py, the imported rule/source models and desktop
+Zoning view.
+
+Technical specifications
Runtime and storage
-This prepared source candidate targets Windows x64 fresh installation. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 / PostGIS and managed original files. The prior accepted runtime contained FastAPI 0.162.0; this changed candidate requires its own installed dependency verification. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label.
-
-The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL uses the configured local runtime port (default 15432). Optional local model service defaults to 127.0.0.1:15434. Those are deployment defaults, not internet endpoints. The runtime has health, module and readiness endpoints; readiness is stronger than process existence. The task queue is the existing local Core task infrastructure, not an assertion that a separate Redis service is required for this desktop composition.
-
-The default native profile is %LOCALAPPDATA%\CivicSuite; the historical directory name remains part of compatibility. Do not rename it to Townlight. A configured TOWNLIGHT_PROFILE_ROOT must be absolute. Local configuration and secrets live under that profile; protected managed files and database state must be backed up coherently. Source/runtime identity is distinct from a product’s display label.
+The accepted package targets Windows x64 fresh installation. Its native
+shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are
+JavaScript built with Vite 8.1.6. This describes the native desktop
+frontend; Station has a separate React operator, specified below or in
+its product manual. Canonical business workflows use bundled CPython
+3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 /
+PostGIS and managed original files. The installed runtime tested here
+contains FastAPI 0.162.0. Package minimum Python requirements can differ
+from the bundled executable; the metadata reference preserves both. No
+stack rewrite is implied by the beta label.
+
+The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL
+uses the configured local runtime port (default 15432). Optional local
+model service defaults to 127.0.0.1:15434. Those are deployment
+defaults, not internet endpoints. The runtime has health, module and
+readiness endpoints; readiness is stronger than process existence. The
+task queue is the existing local Core task infrastructure, not an
+assertion that a separate Redis service is required for this desktop
+composition.
+
+The default native profile is %LOCALAPPDATA%\CivicSuite; the historical
+directory name remains part of compatibility. Do not rename it to
+Townlight. A configured TOWNLIGHT_PROFILE_ROOT must be absolute. Local
+configuration and secrets live under that profile; protected managed
+files and database state must be backed up coherently. Source/runtime
+identity is distinct from a product’s display label.
Data and consistency
-GeoJSON import datasets; parcels and zone/overlay context; cited rules; questions and answers; review events; selected Meetings history; immutable snapshots.
+GeoJSON import datasets; parcels and zone/overlay context; cited rules;
+questions and answers; review events; selected Meetings history;
+immutable snapshots.
-Versioned saves use expected prior revision identifiers where defined. Reopen and reconcile on conflict. Exact exports and handoffs use source IDs, current visibility, revision and SHA256. Review belongs to the saved revision and does not transfer silently to edited text. Database changes use the owning product’s migrations; a request or readiness check is not an authorization to mutate schema.
+Versioned saves use expected prior revision identifiers where defined.
+Reopen and reconcile on conflict. Exact exports and handoffs use source
+IDs, current visibility, revision and SHA256. Review belongs to the
+saved revision and does not transfer silently to edited text. Database
+changes use the owning product’s migrations; a request or readiness
+check is not an authorization to mutate schema.
Capacity and platform statements
-This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The new installer size remains pending its build; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
-
-The exact runtime payload lock records pinned files, sizes and hashes. The component metadata records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
-
- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Data contract Description
- ----------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------
- Input A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence.
-
- Retained records GeoJSON import datasets; parcels and zone/overlay context; cited rules; questions and answers; review events; selected Meetings history; immutable snapshots.
-
- Output Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes.
-
- Connections Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.
- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+This beta has synthetic single-profile workflow evidence. It does not
+have a published benchmark for concurrent staff capacity, minimum
+RAM/CPU, large-source limits or a field SLA. Do not turn a developer
+machine’s specification into a supported minimum. The signed MSI is
+2,082,697,216 bytes; allow additional disk for extracted runtime,
+database, originals, exports, media and backups. Select
+equipment/storage after sizing those actual workloads.
-Setup and operation
+The exact runtime payload lock records pinned files, sizes and hashes.
+The component metadata records shipped dependency declarations. These
+references are more precise than a manually copied dependency list.
+Third-party and historical license notices must accompany their matching
+payloads.
-1. Obtain the identified signed private candidate and its corresponding-source companion from the beta coordinator. The landing pages in this documentation are not an installer download service.
-2. On the intended fresh Windows test installation, verify the MSI hash and publisher signature before installing. Preserve unrelated profiles and recovery material. Installed acceptance for this source candidate remains pending; no in-place legacy upgrade is supported.
-3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select Townlight Inspections candidate (inspections-preview) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
-4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. Continue without local AI is valid for the deterministic workflows.
-5. Run Health Check and wait for readiness. Open Townlight. In System Health select Finish Records Migration to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
-6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
-7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
-
-Configuration
+Configuration and administration
Native deployment configuration
-Use Setup, Settings and System Health for supported staff operation. Administrators provision folders, backup storage, named accounts and the city profile. Select inspections-preview for the bounded desktop composition, including Access and Notice. Station remains a separate service boundary. Do not use a standalone product’s demo server as a substitute for the installed workspace.
-
-Technical deployments use TOWNLIGHT_PRODUCT_PROFILE, TOWNLIGHT_PROFILE_ROOT, DATABASE_URL, TOWNLIGHT_RUNTIME_PORT, PORTAL_MODE and the runtime-managed secret files. Treat database URLs and native session proofs as secrets. The installed native domain runtime explicitly refuses non-loopback binding. PORTAL_MODE=private is the accepted posture; changing it does not by itself commission an internet portal, authentication provider or reverse proxy.
-
-The isolated documentation exporter sets a fictional profile and unusable synthetic database origin only to read schemas; those values are not deployment configuration. Keep deployment values in the intended process/account scope. An already-running process does not automatically inherit later environment edits.
-
-API usage
+Use Setup, Settings and System Health for supported staff operation.
+Administrators provision folders, backup storage, named accounts and the
+city profile. Select inspections-preview for the bounded desktop
+composition, including Access and Notice. Station remains a separate
+service boundary. Do not use a standalone product’s demo server as a
+substitute for the installed workspace.
+
+Technical deployments use TOWNLIGHT_PRODUCT_PROFILE,
+TOWNLIGHT_PROFILE_ROOT, DATABASE_URL, TOWNLIGHT_RUNTIME_PORT,
+PORTAL_MODE and the runtime-managed secret files. Treat database URLs
+and native session proofs as secrets. The installed native domain
+runtime explicitly refuses non-loopback binding. PORTAL_MODE=private is
+the accepted posture; changing it does not by itself commission an
+internet portal, authentication provider or reverse proxy.
+
+The isolated documentation exporter sets a fictional profile and
+unusable synthetic database origin only to read schemas; those values
+are not deployment configuration. Keep deployment values in the intended
+process/account scope. An already-running process does not automatically
+inherit later environment edits.
+
+API and integration examples
Native command example
-The following JavaScript belongs in the existing trusted Townlight frontend/development environment with invoke imported from @tauri-apps/api/core. It is not a command for an arbitrary web page or an instruction for nontechnical staff. IDs must come from records created in an isolated synthetic exercise.
+The following JavaScript belongs in the existing trusted Townlight
+frontend/development environment with invoke imported from
+@tauri-apps/api/core. It is not a command for an arbitrary web page or
+an instruction for nontechnical staff. IDs must come from records
+created in an isolated synthetic exercise.
import { invoke } from '@tauri-apps/api/core';
const result = await invoke('zoning_domain_request', {request: {operation: 'history', id: questionId}});
@@ -113,7 +381,12 @@ The following JavaScript belongs in the existing trusted Townlight frontend/deve
Trusted local HTTP example
-An administrator/developer can inspect an already-configured isolated runtime from a trusted local process. This PowerShell example reads the signed-in synthetic profile’s existing proof into memory; it does not create a user, seed a session, reveal the proof in output or bypass a permission check. Do not use real city data in development examples. A read response does not prove approval or publication.
+An administrator/developer can inspect an already-configured isolated
+runtime from a trusted local process. This PowerShell example reads the
+signed-in synthetic profile’s existing proof into memory; it does not
+create a user, seed a session, reveal the proof in output or bypass a
+permission check. Do not use real city data in development examples. A
+read response does not prove approval or publication.
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config\local-session.json'
@@ -124,11 +397,24 @@ An administrator/developer can inspect an already-configured isolated runtime fr
Complete synthetic source bundle
-The synthetic Zoning bundle is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as {"bundle": BUNDLE, "expected_previous_revision": null}; for Permitting use {"bundle": BUNDLE, "expected_revision": null}. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
+The synthetic Zoning bundle is the retained fixture used by the beta
+staff exercise. It includes the complete supported source envelope
+rather than a shortened pseudo-payload. Keep its fictional source
+labels. For Planning, wrap it as
+{"bundle": BUNDLE, "expected_previous_revision": null}; for Permitting
+use {"bundle": BUNDLE, "expected_revision": null}. Code and Zoning take
+their own complete import envelopes. Replace null with the current
+expected revision when revising an existing source, as the applicable
+schema requires. These are import examples, not legal authority or
+permission to load them into a live city profile.
A synthetic write with subsequent readback
-This example demonstrates the existing Meetings HTTP contract in an isolated exercise. It is intentionally fictional. It does not start a service. Its authentication setup is included so it can be run independently under the signed-in synthetic account. If a write times out, inspect current records before repeating it.
+This example demonstrates the existing Meetings HTTP contract in an
+isolated exercise. It is intentionally fictional. It does not start a
+service. Its authentication setup is included so it can be run
+independently under the signed-in synthetic account. If a write times
+out, inspect current records before repeating it.
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config/local-session.json'
@@ -148,65 +434,338 @@ This example demonstrates the existing Meetings HTTP contract in an isolated exe
-Headers $headers
Remove-Variable session, headers
-This write requires Meetings to be enabled and the signed-in staff role to permit it. It is a cross-suite integration example; for this product’s request models, use the complete technical reference below.
+This write requires Meetings to be enabled and the signed-in staff role
+to permit it. It is a cross-suite integration example; for this
+product’s request models, use the complete technical reference below.
-MCP status
+Complete technical contract
-No direct product MCP server is exposed by the accepted Townlight desktop or Station boundary. Do not configure an invented townlight mcp command or assume an AI client has staff permissions. The integration surfaces for this beta are native IPC, the documented HTTP APIs, source bundle imports, exact exports and the existing Station CLI.
-
-The bundled transcription code includes a TextFlowKit MCP adapter as a separate source capability. It offers job-based transcribe_media, get_transcript, list_jobs, get_job_status and export_transcript, and additional tools declared in that adapter. It uses stdio first and optional Streamable HTTP, with the MCP SDK as an optional extra. It is not automatically launched, authenticated as Townlight staff or accepted as a Townlight product MCP deployment. This documentation does not add such a service.
-
-For a transcription client already provisioned separately, an illustrative tool call is:
-
- {"name":"get_job_status","arguments":{"job_id":"synthetic-existing-job-id"}}
+Read the Zoning API reference for every documented operation, request
+field, constraint, response declaration and source supplement. Download
+the OpenAPI JSON for tools. For Station this is the suite-side schema
+only; its separate service contract is documented in the API supplement.
+The reference directory includes configuration/source inventories,
+dependency declarations, native command contracts, MCP signatures and
+candidate evidence.
-Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the MCP source reference. Station meeting capture does not become live speech recognition because this optional donor adapter exists.
+MCP and automation boundary
-Verification and known limits
+No direct product MCP server is exposed by the accepted Townlight
+desktop or Station boundary. Do not configure an invented townlight mcp
+command or assume an AI client has staff permissions. The integration
+surfaces for this beta are native IPC, the documented HTTP APIs, source
+bundle imports, exact exports and the existing Station CLI.
- --------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Product Recorded result Precisely exercised
- ----------------------- ----------------------- --------------------------------------------------------------------------------------------------------------------
- Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace.
+The bundled transcription code includes a TextFlowKit MCP adapter as a
+separate source capability. It offers job-based transcribe_media,
+get_transcript, list_jobs, get_job_status and export_transcript, and
+additional tools declared in that adapter. It uses stdio first and
+optional Streamable HTTP, with the MCP SDK as an optional extra. It is
+not automatically launched, authenticated as Townlight staff or accepted
+as a Townlight product MCP deployment. This documentation does not add
+such a service.
- --------------------------------------------------------------------------------------------------------------------------------------------------------------------
+For a transcription client already provisioned separately, an
+illustrative tool call is:
-These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run.
-
-The workflow matrix identifies raw receipt filenames. The evidence index retains their original hashes; raw receipts remain in the private beta handoff rather than being silently republished with the documentation site.
-
-The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim.
-
-The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.
-
-Development and repository map
-
-Use the corresponding source for the candidate rather than assuming the public default branch matches it. The source companion contains installed-owned-source, product build inputs, desktop Rust/browser sources, locks and BUILD.md. It excludes credentials and third-party binary/model payloads. Use the recorded runtime lock when reproducing packaging.
-
-Relevant source contracts:
+ {"name":"get_job_status","arguments":{"job_id":"synthetic-existing-job-id"}}
-- townlight_zoning/geo_import.py
-- townlight_zoning/discretionary.py
-- townlight_runtime/zoning_bridge.py
-- townlight_runtime/zoning_records.py
+Use a job ID returned by that transcription service. This example does
+not create a Townlight record or bypass its review/Records handoff. The
+exact optional adapter tool signatures are supplied in the MCP source
+reference. Station meeting capture does not become live speech
+recognition because this optional donor adapter exists.
+
+Security and permissions
+
+Use your own named account and save before leaving a screen. A saved
+draft is durable; unsaved form text may not be. If a write has an
+unknown result, reopen its record before repeating it.
+
+Read source jurisdiction, dates, citation, version and visibility. A
+copied source hash identifies exact bytes, not their legal
+applicability. If a source changes or permission is removed, resolve the
+source problem rather than substituting stale cached content.
+
+Keep originals and derivatives separate. Review the intended audience
+before export. A public summary excludes private fields only through the
+applicable copy contract and your review. A renamed private packet is
+still private content.
+
+Drafting, review, approval, attachment, export, fulfillment and
+publication are separate operations. A Townlight workpaper does not
+itself adopt law, issue a permit, impose a fine or release a records
+response. The responsible staff member records the applicable decision.
+
+The native session is validated and mapped to a persisted SQL identity.
+An editable actor/reviewer label is not authentication. Product/module
+permissions and source visibility apply at the server boundary.
+Revoked/unavailable authority fails closed for new Station operations; a
+previous permission result is not a perpetual authorization.
+
+Use protected local folders, account permissions and credential storage.
+Never include the native session file, database passwords, provider keys
+or unredacted support bundles in a public issue or generated public
+documentation. A local public view is not automatically a secured
+internet deployment. Keep network exposure and real equipment acceptance
+specific to the chosen beta site.
+
+Backup recovery and maintenance
+
+Save work and use Core’s canonical Backup Now before maintenance. That
+operation stops writers. Preserve the coherent profile/database/document
+backup and its receipt, then use Start to resume. A source export is not
+a full backup.
+
+Use Restore Latest Backup through the supported controls. If the result
+says Restore needs service start, use Start, then Check, and reopen a
+known record. Do not repeat restore merely because services need to
+start. The fresh-profile acceptance verified that a fulfilled request
+survived restore and a post-backup marker did not.
+
+Keep Station’s dedicated database and media evidence together in its own
+backup. Core’s native-profile backup must not be assumed to include an
+external Station data directory. Stop writers during a coordinated
+backup. Preserve failed media attempts and logs.
+
+On failure, record the time, selected composition, component/installer
+versions and exact message. Check System Health for stopped, starting,
+ready or failed dependencies. Use the existing Retry control after
+readiness; do not create duplicate business records to refresh a stale
+view. Share only a redacted diagnostic bundle. Preserve secrets,
+original evidence, recovery material and unrelated installations.
+
+Troubleshooting
+
+ Symptom Likely meaning Next action
+ ----------------------------- ------------------------------------------------------------------------ --------------------------------------------------------------------------------------------------
+ Workspace absent Wrong product composition or unavailable canonical runtime. Check selected composition; activate through Finish Records Migration; wait for readiness.
+ Cannot sign in / 401 Missing or expired named account session. Sign in normally; reopen a Station launch ticket if applicable.
+ Permission denied / 403 Account, module, source or browser-origin permission. Ask the authorized administrator to inspect the intended permission; do not invent role headers.
+ Save conflict / 409 The saved revision, expected source hash or lifecycle changed. Keep edits, reopen current state and reconcile deliberately.
+ Invalid input / 422 Required field, format, geometry, source envelope or state is invalid. Read the field detail and correct the input/source; preserve originals.
+ Service unavailable / 503 Database, schema, connected source or configuration unavailable. Inspect System Health and the named dependency. Preserve work; retry only after readiness.
+ Export refused Missing exact review, approval, audience or source authorization. Read the refusal and complete the owning product’s explicit decision.
+ Restore needs service start The snapshot was restored but services have not resumed. Use Start, then Check and verify a saved record; do not blindly repeat restore.
+
+Verified workflows and limits
+
+ Product Recorded result Precisely exercised
+ --------- ----------------- --------------------------------------------------------------------------------------------------------------------
+ Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace.
+
+These results come from the identified signed candidate’s fresh
+normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and
+selected headless controls. All accounts, source bundles and media were
+synthetic. The guest install/uninstall and recovery passed, and the
+owned Sandbox stopped. No host installed application or standalone
+CivicCast was changed. This documentation task reuses those receipts; it
+does not claim a new software acceptance run.
+
+See the Windows acceptance summary for this MSI. The historical evidence
+index applies to its original build.
+
+The limits remain: actual city field acceptance and equipment/network
+commissioning; Station automatic provisioning/SCM commissioning; every
+UI/role combination; field recognition accuracy; and historical in-place
+upgrades are not certified. They are not five invented feature
+requirements. Fresh-install controlled beta handoff remains the accepted
+scope. This package makes no city-deployment, publication or
+general-availability claim.
+
+Terms of service and license
+
+Scope and status
+
+These terms describe the Townlight Beta 1 software and this
+documentation package. This public Windows beta is for evaluation. No
+uptime commitment, support response time, indemnity, data-processing
+agreement or paid service is created by these documents. A separate
+signed agreement, if any, governs services it actually provides.
+
+Software license and rights
+
+Current Townlight-owned distributions identified in this candidate use
+AGPL-3.0-only. The full license is supplied with this documentation and
+with the source companion. The license governs rights to run, copy,
+modify and convey the covered software; these operational terms do not
+add restrictions to those rights. Historical grants and dependency
+licenses retain their own terms. CivicCast remains a separate product
+and is not relicensed by this documentation work.
+
+When conveying covered software, retain applicable notices and provide
+the corresponding source and installation/build information required by
+the license. For a modified version supporting remote network
+interaction, follow section 13’s source-offer requirement. The companion
+archive identifies the source for this candidate; a link to a different
+public branch is not a substitute for the matching source. Read the
+supplied license for the complete conditions. See the GNU license
+reference and GNU licensing FAQ.
+
+Data ownership and access
+
+Importing a document does not transfer its ownership or grant permission
+to publish it. The operating organization controls its accounts, access
+decisions, lawful source use, retention and review/release policy. Keep
+resident information, credentials, private notes and restricted evidence
+in their authorized locations. Documentation examples contain fictional
+data. No real city account, credential or record is required to exercise
+these examples in an isolated test environment.
+
+Local operation and external processors
+
+The accepted beta workflow is local and uses named staff accounts.
+Station has separate storage and credentials. Configure backup
+destinations and optional model/network providers deliberately. A
+configured external provider may receive submitted prompts, images or
+audio according to that configuration and provider’s terms; this
+documentation does not promise that every optional configuration is
+offline. An email outbox or local public view does not establish
+external delivery or an internet deployment. This static documentation
+site has no analytics, account collection or remote font dependency.
+
+Staff decisions and source applicability
+
+Staff verify the jurisdiction, source currency, permissions, citations
+and proposed audience. Model output and generated guidance require
+review. No draft is automatically an official legal interpretation,
+zoning determination, permit approval, fee assessment, enforcement
+notice or records-release decision. Official permit fee authority
+remains with the adopted source and responsible organization; imported
+amounts do not become a new authoritative calculation.
+
+Beta operation and recovery
+
+Use the identified candidate in its supported fresh-install scope.
+Preserve backups and original evidence. Test physical equipment and
+chosen network/service configuration before relying on them. The
+supplied acceptance describes selected synthetic workflows, not every
+screen, vendor, field condition or upgrade. Operators decide whether a
+particular deployment meets their own operational obligations.
+
+Warranty and liability
+
+The covered software’s warranty and liability conditions are those in
+sections 15–17 of the supplied AGPL and any applicable separate written
+undertaking. This documentation creates no additional warranty or
+limitation beyond those terms. Third-party software is subject to its
+retained license notices. Nothing here removes rights that applicable
+law makes nonwaivable.
+
+Support and incident reporting
+
+Use the project’s existing SUPPORT and SECURITY guidance for its
+matching repository. Report reproducible behavior with the version,
+operation and redacted logs. Do not put credentials, resident records or
+unredacted evidence in a public issue. Coordinate sensitive reports
+through the channel designated in SECURITY. No new support address or
+service commitment is invented here.
+
+Ending a beta exercise and document changes
+
+When an organization ends testing, it controls retention/export and
+removes access according to its policy. Uninstall may retain data; back
+up and inspect the selected removal options. Ending an exercise does not
+revoke rights already granted by AGPL. Later software/documentation
+versions must identify their changed candidate and scope; historical
+receipts retain their original identities. These terms do not claim that
+a city has accepted a contract merely by reading a manual.
+
+Glossary
+
+ Term Meaning
+ --------------------------- ---------------------------------------------------------------------------------------------------------------------
+ Approval An explicit authorized decision on the saved text/artifact. It is separate from saving or attachment.
+ Canonical record The owning product’s retained identity and saved version, rather than an editable copied label.
+ Composition The selected set of desktop modules; inspections-preview exposes the eight staff products.
+ Corresponding source The source/build material matching the delivered covered program, subject to its license.
+ Derivative / Records copy A separately prepared document with its own intended audience and hash.
+ Hash / SHA256 A fingerprint of exact bytes. It detects change; it does not establish legal authority.
+ Idempotency Repeating the same identified request has the same intended effect; changing its payload can be refused.
+ IPC The native desktop command boundary between its browser interface and Rust host.
+ MCP Model Context Protocol; no direct Townlight product server is enabled by this beta.
+ Original Retained source bytes. A reviewed derivative does not replace them.
+ Provenance Source, version, date, actor and relationship information retained with evidence.
+ Revision An immutable saved version. Later edits do not inherit an earlier review automatically.
+ Snapshot A fixed audience-specific copy tied to a source/reviewed revision.
+ Station Townlight’s separate media boundary using a pinned CivicCast-derived engine; standalone CivicCast remains separate.
+
+Alphabetical subject index
+
+- Accounts and authentication — Security and permissions.
+- AGPL and source — Terms of service and license.
+- API contracts — API and integration examples.
+- Architecture — Architecture.
+- Backup — Backup recovery and maintenance.
+- Beta version — Beta identity.
+- Configuration — Configuration and administration.
+- Evidence and acceptance — Verified workflows and limits.
+- Fees and official decisions — Terms of service and license.
+- First run — First run.
+- Handoffs and audience — Connected workflows.
+- MCP — MCP and automation boundary.
+- Originals and provenance — Security and permissions.
+- Recovery — Backup recovery and maintenance.
+- Staff procedures — Daily workflow.
+- Station configuration — Configuration and administration.
+- Technical stack — Technical specifications.
+- Troubleshooting — Troubleshooting.
+
+Operating subject links
+
+- Discretionary processes and staff review — Discretionary processes and
+ staff review.
+- Explain the cited process — Explain the cited process.
+- Keep parcel import and inspection in the right order — Keep parcel
+ import and inspection in the right order.
+- Use the existing specialist review contracts — Use the existing
+ specialist review contracts.
+
+Source and document control
+
+This edition is authored from the immutable corresponding-source
+companion, the generated installed-domain schema and the retained
+workflow receipts. The current software versions and signed artifacts
+are unchanged. Public historical pages are not synchronized or published
+by this local documentation task.
+
+Workflow subject index
+
+- Ask a parcel question — Daily workflow, step 4.
-The desktop package defines npm run build, npm test, npm run test:browser and its Tauri command. Python products retain their own pyproject.toml, tests and migrations; use the matching checkout’s declared dependencies and test configuration. Do not run a sample server against a production profile. This documentation build validates documentation only and reuses the separately identified installed acceptance; it does not claim a new complete application CI run.
+- Create a snapshot — Daily workflow, step 6.
+
+- Import and inspect — Daily workflow, step 2.
+
+- Prepare parcel data — Daily workflow, step 1.
+
+- Record review and context — Daily workflow, step 5.
-Recovery and support
+- Register cited rules — Daily workflow, step 3.
-Save work and use Core’s canonical Backup Now before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use Start to resume. A source export is not a full backup.
+- Use it downstream — Daily workflow, step 7.
-Use Restore Latest Backup through the supported controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not.
+- Source inventory and file hashes
+
+- All component metadata
-Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs.
+- Installed domain OpenAPI
-On failure, record the time, selected composition, component/installer versions and exact message. Check System Health for stopped, starting, ready or failed dependencies. Use the existing Retry control after readiness; do not create duplicate business records to refresh a stale view. Share only a redacted diagnostic bundle. Preserve secrets, original evidence, recovery material and unrelated installations.
+- Workflow matrix
-Prepared package installation
+- Full AGPL text
+
+Source package installation
-The renamed distributions are not yet published on a package index. Use the matching verified candidate wheel directory, not a renamed historical release URL. Installation of these Python packages is a developer/package check; the signed Windows MSI and its installed acceptance remain separate.
+Use locally built wheels from the exact component sources in the
+corresponding-source companion and verify their hashes. Do not relabel
+historical release assets. Installation of these Python packages is a
+developer/package check; the signed Windows MSI and its installed
+acceptance remain separate.
-In a new Windows virtual environment, replace the example wheel-directory path with the directory accompanying this candidate and verify its SHA256 manifest:
+In a new Windows virtual environment, replace the example
+wheel-directory path with your locally built wheel directory from the
+matching pinned source and verify its SHA256 manifest:
python -m venv .venv
.\.venv\Scripts\Activate.ps1
@@ -215,12 +774,22 @@ In a new Windows virtual environment, replace the example wheel-directory path w
python -m pip install (Join-Path $candidateWheels 'townlight_zoning-0.2.3-py3-none-any.whl')
python -c "import townlight_zoning; from importlib.metadata import version; print(version('townlight-zoning'))"
-Expected principal import: townlight_zoning; expected distribution version: 0.2.3. Use a fresh empty database/profile for workflow testing. Existing city data and the previous release remain untouched; no in-place upgrade or old-import compatibility shim is supplied.
+Expected principal import: townlight_zoning; expected distribution
+version: 0.2.3. Use a fresh empty database/profile for workflow testing.
+Existing city data and the previous release remain untouched; no
+in-place upgrade or old-import compatibility shim is supplied.
License and responsible use
-Current owned code is AGPL-3.0-only. Preserve full license, matching corresponding source, dependency notices and historical grants. Terms of use do not remove license rights. Source imports do not confer permission to publish third-party material. Review all automatic drafts and use the separate owning-product decision before official action. CivicCast remains independent.
+Current owned code is AGPL-3.0-only. Preserve full license, matching
+corresponding source, dependency notices and historical grants. Terms of
+use do not remove license rights. Source imports do not confer
+permission to publish third-party material. Review all automatic drafts
+and use the separate owning-product decision before official action.
+CivicCast remains independent.
Earlier documentation
-Previous editions are retained under docs/history/pre-townlight-beta-1/. They describe their original software and license grants. Use the current Townlight Beta 1 manual for this candidate.
+Previous editions are retained under docs/history/pre-townlight-beta-1/.
+They describe their original software and license grants. Use the
+current Townlight Beta 1 manual for this candidate.
diff --git a/SECURITY.md b/SECURITY.md
index e95c7d8..d9ddb94 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,7 +1,7 @@
# Security
-Prepared naming candidate: `townlight-zoning` 0.2.3. Installed acceptance remains pending.
+Current source package: `townlight-zoning` 0.2.3. Windows MSI 1.7.0.1 is [published](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1). Its [acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) identifies the tested workflows and limits; standalone source checks remain separate.
-Townlight Zoning Current version: 0.2.2. This is a narrow truth-repair release with no functional upgrade. The previous v1.0.0 release was published in error and does not prove public-use readiness. Deploy it only for local scaffold evaluation behind the city's trusted access layer, set `TOWNLIGHT_ZONING_STAFF_TRUSTED_PROXY_CIDRS` for the reverse proxy allowed to inject staff headers, review local parcel/rule data with planning staff, and route official zoning determinations to municipal staff.
+Townlight Zoning Current version: 0.2.3. This is a narrow truth-repair release with no functional upgrade. The previous v1.0.0 release was published in error and does not prove public-use readiness. Deploy it only for local scaffold evaluation behind the city's trusted access layer, set `TOWNLIGHT_ZONING_STAFF_TRUSTED_PROXY_CIDRS` for the reverse proxy allowed to inject staff headers, review local parcel/rule data with planning staff, and route official zoning determinations to municipal staff.
Report suspected vulnerabilities privately to the project maintainer. Do not open public issues containing exploit details, secrets, or sensitive municipal data.
diff --git a/USER-MANUAL.docx b/USER-MANUAL.docx
index 8e7b61c..24abe7e 100644
Binary files a/USER-MANUAL.docx and b/USER-MANUAL.docx differ
diff --git a/USER-MANUAL.md b/USER-MANUAL.md
index 7a6b24b..b18bf6f 100644
--- a/USER-MANUAL.md
+++ b/USER-MANUAL.md
@@ -1,28 +1,54 @@
+Windows x64 Beta 1 · MSI 1.7.0.1
+
+The signed [Windows x64 beta 1.7.0.1](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1) passed the documented fresh Windows Sandbox checks with synthetic data.
+
+- Townlight Zoning Manual
+ - Contents
+ - Using this manual
+ - Beta identity
+ - First run
+ - Daily workflow
+ - Connected workflows
+ - Architecture
+ - Discretionary processes and staff review
+ - Technical specifications
+ - Configuration and administration
+ - API and integration examples
+ - MCP and automation boundary
+ - Security and permissions
+ - Backup recovery and maintenance
+ - Troubleshooting
+ - Verified workflows and limits
+ - Terms of service and license
+ - Glossary
+ - Alphabetical subject index
+ - Source and document control
+
# Townlight Zoning Manual
**Townlight Beta 1** · Naming candidate documentation edition 2 November 2026
## Contents
-- [Using this manual](#using-this-manual)
-- [Beta identity](#beta-identity)
-- [First run](#first-run)
-- [Daily workflow](#daily-workflow)
-- [Connected workflows](#connected-workflows)
-- [Architecture](#architecture)
-- [Discretionary processes and staff review](#discretionary-processes-and-staff-review)
-- [Technical specifications](#technical-specifications)
-- [Configuration and administration](#configuration-and-administration)
-- [API and integration examples](#api-and-integration-examples)
-- [MCP and automation boundary](#mcp-and-automation-boundary)
-- [Security and permissions](#security-and-permissions)
-- [Backup recovery and maintenance](#backup-recovery-and-maintenance)
-- [Troubleshooting](#troubleshooting)
-- [Verified workflows and limits](#verified-workflows-and-limits)
-- [Terms of service and license](#terms-of-service-and-license)
-- [Glossary](#glossary)
-- [Alphabetical subject index](#alphabetical-subject-index)
-- [Source and document control](#source-and-document-control)
+- [Using this manual](https://townlight.github.io/manuals/zoning.html#using-this-manual)
+- [Beta identity](https://townlight.github.io/manuals/zoning.html#beta-identity)
+- [First run](https://townlight.github.io/manuals/zoning.html#first-run)
+- [Daily workflow](https://townlight.github.io/manuals/zoning.html#daily-workflow)
+- [Connected workflows](https://townlight.github.io/manuals/zoning.html#connected-workflows)
+- [Architecture](https://townlight.github.io/manuals/zoning.html#architecture)
+- [Discretionary processes and staff review](https://townlight.github.io/manuals/zoning.html#discretionary-processes-and-staff-review)
+- [Technical specifications](https://townlight.github.io/manuals/zoning.html#technical-specifications)
+- [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration)
+- [API and integration examples](https://townlight.github.io/manuals/zoning.html#api-and-integration-examples)
+- [MCP and automation boundary](https://townlight.github.io/manuals/zoning.html#mcp-and-automation-boundary)
+- [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions)
+- [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance)
+- [Troubleshooting](https://townlight.github.io/manuals/zoning.html#troubleshooting)
+- [Verified workflows and limits](https://townlight.github.io/manuals/zoning.html#verified-workflows-and-limits)
+- [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license)
+- [Glossary](https://townlight.github.io/manuals/zoning.html#glossary)
+- [Alphabetical subject index](https://townlight.github.io/manuals/zoning.html#alphabetical-subject-index)
+- [Source and document control](https://townlight.github.io/manuals/zoning.html#source-and-document-control)
## Using this manual
@@ -33,67 +59,67 @@ Staff should begin with First run and Daily workflow. Administrators should also
## Beta identity
| Identity | Value |
-| --- | --- |
+|----|----|
| Documentation | Townlight Beta 1 naming, Access and Notice candidate |
-| Intended installer version | 1.7.0.1; build and acceptance pending |
+| Intended installer version | 1.7.0.1 |
| Product component | townlight-zoning 0.2.3 |
| Principal import package | townlight_zoning |
| Native desktop source version | 1.7.0-1 |
-| Candidate hashes | Pending candidate build, signing and installed acceptance |
+| Candidate hashes | [SHA-256 checksums](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/SHA256SUMS-Windows-1.7.0.1.txt) and [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) |
| Current owned software license | AGPL-3.0-only |
| Acceptance composition | Fresh Windows x64 profile; inspections-preview; Station configured separately |
-The naming change advances this package's version and requires a new signed installer and installed acceptance. Those steps and publication remain pending. Historical tags, receipts and archived manuals keep their original names and certify only their identified artifacts. Use an empty database and fresh profile; no in-place legacy upgrade is supported. The approved Windows profile path remains `%LOCALAPPDATA%\CivicSuite`. Preserve existing profiles, data and recovery material.
+Use an empty database and fresh Windows profile. The installer refuses legacy profile initialization. The approved profile path is `%LOCALAPPDATA%\CivicSuite`. Keep existing profiles and backups.
## First run
-1. Obtain the identified signed private candidate and its corresponding-source companion from the beta coordinator. The landing pages in this documentation are not an installer download service.
-2. On the intended fresh Windows test installation, verify the MSI hash and publisher signature before installing. Preserve unrelated profiles and recovery material. Installed acceptance for this source candidate remains pending; no in-place legacy upgrade is supported.
-3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
-4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. **Continue without local AI** is valid for the deterministic workflows.
-5. Run Health Check and wait for readiness. Open Townlight. In System Health select **Finish Records Migration** to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
-6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
-7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
+1. Download the signed MSI, matching source companion and checksums from the [public Windows release](https://github.com/townlight/townlight/releases/tag/townlight-beta-1-windows-1.7.0.1).
+2. Verify the MSI hash and Authenticode publisher before installing on a fresh Windows profile. See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) for the tested setup.
+3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select **Townlight Inspections candidate** (`inspections-preview`) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
+4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. **Continue without local AI** is valid for the deterministic workflows.
+5. Run Health Check and wait for readiness. Open Townlight. In System Health select **Finish Records Migration** to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
+6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
+7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
## Daily workflow
-
+
### 1. Prepare parcel data
Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
-
+
### 2. Import and inspect
Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
-
+
### 3. Register cited rules
Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
-
+
### 4. Ask a parcel question
Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.
-
+
### 5. Record review and context
Record a correction and its reason when needed. Select permitted Meetings history explicitly. Preserve the question/review history and distinguish staff-only precedent from public material.
-
+
### 6. Create a snapshot
Review the audience and exact content before creating the immutable snapshot. A public snapshot must satisfy its permitted-source contract; choosing a public label does not sanitize private notes.
-
+
### 7. Use it downstream
@@ -113,20 +139,21 @@ Drafting, review, approval, attachment, export, fulfillment and publication are
Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.
-
| Direction | Material |
-| --- | --- |
+|----|----|
| Input | A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence. |
| Output | Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes. |
-
### Product boundary
The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.
## Architecture
-
+
+
+Townlight Zoning architecture and evidence flow
+
The drawing shows the principal staff/evidence path. Native commands carry trusted identity to Python business services; PostgreSQL and retained original files hold durable state. A downstream copy does not silently transfer decision authority. Station has its own configured authority/media boundary, database and mutable files. The connected-workflow text supplies the drawing’s reading order and accessibility alternative.
@@ -138,7 +165,7 @@ In the existing Zoning workspace, complete **Variance, conditional use or noncon
The mounted API is `POST /desktop/v1/zoning/standards/process-explanation` under the normal authenticated staff session. Its equivalent request body is:
-```json
+``` json
{"question":"Explain the synthetic variance process","process_section":"18.20.050","zone_code":"SYN-R","rule_types":["front_setback"],"observed":{"front_setback":"8 feet"}}
```
@@ -150,7 +177,7 @@ Check the complete JSON envelope, original hashes and EPSG:4326 geometry before
### Use the existing specialist review contracts
-The standalone Zoning application's review/analytics/report routes are documented source capabilities, not extra native desktop screens. In a deployment where its actual staff authentication is already configured:
+The standalone Zoning application’s review/analytics/report routes are documented source capabilities, not extra native desktop screens. In a deployment where its actual staff authentication is already configured:
- Create an ambiguity review with `zone_code`, `question` and `reason` at `/api/v1/townlight_zoning/staff/ambiguity-reviews`. Read its returned ID and list state. Update that ID with `status`, optional `assigned_to` and `resolution`; use `open`, `in_review`, `resolved` or `closed`. Resolving or closing requires a nonempty `resolution`.
- Retain a flagged answer at `/api/v1/townlight_zoning/staff/flagged-answers` with the original question/answer, zone, flag reason and source citations. Use `/{review_id}/improve` with `improved_answer` and `improvement_notes`. Preserve the original and improvement attribution; a correction does not rewrite the imported Code source.
@@ -159,16 +186,16 @@ The standalone Zoning application's review/analytics/report routes are documente
A synthetic ambiguity request is:
-```json
+``` json
{"zone_code":"SYN-R","question":"Which retained setback rule applies?","reason":"Synthetic overlay ambiguity requires planner review"}
```
-Do not send invented staff-role headers or assume these standalone paths exist at the installed desktop origin. The native workspace's supported review/history/snapshot controls continue to use its fixed authenticated bridge. Use the technical supplement to distinguish the two surfaces.
+Do not send invented staff-role headers or assume these standalone paths exist at the installed desktop origin. The native workspace’s supported review/history/snapshot controls continue to use its fixed authenticated bridge. Use the technical supplement to distinguish the two surfaces.
Source contracts: `townlight_runtime/zoning_bridge.py`, `townlight_zoning/main.py`, the imported rule/source models and desktop Zoning view.
-
## Technical specifications
+
### Runtime and storage
The accepted package targets **Windows x64 fresh installation**. Its native shell uses **Rust 2021, Tauri 2 and Microsoft WebView2**; browser assets are JavaScript built with **Vite 8.1.6**. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled **CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic**, with **PostgreSQL 17 / PostGIS** and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label.
@@ -185,11 +212,12 @@ Versioned saves use expected prior revision identifiers where defined. Reopen an
### Capacity and platform statements
-This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The new installer size remains pending its build; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
+This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The signed MSI is 2,082,697,216 bytes; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
-The exact [runtime payload lock](docs/beta-1/reference/runtime-payload-lock.json) records pinned files, sizes and hashes. The [component metadata](docs/beta-1/reference/component-metadata.json) records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
+The exact [runtime payload lock](https://townlight.github.io/reference/runtime-payload-lock.json) records pinned files, sizes and hashes. The [component metadata](https://townlight.github.io/reference/component-metadata.json) records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
## Configuration and administration
+
### Native deployment configuration
Use Setup, Settings and System Health for supported staff operation. Administrators provision folders, backup storage, named accounts and the city profile. Select `inspections-preview` for the bounded desktop composition, including Access and Notice. Station remains a separate service boundary. Do not use a standalone product’s demo server as a substitute for the installed workspace.
@@ -199,11 +227,12 @@ Technical deployments use `TOWNLIGHT_PRODUCT_PROFILE`, `TOWNLIGHT_PROFILE_ROOT`,
The isolated documentation exporter sets a fictional profile and unusable synthetic database origin only to read schemas; those values are not deployment configuration. Keep deployment values in the intended process/account scope. An already-running process does not automatically inherit later environment edits.
## API and integration examples
+
### Native command example
The following JavaScript belongs in the existing trusted Townlight frontend/development environment with `invoke` imported from `@tauri-apps/api/core`. It is not a command for an arbitrary web page or an instruction for nontechnical staff. IDs must come from records created in an isolated synthetic exercise.
-```javascript
+``` javascript
import { invoke } from '@tauri-apps/api/core';
const result = await invoke('zoning_domain_request', {request: {operation: 'history', id: questionId}});
console.log(result);
@@ -213,7 +242,7 @@ console.log(result);
An administrator/developer can inspect an already-configured isolated runtime from a trusted local process. This PowerShell example reads the signed-in synthetic profile’s existing proof into memory; it does not create a user, seed a session, reveal the proof in output or bypass a permission check. Do not use real city data in development examples. A read response does not prove approval or publication.
-```powershell
+``` powershell
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config\local-session.json'
$session = Get-Content -LiteralPath $sessionPath -Raw | ConvertFrom-Json
@@ -224,13 +253,13 @@ Remove-Variable session, headers
### Complete synthetic source bundle
-The [synthetic Zoning bundle](docs/beta-1/reference/examples/synthetic-geo-bundle.json) is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as `{"bundle": BUNDLE, "expected_previous_revision": null}`; for Permitting use `{"bundle": BUNDLE, "expected_revision": null}`. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
+The [synthetic Zoning bundle](https://townlight.github.io/reference/examples/synthetic-geo-bundle.json) is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as `{"bundle": BUNDLE, "expected_previous_revision": null}`; for Permitting use `{"bundle": BUNDLE, "expected_revision": null}`. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
### A synthetic write with subsequent readback
This example demonstrates the existing Meetings HTTP contract in an isolated exercise. It is intentionally fictional. It does not start a service. Its authentication setup is included so it can be run independently under the signed-in synthetic account. If a write times out, inspect current records before repeating it.
-```powershell
+``` powershell
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config/local-session.json'
$session = Get-Content -LiteralPath $sessionPath -Raw | ConvertFrom-Json
@@ -254,7 +283,7 @@ This write requires Meetings to be enabled and the signed-in staff role to permi
### Complete technical contract
-Read the [Zoning API reference](docs/beta-1/api/zoning.html) for every documented operation, request field, constraint, response declaration and source supplement. Download the [OpenAPI JSON](docs/beta-1/api/zoning-openapi.json) for tools. For Station this is the suite-side schema only; its separate service contract is documented in the API supplement. The [reference directory](docs/beta-1/reference/index.html) includes configuration/source inventories, dependency declarations, native command contracts, MCP signatures and candidate evidence.
+Read the [Zoning API reference](https://townlight.github.io/api/zoning.html) for every documented operation, request field, constraint, response declaration and source supplement. Download the [OpenAPI JSON](https://townlight.github.io/api/zoning-openapi.json) for tools. For Station this is the suite-side schema only; its separate service contract is documented in the API supplement. The [reference directory](https://townlight.github.io/reference/index.html) includes configuration/source inventories, dependency declarations, native command contracts, MCP signatures and candidate evidence.
## MCP and automation boundary
@@ -264,15 +293,14 @@ The bundled transcription code includes a **TextFlowKit MCP adapter** as a separ
For a transcription client already provisioned separately, an illustrative tool call is:
-```json
+``` json
{"name":"get_job_status","arguments":{"job_id":"synthetic-existing-job-id"}}
```
-Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the [MCP source reference](docs/beta-1/reference/mcp.html). Station meeting capture does not become live speech recognition because this optional donor adapter exists.
+Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the [MCP source reference](https://townlight.github.io/reference/mcp.html). Station meeting capture does not become live speech recognition because this optional donor adapter exists.
## Security and permissions
-
Use your own named account and save before leaving a screen. A saved draft is durable; unsaved form text may not be. If a write has an unknown result, reopen its record before repeating it.
Read source jurisdiction, dates, citation, version and visibility. A copied source hash identifies exact bytes, not their legal applicability. If a source changes or permission is removed, resolve the source problem rather than substituting stale cached content.
@@ -298,7 +326,7 @@ On failure, record the time, selected composition, component/installer versions
## Troubleshooting
| Symptom | Likely meaning | Next action |
-| --- | --- | --- |
+|----|----|----|
| Workspace absent | Wrong product composition or unavailable canonical runtime. | Check selected composition; activate through Finish Records Migration; wait for readiness. |
| Cannot sign in / 401 | Missing or expired named account session. | Sign in normally; reopen a Station launch ticket if applicable. |
| Permission denied / 403 | Account, module, source or browser-origin permission. | Ask the authorized administrator to inspect the intended permission; do not invent role headers. |
@@ -308,17 +336,15 @@ On failure, record the time, selected composition, component/installer versions
| Export refused | Missing exact review, approval, audience or source authorization. | Read the refusal and complete the owning product’s explicit decision. |
| Restore needs service start | The snapshot was restored but services have not resumed. | Use Start, then Check and verify a saved record; do not blindly repeat restore. |
-
## Verified workflows and limits
| Product | Recorded result | Precisely exercised |
-| --- | --- | --- |
+|----|----|----|
| Zoning | PASS | GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace. |
-
These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run.
-The [workflow matrix](docs/beta-1/reference/workflow-matrix.json) identifies raw receipt filenames. The [evidence index](docs/beta-1/reference/sandbox-evidence-index.json) retains their original hashes; raw receipts remain in the private beta handoff rather than being silently republished with the documentation site.
+See the [Windows acceptance summary](https://github.com/townlight/townlight/releases/download/townlight-beta-1-windows-1.7.0.1/ACCEPTANCE-Windows-1.7.0.1.md) for this MSI. The historical [evidence index](https://townlight.github.io/reference/sandbox-evidence-index.json) applies to its original build.
The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim.
@@ -326,7 +352,7 @@ The limits remain: actual city field acceptance and equipment/network commission
### Scope and status
-These terms describe the Townlight Beta 1 software and this documentation package. This is a locally prepared private beta, not a hosted-service subscription, a city deployment agreement or a public release. No uptime commitment, support response time, indemnity, data-processing agreement or paid service is created by these documents. A separate signed agreement, if any, governs services it actually provides.
+These terms describe the Townlight Beta 1 software and this documentation package. This public Windows beta is for evaluation. No uptime commitment, support response time, indemnity, data-processing agreement or paid service is created by these documents. A separate signed agreement, if any, governs services it actually provides.
### Software license and rights
@@ -365,7 +391,7 @@ When an organization ends testing, it controls retention/export and removes acce
## Glossary
| Term | Meaning |
-| --- | --- |
+|----|----|
| Approval | An explicit authorized decision on the saved text/artifact. It is separate from saving or attachment. |
| Canonical record | The owning product’s retained identity and saved version, rather than an editable copied label. |
| Composition | The selected set of desktop modules; inspections-preview exposes the eight staff products. |
@@ -381,34 +407,33 @@ When an organization ends testing, it controls retention/export and removes acce
| Snapshot | A fixed audience-specific copy tied to a source/reviewed revision. |
| Station | Townlight’s separate media boundary using a pinned CivicCast-derived engine; standalone CivicCast remains separate. |
-
## Alphabetical subject index
-- **Accounts and authentication** — [Security and permissions](#security-and-permissions).
-- **AGPL and source** — [Terms of service and license](#terms-of-service-and-license).
-- **API contracts** — [API and integration examples](#api-and-integration-examples).
-- **Architecture** — [Architecture](#architecture).
-- **Backup** — [Backup recovery and maintenance](#backup-recovery-and-maintenance).
-- **Beta version** — [Beta identity](#beta-identity).
-- **Configuration** — [Configuration and administration](#configuration-and-administration).
-- **Evidence and acceptance** — [Verified workflows and limits](#verified-workflows-and-limits).
-- **Fees and official decisions** — [Terms of service and license](#terms-of-service-and-license).
-- **First run** — [First run](#first-run).
-- **Handoffs and audience** — [Connected workflows](#connected-workflows).
-- **MCP** — [MCP and automation boundary](#mcp-and-automation-boundary).
-- **Originals and provenance** — [Security and permissions](#security-and-permissions).
-- **Recovery** — [Backup recovery and maintenance](#backup-recovery-and-maintenance).
-- **Staff procedures** — [Daily workflow](#daily-workflow).
-- **Station configuration** — [Configuration and administration](#configuration-and-administration).
-- **Technical stack** — [Technical specifications](#technical-specifications).
-- **Troubleshooting** — [Troubleshooting](#troubleshooting).
+- **Accounts and authentication** — [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions).
+- **AGPL and source** — [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license).
+- **API contracts** — [API and integration examples](https://townlight.github.io/manuals/zoning.html#api-and-integration-examples).
+- **Architecture** — [Architecture](https://townlight.github.io/manuals/zoning.html#architecture).
+- **Backup** — [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance).
+- **Beta version** — [Beta identity](https://townlight.github.io/manuals/zoning.html#beta-identity).
+- **Configuration** — [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration).
+- **Evidence and acceptance** — [Verified workflows and limits](https://townlight.github.io/manuals/zoning.html#verified-workflows-and-limits).
+- **Fees and official decisions** — [Terms of service and license](https://townlight.github.io/manuals/zoning.html#terms-of-service-and-license).
+- **First run** — [First run](https://townlight.github.io/manuals/zoning.html#first-run).
+- **Handoffs and audience** — [Connected workflows](https://townlight.github.io/manuals/zoning.html#connected-workflows).
+- **MCP** — [MCP and automation boundary](https://townlight.github.io/manuals/zoning.html#mcp-and-automation-boundary).
+- **Originals and provenance** — [Security and permissions](https://townlight.github.io/manuals/zoning.html#security-and-permissions).
+- **Recovery** — [Backup recovery and maintenance](https://townlight.github.io/manuals/zoning.html#backup-recovery-and-maintenance).
+- **Staff procedures** — [Daily workflow](https://townlight.github.io/manuals/zoning.html#daily-workflow).
+- **Station configuration** — [Configuration and administration](https://townlight.github.io/manuals/zoning.html#configuration-and-administration).
+- **Technical stack** — [Technical specifications](https://townlight.github.io/manuals/zoning.html#technical-specifications).
+- **Troubleshooting** — [Troubleshooting](https://townlight.github.io/manuals/zoning.html#troubleshooting).
### Operating subject links
-- **Discretionary processes and staff review** — [Discretionary processes and staff review](#discretionary-processes-and-staff-review).
-- **Explain the cited process** — [Explain the cited process](#explain-the-cited-process).
-- **Keep parcel import and inspection in the right order** — [Keep parcel import and inspection in the right order](#keep-parcel-import-and-inspection-in-the-right-order).
-- **Use the existing specialist review contracts** — [Use the existing specialist review contracts](#use-the-existing-specialist-review-contracts).
+- **Discretionary processes and staff review** — [Discretionary processes and staff review](https://townlight.github.io/manuals/zoning.html#discretionary-processes-and-staff-review).
+- **Explain the cited process** — [Explain the cited process](https://townlight.github.io/manuals/zoning.html#explain-the-cited-process).
+- **Keep parcel import and inspection in the right order** — [Keep parcel import and inspection in the right order](https://townlight.github.io/manuals/zoning.html#keep-parcel-import-and-inspection-in-the-right-order).
+- **Use the existing specialist review contracts** — [Use the existing specialist review contracts](https://townlight.github.io/manuals/zoning.html#use-the-existing-specialist-review-contracts).
## Source and document control
@@ -416,16 +441,26 @@ This edition is authored from the immutable corresponding-source companion, the
### Workflow subject index
-- **Ask a parcel question** — [Daily workflow, step 4](#workflow-4).
-- **Create a snapshot** — [Daily workflow, step 6](#workflow-6).
-- **Import and inspect** — [Daily workflow, step 2](#workflow-2).
-- **Prepare parcel data** — [Daily workflow, step 1](#workflow-1).
-- **Record review and context** — [Daily workflow, step 5](#workflow-5).
-- **Register cited rules** — [Daily workflow, step 3](#workflow-3).
-- **Use it downstream** — [Daily workflow, step 7](#workflow-7).
-
-- [Source inventory and file hashes](docs/beta-1/reference/source-inventory.json)
-- [All component metadata](docs/beta-1/reference/component-metadata.json)
-- [Installed domain OpenAPI](docs/beta-1/reference/desktop-domain-openapi.json)
-- [Workflow matrix](docs/beta-1/reference/workflow-matrix.json)
-- [Full AGPL text](docs/beta-1/reference/AGPL-3.0.txt)
+- **Ask a parcel question** — [Daily workflow, step 4](https://townlight.github.io/manuals/zoning.html#workflow-4).
+
+- **Create a snapshot** — [Daily workflow, step 6](https://townlight.github.io/manuals/zoning.html#workflow-6).
+
+- **Import and inspect** — [Daily workflow, step 2](https://townlight.github.io/manuals/zoning.html#workflow-2).
+
+- **Prepare parcel data** — [Daily workflow, step 1](https://townlight.github.io/manuals/zoning.html#workflow-1).
+
+- **Record review and context** — [Daily workflow, step 5](https://townlight.github.io/manuals/zoning.html#workflow-5).
+
+- **Register cited rules** — [Daily workflow, step 3](https://townlight.github.io/manuals/zoning.html#workflow-3).
+
+- **Use it downstream** — [Daily workflow, step 7](https://townlight.github.io/manuals/zoning.html#workflow-7).
+
+- [Source inventory and file hashes](https://townlight.github.io/reference/source-inventory.json)
+
+- [All component metadata](https://townlight.github.io/reference/component-metadata.json)
+
+- [Installed domain OpenAPI](https://townlight.github.io/reference/desktop-domain-openapi.json)
+
+- [Workflow matrix](https://townlight.github.io/reference/workflow-matrix.json)
+
+- [Full AGPL text](https://townlight.github.io/reference/AGPL-3.0.txt)
diff --git a/USER-MANUAL.pdf b/USER-MANUAL.pdf
index 976f000..15371e5 100644
Binary files a/USER-MANUAL.pdf and b/USER-MANUAL.pdf differ
diff --git a/USER-MANUAL.txt b/USER-MANUAL.txt
index f1a96f1..1cda087 100644
--- a/USER-MANUAL.txt
+++ b/USER-MANUAL.txt
@@ -1,6 +1,34 @@
+Windows x64 Beta 1 · MSI 1.7.0.1
+
+The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows
+Sandbox checks with synthetic data.
+
+- Townlight Zoning Manual
+ - Contents
+ - Using this manual
+ - Beta identity
+ - First run
+ - Daily workflow
+ - Connected workflows
+ - Architecture
+ - Discretionary processes and staff review
+ - Technical specifications
+ - Configuration and administration
+ - API and integration examples
+ - MCP and automation boundary
+ - Security and permissions
+ - Backup recovery and maintenance
+ - Troubleshooting
+ - Verified workflows and limits
+ - Terms of service and license
+ - Glossary
+ - Alphabetical subject index
+ - Source and document control
+
Townlight Zoning Manual
-Townlight Beta 1 · Naming candidate documentation edition 2 November 2026
+Townlight Beta 1 · Naming candidate documentation edition 2 November
+2026
Contents
@@ -26,176 +54,326 @@ Contents
Using this manual
-Townlight Zoning helps planners, land-use staff and authorized reviewers. Zoning combines local parcel geometry, cited zoning rules and staff review. It retains questions, corrections and snapshots with provenance so downstream staff can identify the precise evidence used.
+Townlight Zoning helps planners, land-use staff and authorized
+reviewers. Zoning combines local parcel geometry, cited zoning rules and
+staff review. It retains questions, corrections and snapshots with
+provenance so downstream staff can identify the precise evidence used.
-Staff should begin with First run and Daily workflow. Administrators should also read Architecture, Technical specifications, Configuration, Security and Recovery. Developers should use the exact API/data dictionary and examples. The table of contents and alphabetical subject index link to the relevant sections in the HTML edition; the PDF preserves headings and searchable text. An editable Word edition is included with the same documentation companion.
+Staff should begin with First run and Daily workflow. Administrators
+should also read Architecture, Technical specifications, Configuration,
+Security and Recovery. Developers should use the exact API/data
+dictionary and examples. The table of contents and alphabetical subject
+index link to the relevant sections in the HTML edition; the PDF
+preserves headings and searchable text. An editable Word edition is
+included with the same documentation companion.
Beta identity
- -------------------------------------------------------------------------------------------------------------------
- Identity Value
- ----------------------------------- -------------------------------------------------------------------------------
- Documentation Townlight Beta 1 naming, Access and Notice candidate
-
- Intended installer version 1.7.0.1; build and acceptance pending
-
- Product component townlight-zoning 0.2.3
-
- Principal import package townlight_zoning
-
- Native desktop source version 1.7.0-1
-
- Candidate hashes Pending candidate build, signing and installed acceptance
-
- Current owned software license AGPL-3.0-only
-
- Acceptance composition Fresh Windows x64 profile; inspections-preview; Station configured separately
- -------------------------------------------------------------------------------------------------------------------
-
-The naming change advances this package’s version and requires a new signed installer and installed acceptance. Those steps and publication remain pending. Historical tags, receipts and archived manuals keep their original names and certify only their identified artifacts. Use an empty database and fresh profile; no in-place legacy upgrade is supported. The approved Windows profile path remains %LOCALAPPDATA%\CivicSuite. Preserve existing profiles, data and recovery material.
+ Identity Value
+ -------------------------------- -------------------------------------------------------------------------------
+ Documentation Townlight Beta 1 naming, Access and Notice candidate
+ Intended installer version 1.7.0.1
+ Product component townlight-zoning 0.2.3
+ Principal import package townlight_zoning
+ Native desktop source version 1.7.0-1
+ Candidate hashes SHA-256 checksums and Windows acceptance summary
+ Current owned software license AGPL-3.0-only
+ Acceptance composition Fresh Windows x64 profile; inspections-preview; Station configured separately
+
+Use an empty database and fresh Windows profile. The installer refuses
+legacy profile initialization. The approved profile path is
+%LOCALAPPDATA%\CivicSuite. Keep existing profiles and backups.
First run
-1. Obtain the identified signed private candidate and its corresponding-source companion from the beta coordinator. The landing pages in this documentation are not an installer download service.
-2. On the intended fresh Windows test installation, verify the MSI hash and publisher signature before installing. Preserve unrelated profiles and recovery material. Installed acceptance for this source candidate remains pending; no in-place legacy upgrade is supported.
-3. Launch Townlight under the intended named Windows account. Choose the storage folders. Select Townlight Inspections candidate (inspections-preview) for the bounded desktop composition, including Access and Notice. A narrower default selection will not expose all workspaces.
-4. Enter the city profile, time zone and contacts. Create the first named local administrator, sign in and choose protected backup storage. Continue without local AI is valid for the deterministic workflows.
-5. Run Health Check and wait for readiness. Open Townlight. In System Health select Finish Records Migration to activate the canonical Python/PostgreSQL runtime. Do not fabricate migration receipts or seed accounts.
-6. Create named staff through Settings. Import authorized sources using each product’s source library. All examples in this package are synthetic; they are not municipal authority.
-7. Provision Station separately if it is part of the beta exercise. Selecting the desktop composition does not start or configure Station. Configure vision explicitly only if automatic photo drafting is selected.
+1. Download the signed MSI, matching source companion and checksums
+ from the public Windows release.
+2. Verify the MSI hash and Authenticode publisher before installing on
+ a fresh Windows profile. See the Windows acceptance summary for the
+ tested setup.
+3. Launch Townlight under the intended named Windows account. Choose
+ the storage folders. Select Townlight Inspections candidate
+ (inspections-preview) for the bounded desktop composition, including
+ Access and Notice. A narrower default selection will not expose all
+ workspaces.
+4. Enter the city profile, time zone and contacts. Create the first
+ named local administrator, sign in and choose protected backup
+ storage. Continue without local AI is valid for the deterministic
+ workflows.
+5. Run Health Check and wait for readiness. Open Townlight. In System
+ Health select Finish Records Migration to activate the canonical
+ Python/PostgreSQL runtime. Do not fabricate migration receipts or
+ seed accounts.
+6. Create named staff through Settings. Import authorized sources using
+ each product’s source library. All examples in this package are
+ synthetic; they are not municipal authority.
+7. Provision Station separately if it is part of the beta exercise.
+ Selecting the desktop composition does not start or configure
+ Station. Configure vision explicitly only if automatic photo
+ drafting is selected.
Daily workflow
1. Prepare parcel data
-Use the complete supported bundle, including jurisdiction, dataset metadata and original hashes. The coordinates must be EPSG:4326. A loose geometry file is not the full source envelope.
+Use the complete supported bundle, including jurisdiction, dataset
+metadata and original hashes. The coordinates must be EPSG:4326. A loose
+geometry file is not the full source envelope.
2. Import and inspect
-Check the complete source envelope before selecting Import parcel dataset. That control submits directly; inspect the saved validation/provenance result afterward. Correct a refused source bundle and preserve the evidence. Do not force acceptance by editing SQL.
+Check the complete source envelope before selecting Import parcel
+dataset. That control submits directly; inspect the saved
+validation/provenance result afterward. Correct a refused source bundle
+and preserve the evidence. Do not force acceptance by editing SQL.
3. Register cited rules
-Associate the zone, rule kind/key and value with the relevant public Code section. Inspect overlays and effective context. Leave missing authority visible for planner review.
+Associate the zone, rule kind/key and value with the relevant public
+Code section. Inspect overlays and effective context. Leave missing
+authority visible for planner review.
4. Ask a parcel question
-Look up the intended parcel and ask the supported question. Read the returned citation, applicability and disclaimer. Do not present an uncertain answer as an official decision.
+Look up the intended parcel and ask the supported question. Read the
+returned citation, applicability and disclaimer. Do not present an
+uncertain answer as an official decision.
5. Record review and context
-Record a correction and its reason when needed. Select permitted Meetings history explicitly. Preserve the question/review history and distinguish staff-only precedent from public material.
+Record a correction and its reason when needed. Select permitted
+Meetings history explicitly. Preserve the question/review history and
+distinguish staff-only precedent from public material.
6. Create a snapshot
-Review the audience and exact content before creating the immutable snapshot. A public snapshot must satisfy its permitted-source contract; choosing a public label does not sanitize private notes.
+Review the audience and exact content before creating the immutable
+snapshot. A public snapshot must satisfy its permitted-source contract;
+choosing a public label does not sanitize private notes.
7. Use it downstream
-Select the exact snapshot for Records or the permitted provider path. The receiving workflow rechecks visibility, source identity and hash before retaining or exporting it.
+Select the exact snapshot for Records or the permitted provider path.
+The receiving workflow rechecks visibility, source identity and hash
+before retaining or exporting it.
Working safely
-Use your own named account and save before leaving a screen. A saved draft is durable; unsaved form text may not be. If a write has an unknown result, reopen its record before repeating it.
+Use your own named account and save before leaving a screen. A saved
+draft is durable; unsaved form text may not be. If a write has an
+unknown result, reopen its record before repeating it.
-Read source jurisdiction, dates, citation, version and visibility. A copied source hash identifies exact bytes, not their legal applicability. If a source changes or permission is removed, resolve the source problem rather than substituting stale cached content.
+Read source jurisdiction, dates, citation, version and visibility. A
+copied source hash identifies exact bytes, not their legal
+applicability. If a source changes or permission is removed, resolve the
+source problem rather than substituting stale cached content.
-Keep originals and derivatives separate. Review the intended audience before export. A public summary excludes private fields only through the applicable copy contract and your review. A renamed private packet is still private content.
+Keep originals and derivatives separate. Review the intended audience
+before export. A public summary excludes private fields only through the
+applicable copy contract and your review. A renamed private packet is
+still private content.
-Drafting, review, approval, attachment, export, fulfillment and publication are separate operations. A Townlight workpaper does not itself adopt law, issue a permit, impose a fine or release a records response. The responsible staff member records the applicable decision.
+Drafting, review, approval, attachment, export, fulfillment and
+publication are separate operations. A Townlight workpaper does not
+itself adopt law, issue a permit, impose a fine or release a records
+response. The responsible staff member records the applicable decision.
Connected workflows
-Consumes Code authority and permitted Meetings evidence. Supplies permitted snapshots to Records and context to Planning and Permitting.
-
- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Direction Material
- ----------------------------------- ----------------------------------------------------------------------------------------------------------------------------------
- Input A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence.
+Consumes Code authority and permitted Meetings evidence. Supplies
+permitted snapshots to Records and context to Planning and Permitting.
- Output Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes.
- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
+ Direction Material
+ ----------- ----------------------------------------------------------------------------------------------------------------------------------
+ Input A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset metadata, public Code authority and permitted meeting evidence.
+ Output Source-backed parcel context, informational answers, recorded human corrections and reviewed snapshots with stable hashes.
Product boundary
-The accepted path is local GeoJSON/PostGIS. It does not establish every ArcGIS, assessor or CKAN connector. Answers and process explanations are informational and do not issue an entitlement or an official zoning determination.
+The accepted path is local GeoJSON/PostGIS. It does not establish every
+ArcGIS, assessor or CKAN connector. Answers and process explanations are
+informational and do not issue an entitlement or an official zoning
+determination.
Architecture
-[Townlight Zoning architecture and evidence flow]
-
-The drawing shows the principal staff/evidence path. Native commands carry trusted identity to Python business services; PostgreSQL and retained original files hold durable state. A downstream copy does not silently transfer decision authority. Station has its own configured authority/media boundary, database and mutable files. The connected-workflow text supplies the drawing’s reading order and accessibility alternative.
+The drawing shows the principal staff/evidence path. Native commands
+carry trusted identity to Python business services; PostgreSQL and
+retained original files hold durable state. A downstream copy does not
+silently transfer decision authority. Station has its own configured
+authority/media boundary, database and mutable files. The
+connected-workflow text supplies the drawing’s reading order and
+accessibility alternative.
Discretionary processes and staff review
Explain the cited process
-In the existing Zoning workspace, complete Variance, conditional use or nonconformity question. Supply the applicable process Code section, zone code, optional comma-separated standard to cite, and optional observed condition, for example front_setback=8 feet. Select Explain the cited process. Choose actual imported public authority; the synthetic values below require matching synthetic sources to return supported guidance.
+In the existing Zoning workspace, complete Variance, conditional use or
+nonconformity question. Supply the applicable process Code section, zone
+code, optional comma-separated standard to cite, and optional observed
+condition, for example front_setback=8 feet. Select Explain the cited
+process. Choose actual imported public authority; the synthetic values
+below require matching synthetic sources to return supported guidance.
-The mounted API is POST /desktop/v1/zoning/standards/process-explanation under the normal authenticated staff session. Its equivalent request body is:
+The mounted API is POST /desktop/v1/zoning/standards/process-explanation
+under the normal authenticated staff session. Its equivalent request
+body is:
{"question":"Explain the synthetic variance process","process_section":"18.20.050","zone_code":"SYN-R","rule_types":["front_setback"],"observed":{"front_setback":"8 feet"}}
-Read process citations and each cited standard independently. The output can explain a verified process while reporting unavailable standards or review flags. A difference between an observation and a cited standard is an informational flag; it is not a variance finding, approval, nonconformity determination or substitute for planner review. If no relevant authority is available, obtain the source or leave the item unavailable. Do not attach an unrelated citation to a proposed requirement.
+Read process citations and each cited standard independently. The output
+can explain a verified process while reporting unavailable standards or
+review flags. A difference between an observation and a cited standard
+is an informational flag; it is not a variance finding, approval,
+nonconformity determination or substitute for planner review. If no
+relevant authority is available, obtain the source or leave the item
+unavailable. Do not attach an unrelated citation to a proposed
+requirement.
Keep parcel import and inspection in the right order
-Check the complete JSON envelope, original hashes and EPSG:4326 geometry before submitting Import parcel dataset. That control sends the import directly; it does not open a separate preview/commit screen. Inspect the returned validation/provenance and saved dataset. The browser refuses bundle files larger than 20 MiB; valid geometry and metadata remain subject to server validation. Correct the source bundle after a refusal and retain earlier evidence rather than forcing SQL changes.
+Check the complete JSON envelope, original hashes and EPSG:4326 geometry
+before submitting Import parcel dataset. That control sends the import
+directly; it does not open a separate preview/commit screen. Inspect the
+returned validation/provenance and saved dataset. The browser refuses
+bundle files larger than 20 MiB; valid geometry and metadata remain
+subject to server validation. Correct the source bundle after a refusal
+and retain earlier evidence rather than forcing SQL changes.
Use the existing specialist review contracts
-The standalone Zoning application’s review/analytics/report routes are documented source capabilities, not extra native desktop screens. In a deployment where its actual staff authentication is already configured:
-
-- Create an ambiguity review with zone_code, question and reason at /api/v1/townlight_zoning/staff/ambiguity-reviews. Read its returned ID and list state. Update that ID with status, optional assigned_to and resolution; use open, in_review, resolved or closed. Resolving or closing requires a nonempty resolution.
-- Retain a flagged answer at /api/v1/townlight_zoning/staff/flagged-answers with the original question/answer, zone, flag reason and source citations. Use /{review_id}/improve with improved_answer and improvement_notes. Preserve the original and improvement attribution; a correction does not rewrite the imported Code source.
-- Read /api/v1/townlight_zoning/staff/questions/analytics with the desired high_volume_threshold to identify repeated questions and uncertain answers. Analytics counts are review aids, not jurisdictional conclusions.
-- Create /api/v1/townlight_zoning/staff/reports/outline with a title and actual selected question_ids/queue_item_ids. Review the resulting outline and citations before incorporating it in a staff report. It is not a filed report or a meeting decision.
+The standalone Zoning application’s review/analytics/report routes are
+documented source capabilities, not extra native desktop screens. In a
+deployment where its actual staff authentication is already configured:
+
+- Create an ambiguity review with zone_code, question and reason at
+ /api/v1/townlight_zoning/staff/ambiguity-reviews. Read its returned ID
+ and list state. Update that ID with status, optional assigned_to and
+ resolution; use open, in_review, resolved or closed. Resolving or
+ closing requires a nonempty resolution.
+- Retain a flagged answer at
+ /api/v1/townlight_zoning/staff/flagged-answers with the original
+ question/answer, zone, flag reason and source citations. Use
+ /{review_id}/improve with improved_answer and improvement_notes.
+ Preserve the original and improvement attribution; a correction does
+ not rewrite the imported Code source.
+- Read /api/v1/townlight_zoning/staff/questions/analytics with the
+ desired high_volume_threshold to identify repeated questions and
+ uncertain answers. Analytics counts are review aids, not
+ jurisdictional conclusions.
+- Create /api/v1/townlight_zoning/staff/reports/outline with a title and
+ actual selected question_ids/queue_item_ids. Review the resulting
+ outline and citations before incorporating it in a staff report. It is
+ not a filed report or a meeting decision.
A synthetic ambiguity request is:
{"zone_code":"SYN-R","question":"Which retained setback rule applies?","reason":"Synthetic overlay ambiguity requires planner review"}
-Do not send invented staff-role headers or assume these standalone paths exist at the installed desktop origin. The native workspace’s supported review/history/snapshot controls continue to use its fixed authenticated bridge. Use the technical supplement to distinguish the two surfaces.
+Do not send invented staff-role headers or assume these standalone paths
+exist at the installed desktop origin. The native workspace’s supported
+review/history/snapshot controls continue to use its fixed authenticated
+bridge. Use the technical supplement to distinguish the two surfaces.
-Source contracts: townlight_runtime/zoning_bridge.py, townlight_zoning/main.py, the imported rule/source models and desktop Zoning view.
+Source contracts: townlight_runtime/zoning_bridge.py,
+townlight_zoning/main.py, the imported rule/source models and desktop
+Zoning view.
Technical specifications
Runtime and storage
-The accepted package targets Windows x64 fresh installation. Its native shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are JavaScript built with Vite 8.1.6. This describes the native desktop frontend; Station has a separate React operator, specified below or in its product manual. Canonical business workflows use bundled CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 / PostGIS and managed original files. The installed runtime tested here contains FastAPI 0.162.0. Package minimum Python requirements can differ from the bundled executable; the metadata reference preserves both. No stack rewrite is implied by the beta label.
-
-The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL uses the configured local runtime port (default 15432). Optional local model service defaults to 127.0.0.1:15434. Those are deployment defaults, not internet endpoints. The runtime has health, module and readiness endpoints; readiness is stronger than process existence. The task queue is the existing local Core task infrastructure, not an assertion that a separate Redis service is required for this desktop composition.
-
-The default native profile is %LOCALAPPDATA%\CivicSuite; the historical directory name remains part of compatibility. Do not rename it to Townlight. A configured TOWNLIGHT_PROFILE_ROOT must be absolute. Local configuration and secrets live under that profile; protected managed files and database state must be backed up coherently. Source/runtime identity is distinct from a product’s display label.
+The accepted package targets Windows x64 fresh installation. Its native
+shell uses Rust 2021, Tauri 2 and Microsoft WebView2; browser assets are
+JavaScript built with Vite 8.1.6. This describes the native desktop
+frontend; Station has a separate React operator, specified below or in
+its product manual. Canonical business workflows use bundled CPython
+3.13.5, FastAPI, Pydantic, SQLAlchemy and Alembic, with PostgreSQL 17 /
+PostGIS and managed original files. The installed runtime tested here
+contains FastAPI 0.162.0. Package minimum Python requirements can differ
+from the bundled executable; the metadata reference preserves both. No
+stack rewrite is implied by the beta label.
+
+The native transport is fixed to loopback 127.0.0.1:15480; PostgreSQL
+uses the configured local runtime port (default 15432). Optional local
+model service defaults to 127.0.0.1:15434. Those are deployment
+defaults, not internet endpoints. The runtime has health, module and
+readiness endpoints; readiness is stronger than process existence. The
+task queue is the existing local Core task infrastructure, not an
+assertion that a separate Redis service is required for this desktop
+composition.
+
+The default native profile is %LOCALAPPDATA%\CivicSuite; the historical
+directory name remains part of compatibility. Do not rename it to
+Townlight. A configured TOWNLIGHT_PROFILE_ROOT must be absolute. Local
+configuration and secrets live under that profile; protected managed
+files and database state must be backed up coherently. Source/runtime
+identity is distinct from a product’s display label.
Data and consistency
-GeoJSON import datasets; parcels and zone/overlay context; cited rules; questions and answers; review events; selected Meetings history; immutable snapshots.
+GeoJSON import datasets; parcels and zone/overlay context; cited rules;
+questions and answers; review events; selected Meetings history;
+immutable snapshots.
-Versioned saves use expected prior revision identifiers where defined. Reopen and reconcile on conflict. Exact exports and handoffs use source IDs, current visibility, revision and SHA256. Review belongs to the saved revision and does not transfer silently to edited text. Database changes use the owning product’s migrations; a request or readiness check is not an authorization to mutate schema.
+Versioned saves use expected prior revision identifiers where defined.
+Reopen and reconcile on conflict. Exact exports and handoffs use source
+IDs, current visibility, revision and SHA256. Review belongs to the
+saved revision and does not transfer silently to edited text. Database
+changes use the owning product’s migrations; a request or readiness
+check is not an authorization to mutate schema.
Capacity and platform statements
-This beta has synthetic single-profile workflow evidence. It does not have a published benchmark for concurrent staff capacity, minimum RAM/CPU, large-source limits or a field SLA. Do not turn a developer machine’s specification into a supported minimum. The new installer size remains pending its build; allow additional disk for extracted runtime, database, originals, exports, media and backups. Select equipment/storage after sizing those actual workloads.
+This beta has synthetic single-profile workflow evidence. It does not
+have a published benchmark for concurrent staff capacity, minimum
+RAM/CPU, large-source limits or a field SLA. Do not turn a developer
+machine’s specification into a supported minimum. The signed MSI is
+2,082,697,216 bytes; allow additional disk for extracted runtime,
+database, originals, exports, media and backups. Select
+equipment/storage after sizing those actual workloads.
-The exact runtime payload lock records pinned files, sizes and hashes. The component metadata records shipped dependency declarations. These references are more precise than a manually copied dependency list. Third-party and historical license notices must accompany their matching payloads.
+The exact runtime payload lock records pinned files, sizes and hashes.
+The component metadata records shipped dependency declarations. These
+references are more precise than a manually copied dependency list.
+Third-party and historical license notices must accompany their matching
+payloads.
Configuration and administration
Native deployment configuration
-Use Setup, Settings and System Health for supported staff operation. Administrators provision folders, backup storage, named accounts and the city profile. Select inspections-preview for the bounded desktop composition, including Access and Notice. Station remains a separate service boundary. Do not use a standalone product’s demo server as a substitute for the installed workspace.
-
-Technical deployments use TOWNLIGHT_PRODUCT_PROFILE, TOWNLIGHT_PROFILE_ROOT, DATABASE_URL, TOWNLIGHT_RUNTIME_PORT, PORTAL_MODE and the runtime-managed secret files. Treat database URLs and native session proofs as secrets. The installed native domain runtime explicitly refuses non-loopback binding. PORTAL_MODE=private is the accepted posture; changing it does not by itself commission an internet portal, authentication provider or reverse proxy.
-
-The isolated documentation exporter sets a fictional profile and unusable synthetic database origin only to read schemas; those values are not deployment configuration. Keep deployment values in the intended process/account scope. An already-running process does not automatically inherit later environment edits.
+Use Setup, Settings and System Health for supported staff operation.
+Administrators provision folders, backup storage, named accounts and the
+city profile. Select inspections-preview for the bounded desktop
+composition, including Access and Notice. Station remains a separate
+service boundary. Do not use a standalone product’s demo server as a
+substitute for the installed workspace.
+
+Technical deployments use TOWNLIGHT_PRODUCT_PROFILE,
+TOWNLIGHT_PROFILE_ROOT, DATABASE_URL, TOWNLIGHT_RUNTIME_PORT,
+PORTAL_MODE and the runtime-managed secret files. Treat database URLs
+and native session proofs as secrets. The installed native domain
+runtime explicitly refuses non-loopback binding. PORTAL_MODE=private is
+the accepted posture; changing it does not by itself commission an
+internet portal, authentication provider or reverse proxy.
+
+The isolated documentation exporter sets a fictional profile and
+unusable synthetic database origin only to read schemas; those values
+are not deployment configuration. Keep deployment values in the intended
+process/account scope. An already-running process does not automatically
+inherit later environment edits.
API and integration examples
Native command example
-The following JavaScript belongs in the existing trusted Townlight frontend/development environment with invoke imported from @tauri-apps/api/core. It is not a command for an arbitrary web page or an instruction for nontechnical staff. IDs must come from records created in an isolated synthetic exercise.
+The following JavaScript belongs in the existing trusted Townlight
+frontend/development environment with invoke imported from
+@tauri-apps/api/core. It is not a command for an arbitrary web page or
+an instruction for nontechnical staff. IDs must come from records
+created in an isolated synthetic exercise.
import { invoke } from '@tauri-apps/api/core';
const result = await invoke('zoning_domain_request', {request: {operation: 'history', id: questionId}});
@@ -203,7 +381,12 @@ The following JavaScript belongs in the existing trusted Townlight frontend/deve
Trusted local HTTP example
-An administrator/developer can inspect an already-configured isolated runtime from a trusted local process. This PowerShell example reads the signed-in synthetic profile’s existing proof into memory; it does not create a user, seed a session, reveal the proof in output or bypass a permission check. Do not use real city data in development examples. A read response does not prove approval or publication.
+An administrator/developer can inspect an already-configured isolated
+runtime from a trusted local process. This PowerShell example reads the
+signed-in synthetic profile’s existing proof into memory; it does not
+create a user, seed a session, reveal the proof in output or bypass a
+permission check. Do not use real city data in development examples. A
+read response does not prove approval or publication.
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config\local-session.json'
@@ -214,11 +397,24 @@ An administrator/developer can inspect an already-configured isolated runtime fr
Complete synthetic source bundle
-The synthetic Zoning bundle is the retained fixture used by the beta staff exercise. It includes the complete supported source envelope rather than a shortened pseudo-payload. Keep its fictional source labels. For Planning, wrap it as {"bundle": BUNDLE, "expected_previous_revision": null}; for Permitting use {"bundle": BUNDLE, "expected_revision": null}. Code and Zoning take their own complete import envelopes. Replace null with the current expected revision when revising an existing source, as the applicable schema requires. These are import examples, not legal authority or permission to load them into a live city profile.
+The synthetic Zoning bundle is the retained fixture used by the beta
+staff exercise. It includes the complete supported source envelope
+rather than a shortened pseudo-payload. Keep its fictional source
+labels. For Planning, wrap it as
+{"bundle": BUNDLE, "expected_previous_revision": null}; for Permitting
+use {"bundle": BUNDLE, "expected_revision": null}. Code and Zoning take
+their own complete import envelopes. Replace null with the current
+expected revision when revising an existing source, as the applicable
+schema requires. These are import examples, not legal authority or
+permission to load them into a live city profile.
A synthetic write with subsequent readback
-This example demonstrates the existing Meetings HTTP contract in an isolated exercise. It is intentionally fictional. It does not start a service. Its authentication setup is included so it can be run independently under the signed-in synthetic account. If a write times out, inspect current records before repeating it.
+This example demonstrates the existing Meetings HTTP contract in an
+isolated exercise. It is intentionally fictional. It does not start a
+service. Its authentication setup is included so it can be run
+independently under the signed-in synthetic account. If a write times
+out, inspect current records before repeating it.
$profilePath = Join-Path $env:LOCALAPPDATA 'CivicSuite'
$sessionPath = Join-Path $profilePath 'config/local-session.json'
@@ -238,158 +434,261 @@ This example demonstrates the existing Meetings HTTP contract in an isolated exe
-Headers $headers
Remove-Variable session, headers
-This write requires Meetings to be enabled and the signed-in staff role to permit it. It is a cross-suite integration example; for this product’s request models, use the complete technical reference below.
+This write requires Meetings to be enabled and the signed-in staff role
+to permit it. It is a cross-suite integration example; for this
+product’s request models, use the complete technical reference below.
Complete technical contract
-Read the Zoning API reference for every documented operation, request field, constraint, response declaration and source supplement. Download the OpenAPI JSON for tools. For Station this is the suite-side schema only; its separate service contract is documented in the API supplement. The reference directory includes configuration/source inventories, dependency declarations, native command contracts, MCP signatures and candidate evidence.
+Read the Zoning API reference for every documented operation, request
+field, constraint, response declaration and source supplement. Download
+the OpenAPI JSON for tools. For Station this is the suite-side schema
+only; its separate service contract is documented in the API supplement.
+The reference directory includes configuration/source inventories,
+dependency declarations, native command contracts, MCP signatures and
+candidate evidence.
MCP and automation boundary
-No direct product MCP server is exposed by the accepted Townlight desktop or Station boundary. Do not configure an invented townlight mcp command or assume an AI client has staff permissions. The integration surfaces for this beta are native IPC, the documented HTTP APIs, source bundle imports, exact exports and the existing Station CLI.
+No direct product MCP server is exposed by the accepted Townlight
+desktop or Station boundary. Do not configure an invented townlight mcp
+command or assume an AI client has staff permissions. The integration
+surfaces for this beta are native IPC, the documented HTTP APIs, source
+bundle imports, exact exports and the existing Station CLI.
-The bundled transcription code includes a TextFlowKit MCP adapter as a separate source capability. It offers job-based transcribe_media, get_transcript, list_jobs, get_job_status and export_transcript, and additional tools declared in that adapter. It uses stdio first and optional Streamable HTTP, with the MCP SDK as an optional extra. It is not automatically launched, authenticated as Townlight staff or accepted as a Townlight product MCP deployment. This documentation does not add such a service.
+The bundled transcription code includes a TextFlowKit MCP adapter as a
+separate source capability. It offers job-based transcribe_media,
+get_transcript, list_jobs, get_job_status and export_transcript, and
+additional tools declared in that adapter. It uses stdio first and
+optional Streamable HTTP, with the MCP SDK as an optional extra. It is
+not automatically launched, authenticated as Townlight staff or accepted
+as a Townlight product MCP deployment. This documentation does not add
+such a service.
-For a transcription client already provisioned separately, an illustrative tool call is:
+For a transcription client already provisioned separately, an
+illustrative tool call is:
{"name":"get_job_status","arguments":{"job_id":"synthetic-existing-job-id"}}
-Use a job ID returned by that transcription service. This example does not create a Townlight record or bypass its review/Records handoff. The exact optional adapter tool signatures are supplied in the MCP source reference. Station meeting capture does not become live speech recognition because this optional donor adapter exists.
+Use a job ID returned by that transcription service. This example does
+not create a Townlight record or bypass its review/Records handoff. The
+exact optional adapter tool signatures are supplied in the MCP source
+reference. Station meeting capture does not become live speech
+recognition because this optional donor adapter exists.
Security and permissions
-Use your own named account and save before leaving a screen. A saved draft is durable; unsaved form text may not be. If a write has an unknown result, reopen its record before repeating it.
-
-Read source jurisdiction, dates, citation, version and visibility. A copied source hash identifies exact bytes, not their legal applicability. If a source changes or permission is removed, resolve the source problem rather than substituting stale cached content.
-
-Keep originals and derivatives separate. Review the intended audience before export. A public summary excludes private fields only through the applicable copy contract and your review. A renamed private packet is still private content.
-
-Drafting, review, approval, attachment, export, fulfillment and publication are separate operations. A Townlight workpaper does not itself adopt law, issue a permit, impose a fine or release a records response. The responsible staff member records the applicable decision.
-
-The native session is validated and mapped to a persisted SQL identity. An editable actor/reviewer label is not authentication. Product/module permissions and source visibility apply at the server boundary. Revoked/unavailable authority fails closed for new Station operations; a previous permission result is not a perpetual authorization.
-
-Use protected local folders, account permissions and credential storage. Never include the native session file, database passwords, provider keys or unredacted support bundles in a public issue or generated public documentation. A local public view is not automatically a secured internet deployment. Keep network exposure and real equipment acceptance specific to the chosen beta site.
+Use your own named account and save before leaving a screen. A saved
+draft is durable; unsaved form text may not be. If a write has an
+unknown result, reopen its record before repeating it.
+
+Read source jurisdiction, dates, citation, version and visibility. A
+copied source hash identifies exact bytes, not their legal
+applicability. If a source changes or permission is removed, resolve the
+source problem rather than substituting stale cached content.
+
+Keep originals and derivatives separate. Review the intended audience
+before export. A public summary excludes private fields only through the
+applicable copy contract and your review. A renamed private packet is
+still private content.
+
+Drafting, review, approval, attachment, export, fulfillment and
+publication are separate operations. A Townlight workpaper does not
+itself adopt law, issue a permit, impose a fine or release a records
+response. The responsible staff member records the applicable decision.
+
+The native session is validated and mapped to a persisted SQL identity.
+An editable actor/reviewer label is not authentication. Product/module
+permissions and source visibility apply at the server boundary.
+Revoked/unavailable authority fails closed for new Station operations; a
+previous permission result is not a perpetual authorization.
+
+Use protected local folders, account permissions and credential storage.
+Never include the native session file, database passwords, provider keys
+or unredacted support bundles in a public issue or generated public
+documentation. A local public view is not automatically a secured
+internet deployment. Keep network exposure and real equipment acceptance
+specific to the chosen beta site.
Backup recovery and maintenance
-Save work and use Core’s canonical Backup Now before maintenance. That operation stops writers. Preserve the coherent profile/database/document backup and its receipt, then use Start to resume. A source export is not a full backup.
-
-Use Restore Latest Backup through the supported controls. If the result says Restore needs service start, use Start, then Check, and reopen a known record. Do not repeat restore merely because services need to start. The fresh-profile acceptance verified that a fulfilled request survived restore and a post-backup marker did not.
-
-Keep Station’s dedicated database and media evidence together in its own backup. Core’s native-profile backup must not be assumed to include an external Station data directory. Stop writers during a coordinated backup. Preserve failed media attempts and logs.
-
-On failure, record the time, selected composition, component/installer versions and exact message. Check System Health for stopped, starting, ready or failed dependencies. Use the existing Retry control after readiness; do not create duplicate business records to refresh a stale view. Share only a redacted diagnostic bundle. Preserve secrets, original evidence, recovery material and unrelated installations.
+Save work and use Core’s canonical Backup Now before maintenance. That
+operation stops writers. Preserve the coherent profile/database/document
+backup and its receipt, then use Start to resume. A source export is not
+a full backup.
+
+Use Restore Latest Backup through the supported controls. If the result
+says Restore needs service start, use Start, then Check, and reopen a
+known record. Do not repeat restore merely because services need to
+start. The fresh-profile acceptance verified that a fulfilled request
+survived restore and a post-backup marker did not.
+
+Keep Station’s dedicated database and media evidence together in its own
+backup. Core’s native-profile backup must not be assumed to include an
+external Station data directory. Stop writers during a coordinated
+backup. Preserve failed media attempts and logs.
+
+On failure, record the time, selected composition, component/installer
+versions and exact message. Check System Health for stopped, starting,
+ready or failed dependencies. Use the existing Retry control after
+readiness; do not create duplicate business records to refresh a stale
+view. Share only a redacted diagnostic bundle. Preserve secrets,
+original evidence, recovery material and unrelated installations.
Troubleshooting
- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Symptom Likely meaning Next action
----------------------------- ------------------------------------------------------------------------ --------------------------------------------------------------------------------------------------
Workspace absent Wrong product composition or unavailable canonical runtime. Check selected composition; activate through Finish Records Migration; wait for readiness.
-
Cannot sign in / 401 Missing or expired named account session. Sign in normally; reopen a Station launch ticket if applicable.
-
Permission denied / 403 Account, module, source or browser-origin permission. Ask the authorized administrator to inspect the intended permission; do not invent role headers.
-
Save conflict / 409 The saved revision, expected source hash or lifecycle changed. Keep edits, reopen current state and reconcile deliberately.
-
Invalid input / 422 Required field, format, geometry, source envelope or state is invalid. Read the field detail and correct the input/source; preserve originals.
-
Service unavailable / 503 Database, schema, connected source or configuration unavailable. Inspect System Health and the named dependency. Preserve work; retry only after readiness.
-
Export refused Missing exact review, approval, audience or source authorization. Read the refusal and complete the owning product’s explicit decision.
-
Restore needs service start The snapshot was restored but services have not resumed. Use Start, then Check and verify a saved record; do not blindly repeat restore.
- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verified workflows and limits
- --------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Product Recorded result Precisely exercised
- ----------------------- ----------------------- --------------------------------------------------------------------------------------------------------------------
- Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace.
-
- --------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
-These results come from the identified signed candidate’s fresh normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and selected headless controls. All accounts, source bundles and media were synthetic. The guest install/uninstall and recovery passed, and the owned Sandbox stopped. No host installed application or standalone CivicCast was changed. This documentation task reuses those receipts; it does not claim a new software acceptance run.
-
-The workflow matrix identifies raw receipt filenames. The evidence index retains their original hashes; raw receipts remain in the private beta handoff rather than being silently republished with the documentation site.
-
-The limits remain: actual city field acceptance and equipment/network commissioning; Station automatic provisioning/SCM commissioning; every UI/role combination; field recognition accuracy; and historical in-place upgrades are not certified. They are not five invented feature requirements. Fresh-install controlled beta handoff remains the accepted scope. This package makes no city-deployment, publication or general-availability claim.
+ Product Recorded result Precisely exercised
+ --------- ----------------- --------------------------------------------------------------------------------------------------------------------
+ Zoning PASS GeoJSON/PostGIS import, cited dimensional rule, parcel answer, staff review/history/snapshot and native workspace.
+
+These results come from the identified signed candidate’s fresh
+normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and
+selected headless controls. All accounts, source bundles and media were
+synthetic. The guest install/uninstall and recovery passed, and the
+owned Sandbox stopped. No host installed application or standalone
+CivicCast was changed. This documentation task reuses those receipts; it
+does not claim a new software acceptance run.
+
+See the Windows acceptance summary for this MSI. The historical evidence
+index applies to its original build.
+
+The limits remain: actual city field acceptance and equipment/network
+commissioning; Station automatic provisioning/SCM commissioning; every
+UI/role combination; field recognition accuracy; and historical in-place
+upgrades are not certified. They are not five invented feature
+requirements. Fresh-install controlled beta handoff remains the accepted
+scope. This package makes no city-deployment, publication or
+general-availability claim.
Terms of service and license
Scope and status
-These terms describe the Townlight Beta 1 software and this documentation package. This is a locally prepared private beta, not a hosted-service subscription, a city deployment agreement or a public release. No uptime commitment, support response time, indemnity, data-processing agreement or paid service is created by these documents. A separate signed agreement, if any, governs services it actually provides.
+These terms describe the Townlight Beta 1 software and this
+documentation package. This public Windows beta is for evaluation. No
+uptime commitment, support response time, indemnity, data-processing
+agreement or paid service is created by these documents. A separate
+signed agreement, if any, governs services it actually provides.
Software license and rights
-Current Townlight-owned distributions identified in this candidate use AGPL-3.0-only. The full license is supplied with this documentation and with the source companion. The license governs rights to run, copy, modify and convey the covered software; these operational terms do not add restrictions to those rights. Historical grants and dependency licenses retain their own terms. CivicCast remains a separate product and is not relicensed by this documentation work.
-
-When conveying covered software, retain applicable notices and provide the corresponding source and installation/build information required by the license. For a modified version supporting remote network interaction, follow section 13’s source-offer requirement. The companion archive identifies the source for this candidate; a link to a different public branch is not a substitute for the matching source. Read the supplied license for the complete conditions. See the GNU license reference and GNU licensing FAQ.
+Current Townlight-owned distributions identified in this candidate use
+AGPL-3.0-only. The full license is supplied with this documentation and
+with the source companion. The license governs rights to run, copy,
+modify and convey the covered software; these operational terms do not
+add restrictions to those rights. Historical grants and dependency
+licenses retain their own terms. CivicCast remains a separate product
+and is not relicensed by this documentation work.
+
+When conveying covered software, retain applicable notices and provide
+the corresponding source and installation/build information required by
+the license. For a modified version supporting remote network
+interaction, follow section 13’s source-offer requirement. The companion
+archive identifies the source for this candidate; a link to a different
+public branch is not a substitute for the matching source. Read the
+supplied license for the complete conditions. See the GNU license
+reference and GNU licensing FAQ.
Data ownership and access
-Importing a document does not transfer its ownership or grant permission to publish it. The operating organization controls its accounts, access decisions, lawful source use, retention and review/release policy. Keep resident information, credentials, private notes and restricted evidence in their authorized locations. Documentation examples contain fictional data. No real city account, credential or record is required to exercise these examples in an isolated test environment.
+Importing a document does not transfer its ownership or grant permission
+to publish it. The operating organization controls its accounts, access
+decisions, lawful source use, retention and review/release policy. Keep
+resident information, credentials, private notes and restricted evidence
+in their authorized locations. Documentation examples contain fictional
+data. No real city account, credential or record is required to exercise
+these examples in an isolated test environment.
Local operation and external processors
-The accepted beta workflow is local and uses named staff accounts. Station has separate storage and credentials. Configure backup destinations and optional model/network providers deliberately. A configured external provider may receive submitted prompts, images or audio according to that configuration and provider’s terms; this documentation does not promise that every optional configuration is offline. An email outbox or local public view does not establish external delivery or an internet deployment. This static documentation site has no analytics, account collection or remote font dependency.
+The accepted beta workflow is local and uses named staff accounts.
+Station has separate storage and credentials. Configure backup
+destinations and optional model/network providers deliberately. A
+configured external provider may receive submitted prompts, images or
+audio according to that configuration and provider’s terms; this
+documentation does not promise that every optional configuration is
+offline. An email outbox or local public view does not establish
+external delivery or an internet deployment. This static documentation
+site has no analytics, account collection or remote font dependency.
Staff decisions and source applicability
-Staff verify the jurisdiction, source currency, permissions, citations and proposed audience. Model output and generated guidance require review. No draft is automatically an official legal interpretation, zoning determination, permit approval, fee assessment, enforcement notice or records-release decision. Official permit fee authority remains with the adopted source and responsible organization; imported amounts do not become a new authoritative calculation.
+Staff verify the jurisdiction, source currency, permissions, citations
+and proposed audience. Model output and generated guidance require
+review. No draft is automatically an official legal interpretation,
+zoning determination, permit approval, fee assessment, enforcement
+notice or records-release decision. Official permit fee authority
+remains with the adopted source and responsible organization; imported
+amounts do not become a new authoritative calculation.
Beta operation and recovery
-Use the identified candidate in its supported fresh-install scope. Preserve backups and original evidence. Test physical equipment and chosen network/service configuration before relying on them. The supplied acceptance describes selected synthetic workflows, not every screen, vendor, field condition or upgrade. Operators decide whether a particular deployment meets their own operational obligations.
+Use the identified candidate in its supported fresh-install scope.
+Preserve backups and original evidence. Test physical equipment and
+chosen network/service configuration before relying on them. The
+supplied acceptance describes selected synthetic workflows, not every
+screen, vendor, field condition or upgrade. Operators decide whether a
+particular deployment meets their own operational obligations.
Warranty and liability
-The covered software’s warranty and liability conditions are those in sections 15–17 of the supplied AGPL and any applicable separate written undertaking. This documentation creates no additional warranty or limitation beyond those terms. Third-party software is subject to its retained license notices. Nothing here removes rights that applicable law makes nonwaivable.
+The covered software’s warranty and liability conditions are those in
+sections 15–17 of the supplied AGPL and any applicable separate written
+undertaking. This documentation creates no additional warranty or
+limitation beyond those terms. Third-party software is subject to its
+retained license notices. Nothing here removes rights that applicable
+law makes nonwaivable.
Support and incident reporting
-Use the project’s existing SUPPORT and SECURITY guidance for its matching repository. Report reproducible behavior with the version, operation and redacted logs. Do not put credentials, resident records or unredacted evidence in a public issue. Coordinate sensitive reports through the channel designated in SECURITY. No new support address or service commitment is invented here.
+Use the project’s existing SUPPORT and SECURITY guidance for its
+matching repository. Report reproducible behavior with the version,
+operation and redacted logs. Do not put credentials, resident records or
+unredacted evidence in a public issue. Coordinate sensitive reports
+through the channel designated in SECURITY. No new support address or
+service commitment is invented here.
Ending a beta exercise and document changes
-When an organization ends testing, it controls retention/export and removes access according to its policy. Uninstall may retain data; back up and inspect the selected removal options. Ending an exercise does not revoke rights already granted by AGPL. Later software/documentation versions must identify their changed candidate and scope; historical receipts retain their original identities. These terms do not claim that a city has accepted a contract merely by reading a manual.
+When an organization ends testing, it controls retention/export and
+removes access according to its policy. Uninstall may retain data; back
+up and inspect the selected removal options. Ending an exercise does not
+revoke rights already granted by AGPL. Later software/documentation
+versions must identify their changed candidate and scope; historical
+receipts retain their original identities. These terms do not claim that
+a city has accepted a contract merely by reading a manual.
Glossary
- ---------------------------------------------------------------------------------------------------------------------------------------------------------
- Term Meaning
- ----------------------------------- ---------------------------------------------------------------------------------------------------------------------
- Approval An explicit authorized decision on the saved text/artifact. It is separate from saving or attachment.
-
- Canonical record The owning product’s retained identity and saved version, rather than an editable copied label.
-
- Composition The selected set of desktop modules; inspections-preview exposes the eight staff products.
-
- Corresponding source The source/build material matching the delivered covered program, subject to its license.
-
- Derivative / Records copy A separately prepared document with its own intended audience and hash.
-
- Hash / SHA256 A fingerprint of exact bytes. It detects change; it does not establish legal authority.
-
- Idempotency Repeating the same identified request has the same intended effect; changing its payload can be refused.
-
- IPC The native desktop command boundary between its browser interface and Rust host.
-
- MCP Model Context Protocol; no direct Townlight product server is enabled by this beta.
-
- Original Retained source bytes. A reviewed derivative does not replace them.
-
- Provenance Source, version, date, actor and relationship information retained with evidence.
-
- Revision An immutable saved version. Later edits do not inherit an earlier review automatically.
-
- Snapshot A fixed audience-specific copy tied to a source/reviewed revision.
-
- Station Townlight’s separate media boundary using a pinned CivicCast-derived engine; standalone CivicCast remains separate.
- ---------------------------------------------------------------------------------------------------------------------------------------------------------
+ Term Meaning
+ --------------------------- ---------------------------------------------------------------------------------------------------------------------
+ Approval An explicit authorized decision on the saved text/artifact. It is separate from saving or attachment.
+ Canonical record The owning product’s retained identity and saved version, rather than an editable copied label.
+ Composition The selected set of desktop modules; inspections-preview exposes the eight staff products.
+ Corresponding source The source/build material matching the delivered covered program, subject to its license.
+ Derivative / Records copy A separately prepared document with its own intended audience and hash.
+ Hash / SHA256 A fingerprint of exact bytes. It detects change; it does not establish legal authority.
+ Idempotency Repeating the same identified request has the same intended effect; changing its payload can be refused.
+ IPC The native desktop command boundary between its browser interface and Rust host.
+ MCP Model Context Protocol; no direct Townlight product server is enabled by this beta.
+ Original Retained source bytes. A reviewed derivative does not replace them.
+ Provenance Source, version, date, actor and relationship information retained with evidence.
+ Revision An immutable saved version. Later edits do not inherit an earlier review automatically.
+ Snapshot A fixed audience-specific copy tied to a source/reviewed revision.
+ Station Townlight’s separate media boundary using a pinned CivicCast-derived engine; standalone CivicCast remains separate.
Alphabetical subject index
@@ -414,14 +713,21 @@ Alphabetical subject index
Operating subject links
-- Discretionary processes and staff review — Discretionary processes and staff review.
+- Discretionary processes and staff review — Discretionary processes and
+ staff review.
- Explain the cited process — Explain the cited process.
-- Keep parcel import and inspection in the right order — Keep parcel import and inspection in the right order.
-- Use the existing specialist review contracts — Use the existing specialist review contracts.
+- Keep parcel import and inspection in the right order — Keep parcel
+ import and inspection in the right order.
+- Use the existing specialist review contracts — Use the existing
+ specialist review contracts.
Source and document control
-This edition is authored from the immutable corresponding-source companion, the generated installed-domain schema and the retained workflow receipts. The current software versions and signed artifacts are unchanged. Public historical pages are not synchronized or published by this local documentation task.
+This edition is authored from the immutable corresponding-source
+companion, the generated installed-domain schema and the retained
+workflow receipts. The current software versions and signed artifacts
+are unchanged. Public historical pages are not synchronized or published
+by this local documentation task.
Workflow subject index
diff --git a/docs/beta-1/api/access.html b/docs/beta-1/api/access.html
index a6e0c5e..4bab2be 100644
--- a/docs/beta-1/api/access.html
+++ b/docs/beta-1/api/access.html
@@ -7,8 +7,8 @@
@page{size:Letter;margin:.7in .65in .75in}
@media print{html{scroll-behavior:auto}body{font:10.5pt/1.45 Arial,sans-serif;color:#172f39}header,footer,.search-area,.screen-only{display:none}.doclayout{display:block;padding:0;max-width:none}.toc{position:static;max-height:none;overflow:visible;font-size:10pt;break-after:page}.toc>h2{border:0}.toc ul{columns:2;column-gap:.3in}.toc li{break-inside:avoid}.docbody h1{font-size:30pt}.docbody h2{font-size:19pt;break-after:avoid;padding-top:.15in;margin-top:.35in}.docbody h3{font-size:12pt;break-after:avoid}.docbody h4{break-after:avoid}p{orphans:3;widows:3}pre{font-size:8.2pt;line-height:1.4;padding:.1in;break-inside:auto}table{font-size:8.4pt;line-height:1.35}th,td{padding:.06in .07in}tr{break-inside:avoid}.flow{max-height:6in;object-fit:contain;break-inside:avoid}a{color:#172f39;text-decoration:underline}.cover{break-after:page;padding-top:1in}.cover .edition{font-size:11pt}.cover h1{font-size:32pt}.cover .lead{font-size:14pt}.api-entry{break-inside:auto}.api-entry h3{break-after:avoid}.index-columns{columns:2}}
-pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Access API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Access 0.5.0. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Code API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Code 1.0.9. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Core API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Core 1.3.0.dev2. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Inspections API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Inspections 0.3.0+dev.2. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Meetings API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Meetings 1.0.5. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Notice API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Notice 0.3.0. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Permitting API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Permitting 0.3.0+dev.2. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Planning API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Planning 0.4.0.dev2. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Records API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Records 1.8.0.dev2. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Station API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Station 0.3.0. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Suite API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Desktop source 1.7.0-1; townlight-runtime 0.2.0. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
Prepared source candidate, November 2, 2026. New signed Windows installed acceptance and publication remain pending.
+pre{white-space:pre-wrap;overflow-wrap:anywhere}summary{cursor:pointer;padding:.6rem;font-weight:600}details{margin:.5rem 0}Skip to contentTownlight
Townlight Zoning API reference
+
Windows Beta 1 · source reference. The signed Windows x64 beta 1.7.0.1 passed the documented fresh Windows Sandbox checks with synthetic data. This schema describes source contracts. The Windows acceptance summary identifies the installed checks.
Townlight Zoning 0.2.3. The HTTP host is Townlight Records 1.8.0.dev2. Component package versions and the host API version are separate identities.
Generated from the actual native inspections-preview composition without application lifespan, migrations or database/network access. It describes route and validation contracts; it does not establish endpoint behavior, individual authorization or installed acceptance. Standalone product applications have separate deployment boundaries.
diff --git a/docs/beta-1/assets/code-architecture.svg b/docs/beta-1/assets/code-architecture.svg
new file mode 100644
index 0000000..a61123b
--- /dev/null
+++ b/docs/beta-1/assets/code-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/core-architecture.svg b/docs/beta-1/assets/core-architecture.svg
new file mode 100644
index 0000000..d31cb59
--- /dev/null
+++ b/docs/beta-1/assets/core-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/inspections-architecture.svg b/docs/beta-1/assets/inspections-architecture.svg
new file mode 100644
index 0000000..03a2f1a
--- /dev/null
+++ b/docs/beta-1/assets/inspections-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/meetings-architecture.svg b/docs/beta-1/assets/meetings-architecture.svg
new file mode 100644
index 0000000..013fcaf
--- /dev/null
+++ b/docs/beta-1/assets/meetings-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/permitting-architecture.svg b/docs/beta-1/assets/permitting-architecture.svg
new file mode 100644
index 0000000..f0ea848
--- /dev/null
+++ b/docs/beta-1/assets/permitting-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/planning-architecture.svg b/docs/beta-1/assets/planning-architecture.svg
new file mode 100644
index 0000000..7ade4b3
--- /dev/null
+++ b/docs/beta-1/assets/planning-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/portal-architecture.svg b/docs/beta-1/assets/portal-architecture.svg
new file mode 100644
index 0000000..5b3849c
--- /dev/null
+++ b/docs/beta-1/assets/portal-architecture.svg
@@ -0,0 +1 @@
+
diff --git a/docs/beta-1/assets/portal-home.png b/docs/beta-1/assets/portal-home.png
new file mode 100644
index 0000000..c99e299
Binary files /dev/null and b/docs/beta-1/assets/portal-home.png differ
diff --git a/docs/beta-1/assets/portal-meeting.png b/docs/beta-1/assets/portal-meeting.png
new file mode 100644
index 0000000..524e104
Binary files /dev/null and b/docs/beta-1/assets/portal-meeting.png differ
diff --git a/docs/beta-1/assets/records-architecture.svg b/docs/beta-1/assets/records-architecture.svg
new file mode 100644
index 0000000..4577fb7
--- /dev/null
+++ b/docs/beta-1/assets/records-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/station-architecture.svg b/docs/beta-1/assets/station-architecture.svg
new file mode 100644
index 0000000..ce93434
--- /dev/null
+++ b/docs/beta-1/assets/station-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/station-delivery-architecture.svg b/docs/beta-1/assets/station-delivery-architecture.svg
new file mode 100644
index 0000000..bb1f02d
--- /dev/null
+++ b/docs/beta-1/assets/station-delivery-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/assets/suite-architecture.svg b/docs/beta-1/assets/suite-architecture.svg
new file mode 100644
index 0000000..5206ca7
--- /dev/null
+++ b/docs/beta-1/assets/suite-architecture.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/docs/beta-1/docx/Townlight-Access-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Access-Manual-Beta-1.docx
index 2edaf64..bd2a640 100644
Binary files a/docs/beta-1/docx/Townlight-Access-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Access-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx
index 54b01ed..8eb808d 100644
Binary files a/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Code-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx
index 529355c..1ac2765 100644
Binary files a/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Core-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx
index a801881..51f752f 100644
Binary files a/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Inspections-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx
index 7182d23..bf6d04d 100644
Binary files a/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Meetings-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Notice-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Notice-Manual-Beta-1.docx
index 3c63383..df4c5df 100644
Binary files a/docs/beta-1/docx/Townlight-Notice-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Notice-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx
index 390e03b..a631a99 100644
Binary files a/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Permitting-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx
index 6754f2d..f130233 100644
Binary files a/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Planning-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Portal-Guide-Beta-1.docx b/docs/beta-1/docx/Townlight-Portal-Guide-Beta-1.docx
new file mode 100644
index 0000000..d9196e3
Binary files /dev/null and b/docs/beta-1/docx/Townlight-Portal-Guide-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx
index 7802795..3caa12c 100644
Binary files a/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Records-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx
index bb4e7a9..11f05b6 100644
Binary files a/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Station-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx
index cda568e..ed79d05 100644
Binary files a/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Suite-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx b/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx
index 8e7b61c..24abe7e 100644
Binary files a/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx and b/docs/beta-1/docx/Townlight-Zoning-Manual-Beta-1.docx differ
diff --git a/docs/beta-1/index.html b/docs/beta-1/index.html
index faa792b..3ab5ae2 100644
--- a/docs/beta-1/index.html
+++ b/docs/beta-1/index.html
@@ -1 +1 @@
-Townlight | Townlight Beta 1Skip to contenttownlight ·Townlight Beta 1
The connected municipal suite · Townlight Beta 1
Municipal work with a clear record.
Connected municipal products help staff prepare, review and retain municipal work. Start with a controlled private beta, keep original evidence, and make each official decision deliberately.
Keep source versions and original hashes connected to staff work. Select the intended audience, review the saved revision, and explicitly attach the resulting evidence. Records retains the final response and release decisions.
A practical beta deployment
The selected Townlight desktop composition includes Access and Notice staff workspaces alongside the existing municipal workflows. Station is a separately configured capture and media service. Standalone CivicCast keeps its own product, installation and data.
The changed candidate still requires a new signed installer and exact installed acceptance before distribution. This documentation site does not provision a hosted city portal.
Architecture
The suite and its boundaries
Native staff workspaces use canonical Python/PostgreSQL services. Station has a separate database, media store and explicit Townlight authority.
Evidence rather than promises
Candidate installed acceptance remains pending.
Earlier releases have their own first-run and synthetic Windows Sandbox evidence. This changed source candidate requires a new signed installer and installed acceptance. This is not a claim that every screen, vendor, upgrade or city equipment configuration has been certified.
Begin with the current manual; obtain this candidate only after its exact installer and acceptance are identified. Configure the chosen test site and have its staff review source applicability and run the existing workflows.
Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.
Connected municipal products help staff prepare, review and retain municipal work. Start with a controlled beta evaluation, keep original evidence, and make each official decision deliberately.
Keep source versions and original hashes connected to staff work. Select the intended audience, review the saved revision, and explicitly attach the resulting evidence. Records retains the final response and release decisions.
A practical beta deployment
The selected Townlight desktop composition includes Access and Notice staff workspaces alongside the existing municipal workflows. Station is a separately configured capture and media service. Standalone CivicCast keeps its own product, installation and data.
Native staff workspaces use canonical Python/PostgreSQL services. Station has a separate database, media store and explicit Townlight authority.
Evidence rather than promises
Windows Sandbox acceptance passed.
The Windows acceptance summary records the workflows exercised with synthetic data on the released MSI. This is not a claim that every screen, vendor, upgrade or city equipment configuration has been certified.
Begin with the current manual and download the Windows x64 beta 1.7.0.1. Configure the chosen test site and have its staff review source applicability and run the existing workflows.
Station offers an encrypted live SRT feed to separate CivicCast while recording. The PEG operator controls cable broadcast. Completed recordings can be explicitly uploaded to YouTube with a reviewed title and chosen visibility. The private Records original stays intact.
The portal is a separately deployed suite capability for city pages
+and public meeting archives. It brings together a public Meetings
+archive, a completed Station recording and a Records release copy
+selected for publication. It does not add a tenth product. The existing
+signed Beta 1 installer and prior Sandbox evidence predate this local
+portal integration; they do not demonstrate that it is installed or
+publicly deployed. CivicCast remains separate.
+
For staff: prepare and
+publish
+
+
In Meetings, publish the intended non-closed meeting archive. Review
+its title, scheduled time, agenda, packet, minutes and summary for
+public use.
+
Complete the corresponding Station recording and the Records request
+and release workflow. Records must have a current approved response,
+completed verified artifacts, a fulfilled request and an eligible
+managed release copy with verified lineage to that recording. Keep the
+original private.
+
Obtain the Records request UUID from the trusted staff workflow. A
+fulfilled request or prepared copy is not consent to publish.
+
A Wagtail superuser opens Townlight publication in
+/admin/, enters the request UUID, selects Find
+approved releases, and chooses the intended result. The form
+fills the archive, meeting, recording, request and release-copy IDs and
+expected SHA-256; approval remains unchecked. Review the selection and
+public content, select Publish or update, and
+explicitly approve. Confirm the resulting meeting page and approved file
+as a resident would. Ordinary Wagtail editors cannot use this
+publisher.
+
To remove it from the public archive, use the same selection and
+hash, choose Withdraw, and explicitly approve. Verify
+that the meeting and file are no longer accessible. Withdrawal hides the
+projection; retain source records and follow local retention
+policy.
+
+
An unsuccessful synchronization leaves the previous publication
+intact. Repeating a successful publication updates the same archive
+identity. If source records change, review and explicitly publish again;
+do not assume a source error withdraws a prior version.
The meeting archive is at /meetings/. A published
+meeting page at /meetings/<pk>/ presents the approved
+public meeting text and links to its release at
+/meetings/<pk>/release/. The approved release bytes
+are served with the selected MIME type and support byte ranges for video
+playback. Public text is filtered; requester contact information,
+internal notes, raw payloads, local paths and session proof are not
+public fields. This integration is for completed release copies, not
+live YouTube streaming. Station’s separate CivicCast and YouTube
+workflows retain their own controls.
+
The city-branded homepage presents a resident task finder, service
+information and the latest published playable recording when one is
+available. The archive offers upcoming, past and all dates, title
+search, a meeting-series selector and 20 results per page. Meeting
+series uses the actual public title: the source contract does not supply
+a separate board taxonomy. Each date uses that meeting’s configured IANA
+time zone. Cancelled entries remain identifiable, with no offered
+playback or documents.
+
+
+Actual public meeting page with a
+synthetic approved recording
+
+
On a native Townlight meeting, open Agenda,
+Meeting packet or Approved minutes to
+read the actual approved text in a separate printable page. These are
+text documents, not invented PDF attachments. Video controls play the
+approved release; Download approved release retrieves
+the same checked bytes. Expand About this public record
+for provenance IDs, hashes and precise timestamps. PrimeGov fixtures
+instead identify their links as synthetic references; they do not imply
+live vendor downloads or playable media.
+
Search matches published service-page titles and
+published meeting titles only, with at most 50 results of each type. It
+excludes drafts, restricted city pages, withdrawn meetings and private
+staff content. It does not search the bodies of documents, external
+systems or private Records requests. Service buttons name the
+destination host before taking a resident to the city’s configured
+existing service. Applications, requests and payments stay in that
+designated system. Navigation, the task finder and filters work without
+JavaScript; JavaScript enhances the mobile menu.
+
City editors:
+branding and service content
+
+
Open the home page in Wagtail. Set Brand name,
+Brand prefix, the optional city Logo
+and Hero image, the Hero title,
+introduction, address and hours. Uploaded imagery must be approved for
+public use. With no uploaded images, the original generic civic emblem
+and illustrations are used. The page title is the fallback brand name;
+TOWNLIGHT_BRAND remains the administrative
+site-name/fallback setting. Existing versions stay unchanged and the
+suite label is Townlight Beta 1.
+
Create or edit a Service page under the home page.
+Set its title, kind, summary, section heading and body. Enter one next
+step per line. Optional question/answer blocks become expandable common
+questions. Set the department and public contact details where
+relevant.
+
For a handoff, enter the designated HTTPS Destination
+URL and clear Destination label. Addresses
+containing credentials and non-HTTPS schemes are rejected. The resident
+sees the destination host. This field is a link, not a vendor connector
+or new portal transaction. Verify it against the city’s authorized
+service before use.
+
Page kinds determine icons and shared links. records,
+permits, code, planning and
+contact are resident service entries.
+government supplies the government navigation link;
+privacy and accessibility supply
+footer/utility links. Only live, public pages appear. Use Wagtail’s
+existing editor submission and moderator approval workflow; editing a
+draft does not update public pages.
+
Review the public home, service page and phone layout after
+publishing. Unpublishing or restricting a page removes it from
+navigation, the task finder and title search. Configure city-approved
+privacy, accessibility and contact content; the fictional
+demonstration’s notices are examples, not an adopted city’s
+policies.
+
+
setup_demo creates the fictional Juniper
+Falls homepage and eight information pages on a fresh portal.
+The persistent synthetic notice is controlled by the home page’s
+Synthetic demo field. Example service destinations use
+reserved .example domains and do not operate real services.
+Repeating the command preserves any existing Townlight home and its
+editorial content; it does not replace a city’s website. Existing
+deployments receive additive fields through migrate; no
+existing text is overwritten. Configure their home and service pages
+through Wagtail after migration.
+
No resident account framework, official fee calculation, payment
+processor, live-stream host or new vendor integration is introduced by
+this interface.
+
Deployment and setup
+
The portal is a separate Wagtail deployment with its own database.
+Keep the native desktop runtime bound to loopback; do not expose it to
+the internet. Arrange a trusted private connection between the portal
+service and native runtime. The bridge accepts HTTPS origins or loopback
+HTTP origins; it does not follow redirects or use environment proxies.
+Restrict the server-side proof file to the portal service account and
+provision a native principal with both Meetings and Records permissions.
+Never put the proof in a browser, selection file, log or public
+document.
+
From the portal directory, use Python 3.13, install
+python -m pip install --require-hashes -r requirements.lock,
+run python manage.py migrate,
+python manage.py setup_demo, and
+python manage.py createsuperuser. For local evaluation run
+python manage.py runserver 127.0.0.1:8000. Set a unique
+TOWNLIGHT_SECRET_KEY, TOWNLIGHT_DEBUG=0,
+allowed hosts, TLS and appropriate static and media service before
+deployment. TOWNLIGHT_DB selects the database path;
+TOWNLIGHT_BRAND selects the site name. Protect the database
+and the private release directory together.
+TOWNLIGHT_RELEASE_ROOT is an absolute private directory
+outside public media; by default it is private-releases
+under the portal directory. These setup steps do not commission a hosted
+site or alter the already released installer.
+
Set TOWNLIGHT_NATIVE_ORIGIN to the trusted native origin
+and TOWNLIGHT_NATIVE_PROOF_FILE to an absolute private
+proof-file path. Sign in to the active native desktop with an account
+authorized for both modules. The active profile’s
+config/local-session.json contains
+session_hash; this is an active session proof, not a
+durable service token. Copy it without displaying it into an absolute
+file in a directory already restricted to the portal service account.
+Replace both placeholders in this PowerShell command with the actual
+private paths:
Refresh the protected proof after session expiry, sign-out, account
+change or credential change. Do not print or publish it.
+TOWNLIGHT_DISPLAY_TIMEZONE is an IANA time zone, defaulting
+to UTC. A private selection file can drive the same
+operation from the portal directory:
These IDs and hash are placeholders. Run
+python manage.py sync_townlight selection.json. For
+withdrawal change action to withdraw, retain
+the selection fields and explicit approval, and verify removal. Restrict
+the selection file because it contains internal identifiers.
+
Prepare the candidate
+native runtime
+
The existing signed installer predates the portal bridge and does not
+include its native endpoints. Prepare a separate matching native runtime
+with the compatible Records, Meetings, Core, Access and Notice
+dependencies, normal activation, profile and database contracts. Do not
+patch the installed host runtime. From the suite source root, build the
+candidate wheel into a chosen output directory:
In the separately prepared matching runtime, use its Python
+executable to install the built
+townlight_runtime-0.2.0-py3-none-any.whl with
+python -m pip install --no-deps --force-reinstall '<wheel-output>\townlight_runtime-0.2.0-py3-none-any.whl'.
+Preserve the intended profile, activation and database configuration;
+use meetings-beta or a higher applicable product profile.
+With that runtime’s Python, start
+python -m townlight_runtime.services; it binds
+127.0.0.1:15480 by default, or the port selected by
+TOWNLIGHT_RUNTIME_PORT. Keep this private and provide the
+portal’s server-side active proof and trusted origin as described above.
+Verify the authenticated selections endpoint with a real eligible
+request in the prepared environment before relying on publication. See
+verification and test inputs for the
+isolated acceptance runner and its explicit flags. These instructions do
+not upgrade the old installer or establish installed or public
+deployment acceptance.
+
Production service and
+reverse proxy
+
runserver is for local demonstration only. For
+deployment set TOWNLIGHT_DEBUG=0, a unique
+TOWNLIGHT_SECRET_KEY of at least 50 characters,
+TOWNLIGHT_ALLOWED_HOSTS to the canonical host,
+TOWNLIGHT_BASE_URL to the HTTPS origin,
+TOWNLIGHT_CSRF_TRUSTED_ORIGINS to that HTTPS origin, and
+TOWNLIGHT_STATIC_ROOT to the private deployment’s
+collected-static directory. Run python manage.py migrate,
+then python manage.py collectstatic, and start
+python serve.py --port 8000 under a supervised service
+account. Waitress binds only 127.0.0.1; stop the supervised
+service cleanly before backup or maintenance. In production Django
+enables secure cookies, HTTPS redirect and HSTS.
+
Terminate TLS in a reverse proxy on the same host. Set
+TOWNLIGHT_TRUST_TLS_PROXY=1 only when the proxy removes
+client-supplied forwarded headers and sets its own HTTPS scheme and
+canonical Host. Never expose the native desktop port. Replace the
+example hostname, certificate and static directory with deployment
+values; serve only collected static files directly. The application
+handles all other routes, including approved release files:
Keep the release directory outside every public static or media
+alias. Test the deployed HTTPS origin, admin, archive, range playback
+and explicit withdrawal using an approved synthetic record before
+use.
+
TOWNLIGHT_MEDIA_ROOT selects Wagtail’s uploaded-media
+storage (default portal/media). The image alias above
+serves generated branding renditions from that root’s
+images directory. Set the actual path for the deployment.
+Do not alias the entire media root: Wagtail document downloads may have
+their own access restrictions, and private releases must never be placed
+there. Back up the full media root privately, including originals, with
+the database.
+
Architecture and API
+
+
+Townlight portal
+architecture
+
+
The server calls POST /desktop/v1/portal/bundle with the
+selection JSON and the X-Townlight-Session header. The
+native principal must have both townlight_meetings and
+townlight_records permissions. The returned ZIP contains
+manifest.json and, for publication,
+release.bin; the portal validates identity, hashes, sizes
+and allowable fields before an atomic update. Withdrawal carries a
+manifest without release bytes. The public projection includes meeting
+text and ID/hash provenance, not the private source payload. The bridge
+streams bundles and release bytes through private files. Set
+TOWNLIGHT_PORTAL_MAX_BYTES consistently on both services;
+the default is 8 GiB and the maximum is 64 GiB. Allow private disk space
+for the bundle, staged copy and retained releases. The portal serves MP4
+or octet-stream releases. This transport limit is not the end-to-end
+recording limit: the inherited Records managed-file receipt limits both
+originals and release copies to 2,147,483,647 bytes. At Station’s
+default 6,000 kbps video rate, approximately 47 minutes reaches 2 GiB
+before accounting for audio and container overhead. Plan capture
+duration and bitrate before recording: for example, 2,000 kbps video
+plus audio for two hours is roughly 1.9 GB, depending on actual rates
+and overhead. Measure the resulting files and leave margin. The portal
+does not automatically transcode recordings. Consult the checked-in
+bridge and portal source for the exact contract and errors; do not log
+session proofs.
+
python manage.py export_public <empty-directory>
+exports published pages, metadata and approved release bytes with
+hashes. Secure the export as appropriate. Stop the portal and any
+synchronization before taking a consistent backup of the SQLite database
+and private release directory together; preserve private configuration
+and proof separately. Restore the matched database and releases to an
+isolated environment, set permissions and paths, then verify public
+pages, approved file hashes and withdrawal state before resuming
+service. A failed source sync preserves the prior projection;
+investigate permissions, source eligibility, IDs, expected hash,
+connection and proof-file access before retrying. An explicit withdrawal
+is necessary to remove a previously published item.
+
The export also includes city branding fields, all published service
+guidance, destinations, contact details, question/answer blocks and the
+original uploaded logo/hero files referenced by the published home, with
+hashes. It excludes draft/restricted page content and unreferenced
+uploads. Back up Wagtail’s media directory with its database as well as
+the private approved releases; city-uploaded branding is stored in media
+and its generated renditions must be served by the deployment. The
+public export is a portable content bundle, not a replacement for a
+consistent full backup or a one-command restore.
+
Public presentation routes
+
+
+
+
+
+
+
+
Route
+
Behavior and example
+
+
+
+
+
GET /
+
City home, live/public service navigation and latest published
+playable recording
+
+
+
GET /find-service/?service=meetings
+
Task finder redirects to the archive; a numeric ID selects a
+live/public service under this site’s home; arbitrary redirect
+destinations are refused
+
+
+
GET /meetings/?period=past&q=Council&series=Council%20Meeting&page=1
+
Published-title filters; period is
+upcoming, past or all; series
+matches a full public title; pages contain at most 20 results
+
+
+
GET /meetings/<pk>/
+
Published meeting and available public materials; unpublished
+identity returns 404
+
+
+
GET /meetings/<pk>/documents/agenda/
+
Approved native agenda text; packet and
+minutes select the other approved text documents;
+unavailable, cancelled, non-native or unpublished material returns
+404
+
+
+
GET /meetings/<pk>/release/
+
Existing integrity-checked approved release route with byte ranges;
+publication status is checked on every request
+
+
+
GET /search/?q=records
+
Live/public service title and published meeting title search; no
+private or external search
+
+
+
GET /<service-slug>/
+
Wagtail-published guidance and any configured service handoff
+
+
+
GET /source/
+
Allowlisted corresponding portal source, including deployed CSS,
+JavaScript, SVG illustrations, templates and native bridge source when
+present
+
+
+
+
These resident routes create no records or accounts. The private
+native API and explicit publication approval contract below are
+unchanged. There is no new portal MCP endpoint.
+
Editable data and
+presentation specifications
+
+
+
+
+
+
+
+
Model
+
Additional presentation fields
+
+
+
+
+
HomePage
+
Brand name (120 characters), prefix (40), hero title (160),
+introduction, address, hours, synthetic notice flag and optional Wagtail
+logo/hero image references
+
+
+
ServicePage
+
Kind (20), summary (300), heading (180), body and next-step text,
+destination URL and label (120), department (120), public contact text
+and Wagtail question/answer blocks
+
+
+
Meeting
+
Existing public identity, timestamps/time zone,
+cancellation/publication status, agenda/document projection and approved
+release/provenance fields; no invented board metadata
+
+
+
+
The layouts reuse the approved civic navy/teal, warm white and gold
+design with local fonts and original local illustrations. CSS and a
+small menu script ship in portal/website/static/website/;
+there are no remote fonts, analytics or client-side vendor calls.
+Existing Wagtail permissions, revisions, media storage and static
+collection are reused. Focus styles, skip navigation, semantic headings,
+phone layouts, reduced-motion handling and printable document styling
+are included. Accessible source material, captions/transcripts where
+applicable and the adopting city’s assistance contact remain part of its
+content responsibilities; no accessibility certification is claimed.
+
Bundle contract and errors
+
For discovery, the trusted portal server can call
+GET /desktop/v1/portal/selections?request_id=<UUID>
+with X-Townlight-Session. The native actor must have both
+module permissions. The JSON response is
+{"selections":[{"title":"<public archive title>","selection":{...}}]};
+each selection has all publication request fields, with
+action set to publish and
+approve_publication set to false. The Wagtail
+lookup uses this endpoint. Selecting a result supplies
+request_id, release_copy_id and
+archive_id as query parameters and fills the form without
+granting approval. An empty list means no eligible choice was returned;
+review source readiness and the request.
+
The JSON request requires action (publish
+or withdraw), boolean approve_publication set
+to true, UUIDs archive_id,
+meeting_id, recording_id,
+request_id, release_copy_id, and a
+64-character lowercase expected_release_sha256. No extra
+request fields are accepted. Send it only from the trusted portal server
+with X-Townlight-Session containing its private session
+proof. For example, the supported operator command
+python manage.py sync_townlight selection.json reads the
+selection illustrated above and supplies that header from the protected
+proof file.
+
A successful publish returns application/zip with
+manifest.json and release.bin. Manifest
+version 1 contains version, action,
+archive_id, meeting_id,
+recording_id, request_id,
+release_copy_id, original_sha256,
+title, timezone-aware scheduled_start,
+agenda, packet, minutes,
+summary, and release. The release
+object contains path (release.bin),
+sha256, size, and media_type.
+Withdrawal returns a ZIP containing only manifest.json with
+version, action and archive_id.
+The portal validates the selection, manifest and bytes before changing
+its projection.
+
Invalid input or missing explicit approval is rejected; authorization
+failures are rejected by the native identity layer. Unavailable or
+changed source data produces HTTP 409 with
+Publication sources unavailable or changed; the portal
+command reports synchronization failure and retains the existing
+publication. Resolve the underlying staff-side source, identity, hash or
+connectivity issue before retrying. Do not publish error logs containing
+proof or private source details.
+
Source, license and
+demonstration data
+
The synthetic PrimeGov transport is for demonstration and does not
+contact a real tenant. Townlight-owned portal code is AGPL-3.0-only;
+vendored CivicCast code retains its Apache-2.0 notices.
+/source/ offers allowlisted portal source and the native
+bridge from a repository checkout. Operators must provide the exact
+deployed corresponding source, modifications and dependencies as
+required by their license obligations. See the repository licenses,
+portal/UPSTREAM.md, and the existing terms and license; no city-specific
+legal terms are supplied here.
+
Subject index
+
+
Approval and selection: For staff: prepare and publish
+
Database and recovery: Deployment and setup; Architecture and
+API
+
Proof and permissions: Deployment and setup; Architecture and
+API
+
Resident pages and file: Residents
+
Branding and city service guidance: City editors: branding and
+service content
+
Search, filtering and document routes: Public presentation
+routes
+
Data fields and responsive design: Editable data and presentation
+specifications
+
Source and license: Source, license and demonstration data
+
Withdrawal: For staff: prepare and publish; Architecture and
+API
+
+
Rebuild this guide
+
From the suite repository root, install the repository’s Node
+dependencies (including Playwright), install a Playwright Chromium
+browser and make Python and Pandoc available on PATH. Run
+node scripts/docs/build_portal_guide.cjs. This rebuilds the
+portal guide HTML, editable Word, PDF and architecture PNG, and the
+portal verification reference HTML, from the checked-in Markdown, SVG,
+template and Word reference. To use an existing Playwright installation
+or Chromium executable, set PLAYWRIGHT_MODULE or
+CHROMIUM_EXECUTABLE; PYTHON selects a Python
+executable. The sibling product repositories are not needed to rebuild
+this
+guide.
+
\ No newline at end of file
diff --git a/docs/beta-1/manuals/records.html b/docs/beta-1/manuals/records.html
index 31905a3..09d1bd6 100644
--- a/docs/beta-1/manuals/records.html
+++ b/docs/beta-1/manuals/records.html
@@ -1,6 +1,6 @@
-Townlight Records Manual | Townlight candidateSkip to contenttownlight ·Townlight Beta 1
-
Townlight Beta 1
Townlight
-Zoning
-README
Staff guide and technical reference
Documentation edition 30 October 2026 Existing component versions retained Signed suite installer 1.6.0.1 Private beta documentation companion
Zoning combines local parcel geometry, cited zoning rules and staff
-review. It retains questions, corrections and snapshots with provenance
-so downstream staff can identify the precise evidence used.
-
Start here
-
Staff should use the operating manual. Administrators should read
-first-run, configuration and recovery before changing a deployment.
-Developers should read the exact API/schema reference and matching
-source companion. This is a private candidate documentation update; it
-neither changes public downloads nor publishes a release.
Windows x64 fresh install; inspections-preview; separate Station
-configuration
-
-
-
-
“Townlight Beta 1” identifies this coordinated beta delivery. It does
-not renumber the installer, native binary, Python packages or historical
-receipts. Component versions may differ. This documentation is a later
-companion to unchanged signed bytes, not a rebuilt installer. Historical
-release pages and manuals describe their own versions and are not the
-download instructions for this private candidate.
-
What staff can do
-
-
Prepare parcel data: Use the complete supported
-bundle, including jurisdiction, dataset metadata and original hashes.
-The coordinates must be EPSG:4326. A loose geometry file is not the full
-source envelope.
-
Import and inspect: Check the complete source
-envelope before selecting Import parcel dataset. That control submits
-directly; inspect the saved validation/provenance result afterward.
-Correct a refused source bundle and preserve the evidence. Do not force
-acceptance by editing SQL.
-
Register cited rules: Associate the zone, rule
-kind/key and value with the relevant public Code section. Inspect
-overlays and effective context. Leave missing authority visible for
-planner review.
-
Ask a parcel question: Look up the intended parcel
-and ask the supported question. Read the returned citation,
-applicability and disclaimer. Do not present an uncertain answer as an
-official decision.
-
Record review and context: Record a correction and
-its reason when needed. Select permitted Meetings history explicitly.
-Preserve the question/review history and distinguish staff-only
-precedent from public material.
-
Create a snapshot: Review the audience and exact
-content before creating the immutable snapshot. A public snapshot must
-satisfy its permitted-source contract; choosing a public label does not
-sanitize private notes.
-
Use it downstream: Select the exact snapshot for
-Records or the permitted provider path. The receiving workflow rechecks
-visibility, source identity and hash before retaining or exporting
-it.
-
-
Operating procedures and
-examples
-
The operating manual now includes these existing procedures, with
-synthetic inputs, readback and limits. Follow the actual app boundary
-identified there; a standalone source capability is not automatically a
-desktop screen.
The accepted package targets Windows x64 fresh
-installation. Its native shell uses Rust 2021, Tauri 2
-and Microsoft WebView2; browser assets are JavaScript built
-with Vite 8.1.6. This describes the native desktop
-frontend; Station has a separate React operator, specified below or in
-its product manual. Canonical business workflows use bundled
-CPython 3.13.5, FastAPI, Pydantic, SQLAlchemy and
-Alembic, with PostgreSQL 17 / PostGIS and
-managed original files. The installed runtime tested here contains
-FastAPI 0.162.0. Package minimum Python requirements can differ from the
-bundled executable; the metadata reference preserves both. No stack
-rewrite is implied by the beta label.
-
The native transport is fixed to loopback
-127.0.0.1:15480; PostgreSQL uses the configured local
-runtime port (default 15432). Optional local model service
-defaults to 127.0.0.1:15434. Those are deployment defaults,
-not internet endpoints. The runtime has health, module and readiness
-endpoints; readiness is stronger than process existence. The task queue
-is the existing local Core task infrastructure, not an assertion that a
-separate Redis service is required for this desktop composition.
-
The default native profile is %LOCALAPPDATA%\CivicSuite;
-the historical directory name remains part of compatibility. Do not
-rename it to Townlight. A configured TOWNLIGHT_PROFILE_ROOT
-must be absolute. Local configuration and secrets live under that
-profile; protected managed files and database state must be backed up
-coherently. Source/runtime identity is distinct from a product’s display
-label.
-
Data and consistency
-
GeoJSON import datasets; parcels and zone/overlay context; cited
-rules; questions and answers; review events; selected Meetings history;
-immutable snapshots.
-
Versioned saves use expected prior revision identifiers where
-defined. Reopen and reconcile on conflict. Exact exports and handoffs
-use source IDs, current visibility, revision and SHA256. Review belongs
-to the saved revision and does not transfer silently to edited text.
-Database changes use the owning product’s migrations; a request or
-readiness check is not an authorization to mutate schema.
-
Capacity and platform
-statements
-
This beta has synthetic single-profile workflow evidence. It does not
-have a published benchmark for concurrent staff capacity, minimum
-RAM/CPU, large-source limits or a field SLA. Do not turn a developer
-machine’s specification into a supported minimum. Installer size is
-2,092,122,112 bytes before installation; allow additional disk for
-extracted runtime, database, originals, exports, media and backups.
-Select equipment/storage after sizing those actual workloads.
-
The exact runtime
-payload lock records pinned files, sizes and hashes. The component metadata
-records shipped dependency declarations. These references are more
-precise than a manually copied dependency list. Third-party and
-historical license notices must accompany their matching payloads.
-
-
-
-
-
-
-
-
Data contract
-
Description
-
-
-
-
-
Input
-
A supported EPSG:4326 GeoJSON envelope, jurisdiction and dataset
-metadata, public Code authority and permitted meeting evidence.
-
-
-
Retained records
-
GeoJSON import datasets; parcels and zone/overlay context; cited
-rules; questions and answers; review events; selected Meetings history;
-immutable snapshots.
-
-
-
Output
-
Source-backed parcel context, informational answers, recorded human
-corrections and reviewed snapshots with stable hashes.
-
-
-
Connections
-
Consumes Code authority and permitted Meetings evidence. Supplies
-permitted snapshots to Records and context to Planning and
-Permitting.
-
-
-
-
Setup and operation
-
-
Obtain the identified signed private candidate and its
-corresponding-source companion from the beta coordinator. The landing
-pages in this documentation are not an installer download service.
-
On the intended fresh Windows test installation, verify the MSI hash
-and publisher signature before installing. Preserve unrelated profiles
-and recovery material. This candidate has fresh-install acceptance;
-historical in-place upgrades are unverified.
-
Launch Townlight under the intended named Windows account. Choose
-the storage folders. Select Townlight Inspections
-candidate (inspections-preview) for all eight
-desktop products. A narrower default selection will not expose all
-workspaces.
-
Enter the city profile, time zone and contacts. Create the first
-named local administrator, sign in and choose protected backup storage.
-Continue without local AI is valid for the
-deterministic workflows.
-
Run Health Check and wait for readiness. Open Townlight. In System
-Health select Finish Records Migration to activate the
-canonical Python/PostgreSQL runtime. Do not fabricate migration receipts
-or seed accounts.
-
Create named staff through Settings. Import authorized sources using
-each product’s source library. All examples in this package are
-synthetic; they are not municipal authority.
-
Provision Station separately if it is part of the beta exercise.
-Selecting the desktop composition does not start or configure Station.
-Configure vision explicitly only if automatic photo drafting is
-selected.
-
-
Configuration
-
Native deployment
-configuration
-
Use Setup, Settings and System Health for supported staff operation.
-Administrators provision folders, backup storage, named accounts and the
-city profile. Select inspections-preview for the full
-eight-workspace desktop. Station remains a separate service boundary. Do
-not use a standalone product’s demo server as a substitute for the
-installed workspace.
-
Technical deployments use TOWNLIGHT_PRODUCT_PROFILE,
-TOWNLIGHT_PROFILE_ROOT, DATABASE_URL,
-TOWNLIGHT_RUNTIME_PORT, PORTAL_MODE and the
-runtime-managed secret files. Treat database URLs and native session
-proofs as secrets. The installed native domain runtime explicitly
-refuses non-loopback binding. PORTAL_MODE=private is the
-accepted posture; changing it does not by itself commission an internet
-portal, authentication provider or reverse proxy.
-
The isolated documentation exporter sets a fictional profile and
-unusable synthetic database origin only to read schemas; those values
-are not deployment configuration. Keep deployment values in the intended
-process/account scope. An already-running process does not automatically
-inherit later environment edits.
-
API usage
-
Native command example
-
The following JavaScript belongs in the existing trusted Townlight
-frontend/development environment with invoke imported from
-@tauri-apps/api/core. It is not a command for an arbitrary
-web page or an instruction for nontechnical staff. IDs must come from
-records created in an isolated synthetic exercise.
An administrator/developer can inspect an already-configured isolated
-runtime from a trusted local process. This PowerShell example reads the
-signed-in synthetic profile’s existing proof into memory; it does not
-create a user, seed a session, reveal the proof in output or bypass a
-permission check. Do not use real city data in development examples. A
-read response does not prove approval or publication.
The synthetic Zoning
-bundle is the retained fixture used by the beta staff exercise. It
-includes the complete supported source envelope rather than a shortened
-pseudo-payload. Keep its fictional source labels. For Planning, wrap it
-as {"bundle": BUNDLE, "expected_previous_revision": null};
-for Permitting use
-{"bundle": BUNDLE, "expected_revision": null}. Code and
-Zoning take their own complete import envelopes. Replace null with the
-current expected revision when revising an existing source, as the
-applicable schema requires. These are import examples, not legal
-authority or permission to load them into a live city profile.
-
A synthetic write
-with subsequent readback
-
This example demonstrates the existing Meetings HTTP contract in an
-isolated exercise. It is intentionally fictional. It does not start a
-service. Its authentication setup is included so it can be run
-independently under the signed-in synthetic account. If a write times
-out, inspect current records before repeating it.
This write requires Meetings to be enabled and the signed-in staff
-role to permit it. It is a cross-suite integration example; for this
-product’s request models, use the complete technical reference
-below.
-
MCP status
-
No direct product MCP server is exposed by the accepted Townlight
-desktop or Station boundary. Do not configure an invented
-townlight mcp command or assume an AI client has staff
-permissions. The integration surfaces for this beta are native IPC, the
-documented HTTP APIs, source bundle imports, exact exports and the
-existing Station CLI.
-
The bundled transcription code includes a TextFlowKit MCP
-adapter as a separate source capability. It offers job-based
-transcribe_media, get_transcript,
-list_jobs, get_job_status and
-export_transcript, and additional tools declared in that
-adapter. It uses stdio first and optional Streamable HTTP, with the MCP
-SDK as an optional extra. It is not automatically launched,
-authenticated as Townlight staff or accepted as a Townlight product MCP
-deployment. This documentation does not add such a service.
-
For a transcription client already provisioned separately, an
-illustrative tool call is:
Use a job ID returned by that transcription service. This example
-does not create a Townlight record or bypass its review/Records handoff.
-The exact optional adapter tool signatures are supplied in the MCP source reference. Station meeting
-capture does not become live speech recognition because this optional
-donor adapter exists.
These results come from the identified signed candidate’s fresh
-normal-profile Sandbox exercise: real native IPC/HTTP/PostgreSQL and
-selected headless controls. All accounts, source bundles and media were
-synthetic. The guest install/uninstall and recovery passed, and the
-owned Sandbox stopped. No host installed application or standalone
-CivicCast was changed. This documentation task reuses those receipts; it
-does not claim a new software acceptance run.
-
The workflow matrix
-identifies raw receipt filenames. The evidence index
-retains their original hashes; raw receipts remain in the private beta
-handoff rather than being silently republished with the documentation
-site.
-
The limits remain: actual city field acceptance and equipment/network
-commissioning; Station automatic provisioning/SCM commissioning; every
-UI/role combination; field recognition accuracy; and historical in-place
-upgrades are not certified. They are not five invented feature
-requirements. Fresh-install controlled beta handoff remains the accepted
-scope. This package makes no city-deployment, publication or
-general-availability claim.
-
The accepted path is local GeoJSON/PostGIS. It does not establish
-every ArcGIS, assessor or CKAN connector. Answers and process
-explanations are informational and do not issue an entitlement or an
-official zoning determination.
-
Development and repository
-map
-
Use the corresponding source for the candidate rather than assuming
-the public default branch matches it. The source companion contains
-installed-owned-source, product build inputs, desktop
-Rust/browser sources, locks and BUILD.md. It excludes
-credentials and third-party binary/model payloads. Use the recorded
-runtime lock when reproducing packaging.
-
Relevant source contracts:
-
-
townlight_zoning/geo_import.py
-
townlight_zoning/discretionary.py
-
townlight_runtime/zoning_bridge.py
-
townlight_runtime/zoning_records.py
-
-
The desktop package defines npm run build,
-npm test, npm run test:browser and its Tauri
-command. Python products retain their own pyproject.toml,
-tests and migrations; use the matching checkout’s declared dependencies
-and test configuration. Do not run a sample server against a production
-profile. This documentation build validates documentation only and
-reuses the separately identified installed acceptance; it does not claim
-a new complete application CI run.
-
Recovery and support
-
Save work and use Core’s canonical Backup Now before
-maintenance. That operation stops writers. Preserve the coherent
-profile/database/document backup and its receipt, then use
-Start to resume. A source export is not a full
-backup.
-
Use Restore Latest Backup through the supported
-controls. If the result says Restore needs service
-start, use Start, then Check,
-and reopen a known record. Do not repeat restore merely because services
-need to start. The fresh-profile acceptance verified that a fulfilled
-request survived restore and a post-backup marker did not.
-
Keep Station’s dedicated database and media evidence together in its
-own backup. Core’s native-profile backup must not be assumed to include
-an external Station data directory. Stop writers during a coordinated
-backup. Preserve failed media attempts and logs.
-
On failure, record the time, selected composition,
-component/installer versions and exact message. Check System Health for
-stopped, starting, ready or failed dependencies. Use the existing Retry
-control after readiness; do not create duplicate business records to
-refresh a stale view. Share only a redacted diagnostic bundle. Preserve
-secrets, original evidence, recovery material and unrelated
-installations.
-
License and responsible use
-
Current owned code is AGPL-3.0-only. Preserve full license, matching
-corresponding source, dependency notices and historical grants. Terms of
-use do not remove license rights. Source imports do not confer
-permission to publish third-party material. Review all automatic drafts
-and use the separate owning-product decision before official action.
-CivicCast remains
-independent.
AST route declarations alone do not prove mounting or runtime behavior. The inventory marks source companion assembly as pending until an actual built companion is supplied; it makes no signed-installer claim.