From 754b01902b6c87d155e4bfe2067a346b681f6ee7 Mon Sep 17 00:00:00 2001 From: zemion Date: Sat, 1 Aug 2026 08:55:54 +0200 Subject: [PATCH] Sync Repo-docs-COMMITTEE-DOMAIN-BOUNDARY from project files --- Repo-docs-COMMITTEE-DOMAIN-BOUNDARY.-.md | 69 ++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 Repo-docs-COMMITTEE-DOMAIN-BOUNDARY.-.md diff --git a/Repo-docs-COMMITTEE-DOMAIN-BOUNDARY.-.md b/Repo-docs-COMMITTEE-DOMAIN-BOUNDARY.-.md new file mode 100644 index 0000000..77d4212 --- /dev/null +++ b/Repo-docs-COMMITTEE-DOMAIN-BOUNDARY.-.md @@ -0,0 +1,69 @@ + + +> Mirrored from `/mnt/DATA/git/govoplan-committee/docs/COMMITTEE_DOMAIN_BOUNDARY.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# Committee Domain Boundary + +## Purpose + +Committee, board, council, and senate workflows for meetings, agendas, minutes, decisions, voting, and follow-up tasks. + +## Owns + +- committee bodies +- meeting agendas +- minutes +- deliberation and vote context plus references to formal decision records +- votes +- follow-up assignments + +## Does Not Own + +- generic task execution +- document storage +- calendar event storage +- generic approval gates +- the cross-domain formal decision lifecycle, including authority, facts, + applicable rules, reasoning, effects, review, correction, and revocation + +## Integration Candidates + +- calendar +- docs +- files +- tasks +- workflow +- approvals + +## Current Headless Slice + +The current repository state is intentionally bounded: + +- module manifest and entry point +- tenant-level permission definitions +- manager and viewer role templates +- documentation topic and architecture/evidence declaration +- `committee.decision_path` interface and capability +- a governed assembler for one formal committee outcome +- Gitea issue workflow templates +- manifest and decision reconstruction contract tests + +No runtime API, database model, migration, WebUI route, or navigation item is +registered yet. The headless decision path accepts or resolves one effective +Mandate covering the deciding unit, function, and jurisdiction; requires +approval, fact evidence, versioned legal bases, operative +result, and reasoning, and emits the shared formal Decision contract. If a +Decision registry is installed it records there; otherwise the result remains +a reconstructable return value for a future Committee-owned local projection. + +## Decision Reconstruction Proof + +`tests/test_decision_path.py` proves effective-time authority, organization, +function, and jurisdiction coverage, approval, legal basis/evidence versions, requested effects, +information governance, responsible actor/automation assurance, and a protected +reconstruction payload. A vote remains +an approval reference and is not made indistinguishable from the formal +institutional outcome.