Decision

What It Models

A decision is a formal motion and its recorded disposition under the committee’s rules. It combines what members vote on, who may vote, recorded evidence and the effect of a carried result. Disclosures remain a separate concept even when they suggest that a voter should stand aside.

Identity and Attributes

The stable identity exists before the committee number. Opening captures the governing rule and voter facts so later evaluation does not use a changed roster or bylaw document. Tallies and named votes are separate input methods for the same deterministic result engine.

Relationships

Meeting methods reference a gathering and optional agenda item. Approval targets a minutes revision; appointment decisions can carry nomination slates. Amendments and rescissions refer to an earlier carried record rather than editing its motion.

Invariants

The application checks lifecycle, eligibility, recusal, kind-specific inputs and appointment ownership. Database uniqueness and shape checks are visible in declarations. Trigger-based immutability and deletion grants require migration evidence and are not certified here.

How It Is Stored and Shared

The decisions service owns motions, counters, snapshots, votes and recusals. Consequences share a transaction with closing and invoke owner operations, except for the recorded internal cross-module writes. Queries exposes decisions and votes. This concept declares no custom fields.

Open Design Questions

Empty rule documents still use defaults, and unsupported rescission reversals remain open product issues. The ballot port has no production implementation. Opening also does not repeat the meeting-status check made during drafting.