# MODULE REGISTRY
**BB2G Election Command — the canonical register of all 68 modules.**
> **This file is GENERATED. Do not hand-edit it.**
> Source of truth: `assets/registry.mjs` — 68 module records, 10 groups, 10 shared
> services, 11 completion dimensions, 6 releases.
> Generated 2026-08-15 by importing that module and walking it, so this document
> and the data the application ships cannot drift apart.
>
> `sha256(assets/registry.mjs)` = `b4a80c1724e5f1de08392b3aa7ed33d418c9939408fcafed8a83dbd6a1042e42`
The blueprint puts it plainly: *"The sixty modules are a minimum, not a cap."* It
then names eight further functions — Observer Management, Warehouse Logistics,
Election Communications, Facility Acquisition, Courier Operations, Election Scenario
Exercises, MDM Fleet Management, Vendor Assurance — and instructs that if they
already exist as legitimate BB2G functionality they should be **preserved rather
than forced awkwardly into the original sixty**. They are carried here as modules
61–68, in their own group, flagged `beyondSixty`.
**Registration is not implementation.** A module appearing in this register means
its purpose, workflows, data objects, domain events, acceptance gate and shared-
service dependencies are specified. It does **not** mean it is built. For what is
actually built, see `MODULE_COMPLETION_MATRIX.md` — the honest answer there is that
the shared spine is built and gated and the 68 domain modules are not.
---
## The ten shared services
The blueprint's central instruction: *"The central architectural mistake to avoid
is creating sixty copies of authentication, evidence handling, audit logging,
jurisdiction logic and synchronization. The sixty modules should be comparatively
thin domain applications. The hard infrastructure should live once."*
| Code | Service | Production responsibility | Modules consuming |
|---|---|---|---:|
| **LC** | LockChain Ledger Core | Event canonicalization, hash chain, signed receipts/checkpoints, correction links, independent verification | 68 / 68 |
| **EV** | Evidence Core | Immutable originals, derivatives, provenance, classification, legal holds, custody and evidence manifests | 46 / 68 |
| **ID** | Identity & Authorization Core | MFA, managed devices, RBAC + ABAC, jurisdiction scope, least privilege, privileged-access review | 65 / 68 |
| **OF** | Offline Sync Core | Encrypted local event queue, idempotent replay, conflict handling, server acknowledgements | 28 / 68 |
| **JU** | Jurisdiction Rules Engine | State/county/election applicability, effective dates, controlling authority and procedure selection | 51 / 68 |
| **CU** | Election Knowledge Currency Engine | Source retrieval, section hashes, changes, supersession, stale-source warnings and human review | 12 / 68 |
| **CO** | AI Election Copilot | Citation-grounded procedural retrieval with mandatory abstention when current authority is unavailable | 1 / 68 |
| **NO** | Notifications & Escalation Core | Alerting, acknowledgements, escalation timers, delivery history | 42 / 68 |
| **RE** | Reporting & Document Core | PDF/CSV/JSON outputs, custody receipts, evidence packages, audit reports and manifests | 61 / 68 |
| **OB** | Observability & Security Core | Application health, security events, sync failures, source freshness, backup health and operational telemetry | 24 / 68 |
Read that last column as the architecture argument in numbers. **LockChain Ledger
Core is consumed by all 68** — every significant operation emits a canonical event,
which is exactly why it must exist once and not sixty-eight times. Identity &
Authorization Core: 65. Reporting & Document Core: 61. Jurisdiction Rules Engine:
51. At the other end, **AI Election Copilot is consumed by 1** — it is the last
release for a reason, and it is not load-bearing for anything else.
Service codes used in the module tables below:
`LC` LockChain Ledger Core · `EV` Evidence Core · `ID` Identity & Authorization Core · `OF` Offline Sync Core · `JU` Jurisdiction Rules Engine · `CU` Election Knowledge Currency Engine · `CO` AI Election Copilot · `NO` Notifications & Escalation Core · `RE` Reporting & Document Core · `OB` Observability & Security Core
---
## Module groups
| Group | Modules | Count |
|---|---|---:|
| Election Command | 01–06 | 6 |
| Polling-Place Operations | 07–14 | 8 |
| Ballot Operations | 15–21 | 7 |
| Equipment & Technology | 22–28 | 7 |
| Evidence & Auditability | 29–35 | 7 |
| Incident & Safety | 36–42 | 7 |
| Cybersecurity | 43–49 | 7 |
| Intelligence / Review | 50–54 | 5 |
| Records & Compliance | 55–60 | 6 |
| Beyond the Sixty | 61–68 | 8 |
| **Total** | | **68** |
---
## The register
### Election Command
The role-aware operating picture that plans the election, runs election day and closes it out. The blueprint aligns this group with an existing county operating model built on a staffed command-centre hotline, service-ticket records, field dispatch, offline site procedures and real-time tracking.
| ID | Module | Shared services consumed |
|---|---|---|
| **01** | Master Election Command Center | LC · ID · JU · NO · RE · OB |
| **02** | Election Calendar & Milestones | LC · EV · JU · CU · NO · RE |
| **03** | Jurisdiction Configuration Engine | LC · ID · JU · RE · OB |
| **04** | Election Readiness Score | LC · EV · JU · CU · RE |
| **05** | Election-Day Operations Console | LC · ID · OF · JU · NO · RE · OB |
| **06** | After-Action Command Center | LC · EV · ID · NO · RE |
01 · Master Election Command Center
**What "built in full" means** *(blueprint, verbatim)*
> Role-aware county/state operating picture, jurisdiction/election selector, site health, incidents, tasks, custody and evidence drill-down, handoff summary and current-data timestamps.
**Purpose** — Give county and state command one role-aware operating picture of every location, incident, task and custody exception for the selected jurisdiction and election.
**Workflows**
- Select jurisdiction and election, and scope every panel to that selection
- Watch site health across the fleet: open, preparing, closed, degraded, unreachable
- Drill from a summary tile into the underlying incidents, tasks, custody items or evidence
- Produce a shift handoff summary with open items, owners and current-data timestamps
- Surface unsynchronized devices and stale panels rather than showing confident stale numbers
**Primary data objects** — OperatingPicture, LocationStatus, CommandTask, HandoffSummary, DataFreshnessStamp
**Domain events** — `OPERATING_PICTURE_VIEWED`, `JURISDICTION_SCOPE_SELECTED`, `COMMAND_TASK_ASSIGNED`, `SHIFT_HANDOFF_RECORDED`, `STALE_PANEL_FLAGGED`
**Acceptance gate** — Every tile states the age of its data, an unreachable or unsynchronized source is visibly distinguished from a healthy zero, drill-down resolves to the actual record, and the handoff summary is reproducible as a signed document.
**Role surface** — manager,county,state
**⚠ Caution** — A green tile must never be produced from stale or unreachable data; freshness is part of the reading, not decoration.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
02 · Election Calendar & Milestones
**What "built in full" means** *(blueprint, verbatim)*
> Versioned statutory and operational milestones, dependencies, authoritative-source citations, alerts, escalations and completion evidence.
**Purpose** — Hold the versioned statutory and operational milestone set for an election, with the authority behind each date and the evidence that closed it.
**Workflows**
- Load the jurisdiction milestone pack for an election and version it
- Link each milestone to its controlling authority and effective date
- Track dependencies so a slipped predecessor visibly moves what follows
- Alert and escalate on approaching and missed milestones
- Close a milestone only against attached completion evidence
**Primary data objects** — Milestone, MilestoneVersion, Dependency, SourceCitation, CompletionEvidence
**Domain events** — `MILESTONE_PACK_VERSIONED`, `MILESTONE_SCHEDULED`, `MILESTONE_AT_RISK`, `MILESTONE_ESCALATED`, `MILESTONE_CLOSED_WITH_EVIDENCE`
**Acceptance gate** — No milestone exists without a cited controlling authority and effective date, no milestone can be closed without evidence, and a superseded source raises a review flag on every milestone that cited it.
**Role surface** — manager,county,state
**⚠ Caution** — Dates are read from cited authority with effective dates; the module must never carry a hard-coded statutory deadline of its own.
**Shared services** — LockChain Ledger Core · Evidence Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core
03 · Jurisdiction Configuration Engine
**What "built in full" means** *(blueprint, verbatim)*
> Country/state/county/local inheritance, approved overrides, election-specific configuration, feature flags, configuration diff and rollback.
**Purpose** — Resolve the configuration that applies to a given jurisdiction and election through explicit inheritance and approved overrides, with a diff and a rollback path.
**Workflows**
- Define a baseline at country, state, county and local level and inherit downward
- Request, approve and record an override with its source authority and effective date
- Bind election-specific configuration and feature flags to a single election
- Diff two configuration versions before promotion
- Roll back a configuration version and record why
**Primary data objects** — JurisdictionNode, ConfigBaseline, ConfigOverride, FeatureFlag, ConfigVersion
**Domain events** — `CONFIG_BASELINE_PUBLISHED`, `CONFIG_OVERRIDE_REQUESTED`, `COUNTY_OVERRIDE_APPROVED`, `INHERITED_FROM_STATE`, `CONFIG_ROLLED_BACK`
**Acceptance gate** — Every resolved setting can name where it came from — inherited or approved override — with source authority and effective date, and a rollback restores the prior version without editing history.
**Role surface** — county,state
**⚠ Caution** — A larger jurisdiction is not a multiplication of a smaller one; each child inherits only what is actually common and every difference is recorded as an approved override.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core · Observability & Security Core
04 · Election Readiness Score
**What "built in full" means** *(blueprint, verbatim)*
> Evidence-backed operational-readiness controls with transparent weighting and missing-evidence flags. It must explicitly avoid claiming that a readiness score proves election validity.
**Purpose** — Express operational readiness as a transparent, evidence-backed control roll-up that flags what is missing instead of averaging it away.
**Workflows**
- Define the readiness control set for a jurisdiction and election
- Bind each control to the objective evidence that satisfies it
- Publish the weighting openly and show the arithmetic on demand
- Flag missing, stale and expired evidence as missing rather than as passing
- Export a readiness package with the standing disclaimer attached
**Primary data objects** — ReadinessControl, ControlWeighting, EvidenceBinding, ReadinessSnapshot, MissingEvidenceFlag
**Domain events** — `READINESS_CONTROL_DEFINED`, `READINESS_EVIDENCE_BOUND`, `READINESS_SNAPSHOT_TAKEN`, `MISSING_EVIDENCE_FLAGGED`, `READINESS_PACKAGE_EXPORTED`
**Acceptance gate** — Every point in the score traces to a specific piece of evidence, the weighting is visible wherever the score is, missing evidence is never silently treated as satisfied, and the disclaimer travels with every export.
**Role surface** — manager,county,state
**⚠ Caution** — The readiness score must explicitly avoid claiming that it proves election validity; it measures operational controls and evidence, nothing more.
**Shared services** — LockChain Ledger Core · Evidence Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Reporting & Document Core
05 · Election-Day Operations Console
**What "built in full" means** *(blueprint, verbatim)*
> Live tasks, location state, support requests, personnel/logistics, incident escalation, communications and offline synchronization state.
**Purpose** — Run the day: live tasks, location state, support requests, logistics, escalation, communications and an honest picture of what has not synchronized.
**Workflows**
- Dispatch and track tasks and support requests against locations and workers
- Escalate an incident from the console with timers and acknowledgements
- Push a communication to a location, a role or the whole fleet with delivery history
- Watch offline and degraded devices and the count of events waiting to sync
- Reassign personnel and logistics against live location state
**Primary data objects** — LiveTask, SupportRequest, Dispatch, CommunicationBroadcast, SyncState
**Domain events** — `SUPPORT_REQUEST_OPENED`, `TASK_DISPATCHED`, `DISPATCH_ACKNOWLEDGED`, `BROADCAST_DELIVERED`, `SYNC_BACKLOG_DETECTED`
**Acceptance gate** — The console never shows a device as healthy while its queue is unacknowledged, every dispatch has an acknowledgement or a visible absence of one, and the sync state distinguishes saved-locally from received-by-command.
**Role surface** — manager,county,state
**⚠ Caution** — A yellow saved-locally state must never be visually indistinguishable from a green received-by-county-command acknowledgement.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
06 · After-Action Command Center
**What "built in full" means** *(blueprint, verbatim)*
> Timeline, incident clustering, root-cause analysis, corrective actions, accountable owners, deadlines, training feedback and closure evidence.
**Purpose** — Turn an election into a reviewable record: one timeline, clustered incidents, root causes, owned corrective actions and evidence of closure.
**Workflows**
- Assemble the post-election timeline from custody, incident, equipment and audit events
- Cluster related incidents and test whether the cluster holds under review
- Record a root-cause analysis with the evidence it rests on
- Open corrective actions with accountable owners and deadlines
- Close a corrective action only against closure evidence, and feed findings into training
**Primary data objects** — AfterActionReview, IncidentCluster, RootCauseAnalysis, CorrectiveAction, ClosureEvidence
**Domain events** — `AFTER_ACTION_OPENED`, `INCIDENT_CLUSTER_FORMED`, `ROOT_CAUSE_RECORDED`, `CORRECTIVE_ACTION_ASSIGNED`, `CORRECTIVE_ACTION_CLOSED`
**Acceptance gate** — The timeline is rebuilt from ledger events rather than typed, every corrective action has an owner and a deadline, and closure requires evidence that survives independent verification.
**Role surface** — manager,county,state
**⚠ Caution** — Root-cause analysis records observations and findings; it does not assign motive or culpability the evidence does not support.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core
07 · Polling-Place Opening
**What "built in full" means** *(blueprint, verbatim)*
> Identity/role check, current opening checklist, facility inspection, equipment/seal references, supplies, exceptions, evidence and supervisor release.
**Purpose** — Take a location from closed to operational through the current approved opening sequence, with evidence at every step that requires it.
**Workflows**
- Check identity and role before any opening step is available
- Load the current version-locked opening checklist for this jurisdiction and election
- Record facility inspection, equipment references and seal verification with evidence
- Raise an exception when a step cannot be completed as written
- Request and record supervisor release before the location reports open
**Primary data objects** — OpeningRun, ChecklistStep, SealReference, OpeningException, SupervisorRelease
**Domain events** — `OPENING_STARTED`, `OPENING_STEP_COMPLETED`, `OPENING_EXCEPTION_RAISED`, `SUPERVISOR_RELEASE_GRANTED`, `LOCATION_REPORTED_OPEN`
**Acceptance gate** — The entire opening runs offline end to end, no step marked evidence-required can complete without evidence, the checklist version is locked at start, and the location cannot report open without a recorded supervisor release.
**Role surface** — worker,manager,county
**⚠ Caution** — Equipment and seals are referenced by inventory identifier and scan; the module never opens a control channel to a voting system.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core
08 · Polling-Place Closing
**What "built in full" means** *(blueprint, verbatim)*
> Closing sequence, reconciliation references, seal capture, equipment closeout, custody transfer, open-issue review and signed completion package.
**Purpose** — Close a location in the approved sequence and leave behind a signed completion package that a reviewer can verify later.
**Workflows**
- Run the version-locked closing sequence with reconciliation references
- Capture closing seals with scan and photo evidence
- Close out equipment and record its service state
- Hand custody of materials to the receiving custodian with acknowledgement
- Review open issues, then generate and sign the completion package
**Primary data objects** — ClosingRun, ReconciliationReference, SealCapture, CustodyTransfer, CompletionPackage
**Domain events** — `CLOSING_STARTED`, `CLOSING_SEAL_CAPTURED`, `EQUIPMENT_CLOSEOUT_RECORDED`, `CUSTODY_TRANSFER_ACKNOWLEDGED`, `COMPLETION_PACKAGE_SIGNED`
**Acceptance gate** — The completion package carries hashes, custody references and open-issue state, it is signed by an authorized role, and it verifies independently against the ledger after the fact.
**Role surface** — worker,manager,county
**⚠ Caution** — Reconciliation is referenced, not recomputed here, and no ballot content is ever read or stored by this module.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core
09 · Poll Worker Management
**What "built in full" means** *(blueprint, verbatim)*
> Worker roster, qualifications, shifts, attendance, replacement workflow, role restrictions and minimal sensitive-personnel exposure.
**Purpose** — Staff the fleet: who is qualified, who is assigned, who arrived, who replaced whom — while exposing the least personnel data that still lets the day run.
**Workflows**
- Maintain the roster with qualifications and role restrictions
- Assign shifts to locations and publish the assignment to the worker
- Record attendance and no-shows against the shift
- Run the replacement workflow when a shift cannot be covered
- Enforce field-level minimisation so a location sees only what it needs
**Primary data objects** — Worker, Qualification, ShiftAssignment, AttendanceRecord, ReplacementRequest
**Domain events** — `WORKER_QUALIFIED`, `SHIFT_ASSIGNED`, `ATTENDANCE_RECORDED`, `REPLACEMENT_REQUESTED`, `REPLACEMENT_APPROVED`
**Acceptance gate** — Sensitive personnel fields are redacted at the point of storage for surfaces that do not need them, role restrictions are enforced by authorization tests, and every replacement leaves an approval trail.
**Role surface** — manager,county,state
**⚠ Caution** — Minimal sensitive-personnel exposure is a hard requirement: the field surface sees assignment and role, not a personnel file.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
10 · Poll Worker Training
**What "built in full" means** *(blueprint, verbatim)*
> Versioned election-specific curriculum, scenario training, assessments, certifications, expirations and changed-procedure acknowledgement.
**Purpose** — Prove that the people running the election were trained on the version of the procedure that is actually in force.
**Workflows**
- Publish a versioned curriculum bound to a jurisdiction and election
- Run scenario training and record the outcome
- Score assessments and issue certifications with expiry dates
- Detect an expired or expiring certification before assignment
- Push a changed-procedure acknowledgement when a source or policy is superseded
**Primary data objects** — Curriculum, CurriculumVersion, TrainingScenario, Assessment, Certification
**Domain events** — `CURRICULUM_VERSION_PUBLISHED`, `TRAINING_COMPLETED`, `ASSESSMENT_SCORED`, `CERTIFICATION_ISSUED`, `CHANGED_PROCEDURE_ACKNOWLEDGED`
**Acceptance gate** — A certification names the curriculum version and the procedure version it covers, expiry is enforced rather than advisory, and a superseded procedure produces an acknowledgement task for everyone who trained on the old one.
**Role surface** — worker,manager,county,state
**⚠ Caution** — A certification against a superseded procedure version must read as stale, never as current.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core
11 · Polling-Place Checklist
**What "built in full" means** *(blueprint, verbatim)*
> Conditional checklist engine, evidence-required steps, dual verification, offline execution, exceptions and version locking.
**Purpose** — Provide the conditional checklist engine every field procedure runs on, with evidence, dual verification, offline execution and a locked version.
**Workflows**
- Author and publish a conditional checklist as a versioned artifact
- Lock the version at run start so a mid-run publication cannot change the run
- Branch steps on location, equipment, role and election conditions
- Require evidence or a second verifier on steps that demand it
- Record an exception with reason and route it for review
**Primary data objects** — ChecklistDefinition, ChecklistVersion, ChecklistRun, StepEvidence, DualVerification
**Domain events** — `CHECKLIST_VERSION_LOCKED`, `CHECKLIST_RUN_STARTED`, `STEP_EVIDENCE_ATTACHED`, `DUAL_VERIFICATION_RECORDED`, `CHECKLIST_EXCEPTION_RAISED`
**Acceptance gate** — A run completes fully offline, the locked version is reproducible from the ledger, an evidence-required step cannot be skipped, and dual verification requires two distinct authenticated identities.
**Role surface** — worker,manager,county
**⚠ Caution** — Dual verification means two distinct people; one device and one session can never satisfy both halves.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core
12 · Supply & Inventory Management
**What "built in full" means** *(blueprint, verbatim)*
> Supply kits, scanning, stock thresholds, issue/return, controlled materials, lost/damaged items and warehouse reconciliation.
**Purpose** — Track kits and controlled materials from warehouse to location and back, with thresholds, exceptions and a reconciliation that has to balance.
**Workflows**
- Build and scan supply kits against a location and election
- Issue and return kits with custodian acknowledgement
- Watch stock thresholds and trigger replenishment
- Record lost, damaged and controlled-material exceptions
- Reconcile issued against returned at the warehouse and close variances
**Primary data objects** — SupplyKit, SupplyItem, IssueRecord, ReturnRecord, InventoryVariance
**Domain events** — `KIT_ASSEMBLED`, `KIT_ISSUED`, `KIT_RETURNED`, `CONTROLLED_MATERIAL_EXCEPTION`, `WAREHOUSE_RECONCILED`
**Acceptance gate** — Controlled materials reconcile item by item, a variance cannot be closed without a reason and an approver, and scanning works with no connectivity.
**Role surface** — worker,manager,county
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Notifications & Escalation Core · Reporting & Document Core
13 · Wait-Time / Capacity Monitoring
**What "built in full" means** *(blueprint, verbatim)*
> Timed observations, stale-data indicators, trends, capacity thresholds, dispatch triggers and authorized public-feed adapter.
**Purpose** — Turn timed human observations into capacity signal, with the age of every reading visible and a public feed that only publishes what is authorized.
**Workflows**
- Record a timed observation at a location with observer and method
- Mark a reading stale once it passes its jurisdiction-configured age
- Trend capacity against thresholds across the fleet
- Trigger dispatch when a threshold is breached and stays breached
- Publish through an authorized public-feed adapter with its own approval
**Primary data objects** — WaitObservation, CapacityThreshold, CapacityTrend, DispatchTrigger, PublicFeedAdapter
**Domain events** — `WAIT_OBSERVATION_RECORDED`, `OBSERVATION_MARKED_STALE`, `CAPACITY_THRESHOLD_BREACHED`, `DISPATCH_TRIGGERED`, `PUBLIC_FEED_PUBLISHED`
**Acceptance gate** — No reading is displayed without its age, a stale reading is visibly stale everywhere including the public feed, and the public adapter cannot publish without an authorization record.
**Role surface** — worker,manager,county,state
**⚠ Caution** — An observation is an observation: the module reports what was measured and when, and never presents an extrapolation as a measurement.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
14 · Accessibility Compliance
**What "built in full" means** *(blueprint, verbatim)*
> Site inspection, accessible route, service/equipment availability, digital accessibility checks, remediation and verification.
**Purpose** — Inspect, remediate and verify the accessibility of the physical site, the accessible route, the services offered and the digital surfaces used.
**Workflows**
- Run a site inspection against the jurisdiction inspection pack
- Record the accessible route with evidence and any obstruction
- Confirm accessible service and equipment availability at the location
- Run digital accessibility checks on the surfaces in use
- Open remediation with an owner, then verify the fix on site
**Primary data objects** — SiteInspection, AccessibleRoute, AccessibleService, AccessibilityFinding, RemediationVerification
**Domain events** — `SITE_INSPECTED`, `ACCESSIBLE_ROUTE_RECORDED`, `ACCESSIBILITY_FINDING_OPENED`, `REMEDIATION_ASSIGNED`, `REMEDIATION_VERIFIED`
**Acceptance gate** — A finding closes only on verified remediation with evidence, the inspection runs offline, and the digital checks are run against the rendered surface rather than asserted.
**Role surface** — worker,manager,county,state
**⚠ Caution** — WCAG 2.2 applies to the field surfaces themselves; the module cannot report accessibility while being inaccessible.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
15 · Ballot Inventory
**What "built in full" means** *(blueprint, verbatim)*
> Batch/container inventory, counts, location, seals, controlled count adjustments, reconciliation and exceptions—without storing voter selections.
**Purpose** — Know what ballot material exists, in what batch or container, in what quantity, under what seal, at what location — at the batch level only.
**Workflows**
- Register batches and containers with counts, location and seal references
- Adjust a count only through a controlled, reasoned and approved adjustment
- Reconcile inventory against transfers and custody history
- Raise and route an inventory exception
- Export an inventory position with provenance for each figure
**Primary data objects** — BallotBatch, BallotContainer, CountAdjustment, SealReference, InventoryException
**Domain events** — `BATCH_REGISTERED`, `CONTAINER_SEALED`, `COUNT_ADJUSTMENT_APPROVED`, `INVENTORY_RECONCILED`, `INVENTORY_EXCEPTION_RAISED`
**Acceptance gate** — A schema test proves no field can hold a voter selection, every count change is an approved adjustment event rather than an overwrite, and every displayed figure names where it came from.
**Role surface** — worker,manager,county
**⚠ Caution** — Batch and container level only — without storing voter selections, ever, in any field, derivative or export.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core
16 · Ballot Transfer
**What "built in full" means** *(blueprint, verbatim)*
> Transfer orders, sending/receiving custodians, seals, dual acknowledgement where required, transport state and discrepancies.
**Purpose** — Move ballot material between custodians under an order, with seals, acknowledgements on both ends and a discrepancy path when the two ends disagree.
**Workflows**
- Raise a transfer order naming sending and receiving custodians
- Seal, scan and photograph containers at dispatch
- Track transport state between origin and destination
- Capture receiving acknowledgement, with dual acknowledgement where the jurisdiction requires it
- Open a discrepancy when counts, seals or timing do not match, and route it
**Primary data objects** — TransferOrder, Custodian, SealApplication, TransportState, TransferDiscrepancy
**Domain events** — `TRANSFER_ORDER_ISSUED`, `TRANSFER_DISPATCHED`, `TRANSFER_ACKNOWLEDGED`, `DUAL_ACKNOWLEDGEMENT_RECORDED`, `TRANSFER_DISCREPANCY_OPENED`
**Acceptance gate** — Both ends of every transfer are recorded or the transfer stands visibly open, dual acknowledgement requires two distinct identities, and the full sequence works offline with idempotent replay on reconnect.
**Role surface** — worker,manager,county
**⚠ Caution** — Until a county formally accepts the electronic procedure, the existing county documentation remains the controlling record and BB2G runs in parallel.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
17 · Ballot Chain of Custody
**What "built in full" means** *(blueprint, verbatim)*
> Append-oriented custody history, seals, timestamps, custodians, locations, evidence, LockChain receipts, gap detection and exports.
**Purpose** — Hold the append-only custody history for ballot material and prove, with receipts, that the sequence has not been altered — and show where it has gaps.
**Workflows**
- Append a custody event with custodian, location, seal state, time and evidence
- Issue a LockChain receipt for each custody event and retain verification material
- Detect and surface undocumented intervals and sequence gaps
- Correct an erroneous entry by appending a correction that links to the original
- Export a custody history with hashes and independent verification instructions
**Primary data objects** — CustodyEvent, CustodyChain, SealState, CustodyGap, CustodyReceipt
**Domain events** — `CUSTODY_EVENT_APPENDED`, `CUSTODY_RECEIPT_ISSUED`, `CUSTODY_GAP_DETECTED`, `CUSTODY_EVENT_CORRECTED`, `CUSTODY_HISTORY_EXPORTED`
**Acceptance gate** — History is append-only with no update path in the API or the database, a correction is a new event linked with CORRECTS, gap detection is poison-tested against a removed and a reordered event, and an export verifies outside the application.
**Role surface** — worker,manager,county,state
**⚠ Caution** — Receipts demonstrate provenance, sequence and integrity of the recorded bytes. They do not establish that an allegation inside those bytes is true, and the export language must say so.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
18 · Mail-Ballot Workflow
**What "built in full" means** *(blueprint, verbatim)*
> Batch-level operational stages and custody while minimizing duplication of protected voter information.
**Purpose** — Track the operational stages and custody of mail-ballot material at batch level without becoming a second copy of the voter file.
**Workflows**
- Advance a batch through the jurisdiction-configured operational stages
- Attach custody events and seals at each stage boundary
- Reference the official system of record instead of copying protected voter data
- Raise an exception when a batch stalls or a stage is skipped
- Report stage throughput and ageing at batch level
**Primary data objects** — MailBallotBatch, ProcessingStage, StageTransition, CustodyEvent, BatchException
**Domain events** — `MAIL_BATCH_CREATED`, `MAIL_STAGE_ADVANCED`, `MAIL_BATCH_CUSTODY_RECORDED`, `MAIL_BATCH_STALLED`, `MAIL_BATCH_EXCEPTION_RAISED`
**Acceptance gate** — A data-minimisation test proves the module holds references rather than duplicated protected voter information, stages are jurisdiction-configured rather than hard-coded, and every stage transition carries custody.
**Role surface** — worker,manager,county
**⚠ Caution** — Minimize duplication of protected voter information: reference the official system of record, do not mirror it.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core
19 · Provisional-Ballot Workflow
**What "built in full" means** *(blueprint, verbatim)*
> Material/custody/process tracking while keeping eligibility decisions with authorized election officials and official systems.
**Purpose** — Track provisional material, custody and process state while the eligibility determination itself stays entirely outside this module.
**Workflows**
- Register provisional material at the location with custody
- Track process state and the tasks each state requires
- Record that a determination was made in the official system, with a pointer, never the reasoning
- Raise an exception for missing material or a stalled process
- Report provisional operational status without exposing eligibility rationale
**Primary data objects** — ProvisionalMaterial, ProcessState, CustodyEvent, OfficialDeterminationPointer, ProvisionalException
**Domain events** — `PROVISIONAL_MATERIAL_REGISTERED`, `PROVISIONAL_CUSTODY_RECORDED`, `PROVISIONAL_STATE_ADVANCED`, `OFFICIAL_DETERMINATION_REFERENCED`, `PROVISIONAL_EXCEPTION_RAISED`
**Acceptance gate** — There is no code path, field or API in this module that can express an eligibility decision, and an authorization test proves the determination pointer is read-only and sourced from the official system.
**Role surface** — worker,manager,county
**⚠ Caution** — Eligibility decisions stay with authorized election officials and official systems. This module tracks material, custody and process only.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core
20 · Ballot Reconciliation
**What "built in full" means** *(blueprint, verbatim)*
> Expected-versus-actual counts, source provenance, transparent formulas, variances, second review, exceptions and closure.
**Purpose** — Compare expected against actual at batch level with the formula and the provenance of every input shown, and close variances through a second review.
**Workflows**
- Assemble expected and actual figures, each read at a pointer with its source named
- Show the reconciliation formula in full rather than a computed total alone
- Open a variance when the two sides disagree
- Route the variance to a second reviewer who did not produce it
- Close the reconciliation with an exception record for anything unresolved
**Primary data objects** — ReconciliationRun, CountInput, ReconciliationFormula, Variance, SecondReview
**Domain events** — `RECONCILIATION_STARTED`, `COUNT_INPUT_SOURCED`, `VARIANCE_OPENED`, `SECOND_REVIEW_RECORDED`, `RECONCILIATION_CLOSED`
**Acceptance gate** — No figure is typed where it could be read at a pointer, every figure names its source, the formula is visible wherever the result is, and the second reviewer cannot be the same identity as the preparer.
**Role surface** — manager,county,state
**⚠ Caution** — A variance is a variance: the module reports the difference and requires review, and never characterises the cause.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
21 · Ballot Storage & Retention
**What "built in full" means** *(blueprint, verbatim)*
> Secure storage registry, access history, seals, retention schedules, legal holds, disposition approval and certificates.
**Purpose** — Register secure storage, log every access, apply retention schedules and legal holds, and produce a certificate when disposition is finally approved.
**Workflows**
- Register storage locations, containers and their seals
- Log every access with identity, purpose and time
- Apply the applicable retention schedule from the rules engine
- Place and release a legal hold that overrides scheduled disposition
- Approve disposition and issue a signed certificate of disposition
**Primary data objects** — StorageLocation, StorageContainer, AccessRecord, RetentionSchedule, DispositionCertificate
**Domain events** — `STORAGE_REGISTERED`, `STORAGE_ACCESS_LOGGED`, `RETENTION_APPLIED`, `LEGAL_HOLD_PLACED`, `DISPOSITION_CERTIFICATE_ISSUED`
**Acceptance gate** — A legal hold blocks disposition in code and not only in policy, every access is logged with purpose, and a disposition certificate verifies independently against the ledger.
**Role surface** — manager,county,state
**⚠ Caution** — Storage and retention integrity is an integrity layer in its own right: inappropriate deletion during a retention period must be prevented or detected, not merely discouraged.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
22 · Voting Equipment Registry
**What "built in full" means** *(blueprint, verbatim)*
> Asset/serial/model/version/certification references, location, custody, service status and history, with no unauthorized control channel.
**Purpose** — Hold the authoritative operational record of each piece of voting equipment — identity, location, custody and service state — without ever touching the equipment.
**Workflows**
- Register an asset with serial, model, version and certification reference
- Move an asset between locations with custody and acknowledgement
- Record service status and the full service history
- Import approved metadata through manual, scan or approved offline-file paths
- Report equipment position across the fleet for an election
**Primary data objects** — EquipmentAsset, AssetIdentifier, CertificationReference, CustodyEvent, ServiceStatus
**Domain events** — `ASSET_REGISTERED`, `ASSET_CUSTODY_TRANSFERRED`, `ASSET_LOCATION_CHANGED`, `ASSET_SERVICE_STATUS_CHANGED`, `ASSET_METADATA_IMPORTED`
**Acceptance gate** — A network test proves the module has no outbound path to a voting system, every import arrives through an approved manual, scan or offline-file route, and the registry never claims a certification fact it did not read from a source record.
**Role surface** — worker,manager,county,state
**⚠ Caution** — No unauthorized control channel, and no one-click connect to a tabulator. Equipment enters through inventory identifiers, approved metadata, manual or scan workflows, authorized offline files, or a specifically approved isolation/import architecture.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Reporting & Document Core · Observability & Security Core
23 · Equipment Testing
**What "built in full" means** *(blueprint, verbatim)*
> Test plans, equipment scope, witnesses, test artifacts, failures, remediation, retesting and approval.
**Purpose** — Run equipment testing against an approved plan with named witnesses, retained artifacts and an approval that only comes after remediation is retested.
**Workflows**
- Author and approve a test plan with its equipment scope
- Record witnesses present for the test
- Attach test artifacts as evidence with hashes
- Log a failure, assign remediation, then retest
- Approve the test only when every failure is closed or accepted with reason
**Primary data objects** — TestPlan, EquipmentScope, Witness, TestArtifact, TestFailure
**Domain events** — `TEST_PLAN_APPROVED`, `TEST_EXECUTED`, `TEST_ARTIFACT_ATTACHED`, `TEST_FAILURE_LOGGED`, `RETEST_APPROVED`
**Acceptance gate** — An approval cannot be recorded while an open failure exists without an explicit reasoned acceptance, artifacts are hashed on capture, and witnesses are recorded as identities rather than typed names.
**Role surface** — manager,county,state
**⚠ Caution** — Testing is documented in BB2G; it is executed on the equipment through the approved procedure, never driven by BB2G.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
24 · Logic & Accuracy Documentation
**What "built in full" means** *(blueprint, verbatim)*
> L&A schedules, equipment references, authorized procedure, witnesses/observers, artifacts, exceptions and post-election records.
**Purpose** — Document logic and accuracy activity: schedule, equipment in scope, the authorized procedure followed, who witnessed it and what it produced.
**Workflows**
- Schedule an L&A session and publish it to authorized observers
- Bind the session to the equipment references in scope
- Load the authorized procedure version in force for the jurisdiction and election
- Record witnesses and observers present, and attach artifacts
- Record exceptions and retain the post-election L&A record
**Primary data objects** — LASession, LASchedule, AuthorizedProcedureVersion, ObserverAttendance, LAArtifact
**Domain events** — `LA_SESSION_SCHEDULED`, `LA_PROCEDURE_VERSION_BOUND`, `LA_OBSERVER_RECORDED`, `LA_ARTIFACT_ATTACHED`, `LA_EXCEPTION_RECORDED`
**Acceptance gate** — The procedure version in force is bound at session start and reproducible afterwards, observer attendance is recorded without collecting more about observers than attendance requires, and post-election records survive retention.
**Role surface** — manager,county,state
**⚠ Caution** — The authorized procedure comes from the jurisdiction source pack with its effective date; the module must not carry its own copy of the procedure.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Reporting & Document Core
25 · Equipment Seal Tracking
**What "built in full" means** *(blueprint, verbatim)*
> Seal inventory, application, verification, scan/photo evidence, mismatch workflow, replacement and dual verification.
**Purpose** — Track tamper-evident seals from inventory through application, verification, mismatch and replacement, with evidence at every touch.
**Workflows**
- Receive seals into inventory as controlled stock
- Apply a seal to an asset or container with scan and photo evidence
- Verify an expected seal value against the observed value
- Run the mismatch workflow when the two differ, with dual verification
- Replace a seal and link the replacement to the seal it superseded
**Primary data objects** — Seal, SealApplication, SealVerification, SealMismatch, SealReplacement
**Domain events** — `SEAL_RECEIVED`, `SEAL_APPLIED`, `SEAL_VERIFIED`, `SEAL_MISMATCH_DETECTED`, `SEAL_REPLACED`
**Acceptance gate** — A mismatch cannot be cleared by one person alone, every application and verification carries scan or photo evidence, the workflow runs offline, and seal stock reconciles.
**Role surface** — worker,manager,county
**⚠ Caution** — On a mismatch the system states that the expected value differs from the observed value and that review is required. It does not infer the cause.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
26 · Device Configuration Registry
**What "built in full" means** *(blueprint, verbatim)*
> Approved baselines, version/hash references, configuration validation, drift detection and change approval.
**Purpose** — Hold approved configuration baselines with version and hash references, validate devices against them and surface drift as an approvable change or a finding.
**Workflows**
- Publish an approved baseline with version and hash references
- Validate an observed device configuration against its baseline
- Detect drift and classify it
- Route a drift to change approval or to a security finding
- Retain the baseline history so a past state is reconstructible
**Primary data objects** — ConfigurationBaseline, BaselineVersion, DeviceConfiguration, DriftFinding, ChangeApproval
**Domain events** — `BASELINE_PUBLISHED`, `CONFIGURATION_VALIDATED`, `CONFIGURATION_DRIFT_DETECTED`, `CHANGE_APPROVED`, `BASELINE_SUPERSEDED`
**Acceptance gate** — Validation compares hashes rather than labels, drift is never auto-remediated on a voting-system asset, and every baseline change has an approver and an effective date.
**Role surface** — manager,county,state
**⚠ Caution** — Detection only on voting-system assets: BB2G observes and reports configuration state and never pushes a configuration to one.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
27 · Maintenance / Failure Tracking
**What "built in full" means** *(blueprint, verbatim)*
> Failure tickets, triage, dispatch, replacement equipment, parts, downtime, remediation and return-to-service evidence.
**Purpose** — Carry an equipment failure from the field report to return-to-service, with dispatch, replacement, parts, downtime and closing evidence.
**Workflows**
- Open a failure ticket from the field, offline if necessary
- Triage severity and impact, and dispatch a technician
- Issue replacement equipment with custody
- Record parts used and downtime accrued
- Close on return-to-service evidence
**Primary data objects** — FailureTicket, TriageAssessment, TechnicianDispatch, ReplacementIssue, DowntimeRecord
**Domain events** — `FAILURE_REPORTED`, `FAILURE_TRIAGED`, `TECHNICIAN_DISPATCHED`, `REPLACEMENT_ISSUED`, `RETURN_TO_SERVICE_RECORDED`
**Acceptance gate** — A ticket opened offline reaches command with its original timestamps intact, replacement equipment carries custody, and return-to-service requires evidence rather than an assertion.
**Role surface** — worker,manager,county
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
28 · Certified-System Reference Center
**What "built in full" means** *(blueprint, verbatim)*
> Live EAC and state certification/approval references, version mapping, systems under test, withdrawals, source history and freshness.
**Purpose** — Mirror federal and state certification and approval references as living source records, with version mapping, withdrawals, history and an explicit freshness state.
**Workflows**
- Retrieve certification and approval source records and hash them at section level
- Map a certification record to the equipment versions in the registry
- Track systems under test as a changing state, not a fixed list
- Record withdrawals and supersessions without discarding the previous state
- Display source-last-checked, current status and the source record for every claim
**Primary data objects** — CertificationRecord, ApprovalReference, SystemUnderTest, SourceSnapshot, FreshnessState
**Domain events** — `CERT_SOURCE_CHECKED`, `CERT_RECORD_UPDATED`, `CERT_RECORD_WITHDRAWN`, `SYSTEM_UNDER_TEST_CHANGED`, `SOURCE_MARKED_STALE`
**Acceptance gate** — Every certification claim in the UI carries source-last-checked, status and a link to the source record; a stale source degrades the display instead of silently serving old data; and a test proves no certification count or list is baked into the code.
**Role surface** — manager,county,state
**⚠ Caution** — Never hard-code a certification count or a fixed list of certified systems. The interface reads: source last checked, current status, certification record, previous state retained. Note also that migration between guideline versions does not itself decertify previously certified systems, and state law may impose its own requirements.
**Shared services** — LockChain Ledger Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
29 · Evidence Vault
**What "built in full" means** *(blueprint, verbatim)*
> Immutable originals, hashes, classifications, metadata, custody, legal holds, access history, controlled previews and exports.
**Purpose** — Store originals immutably with hashes, classification and custody, and control every preview, export and access against them.
**Workflows**
- Ingest an original, hash it, and write it once
- Classify the item and attach metadata and custody
- Place and release legal holds
- Serve a controlled preview or derivative without releasing the original
- Log every access with identity and purpose, and export under approval
**Primary data objects** — EvidenceItem, EvidenceHash, Classification, LegalHold, AccessRecord
**Domain events** — `EVIDENCE_INGESTED`, `EVIDENCE_CLASSIFIED`, `LEGAL_HOLD_PLACED`, `EVIDENCE_ACCESS_LOGGED`, `EVIDENCE_EXPORTED`
**Acceptance gate** — Originals are write-once with no update path, a legal hold blocks deletion in code, classification drives permission, every access is logged, and re-hashing any stored original reproduces its recorded hash.
**Role surface** — manager,county,state
**⚠ Caution** — Permission attaches to the value, not to the page: a classified item stays classified through every derivative, preview and export.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core · Observability & Security Core
30 · Immutable Audit Log
**What "built in full" means** *(blueprint, verbatim)*
> Append-only canonical events, hash chain, signed checkpoints, key rotation, independent verification and tamper alerts.
**Purpose** — Be the ledger: canonicalize every significant operation into an append-only hash-chained event stream with signed checkpoints and independent verification.
**Workflows**
- Canonicalize an event and compute its payload and event hashes
- Append to the chain with the previous event hash and issue a receipt
- Cut and sign a checkpoint, and rotate signing keys on schedule
- Verify record, sequence, signer and retention integrity independently of the application
- Raise a tamper alert when verification fails
**Primary data objects** — CanonicalEvent, HashChain, Checkpoint, SigningKey, VerificationReport
**Domain events** — `EVENT_CANONICALIZED`, `EVENT_APPENDED`, `CHECKPOINT_SIGNED`, `SIGNING_KEY_ROTATED`, `TAMPER_ALERT_RAISED`
**Acceptance gate** — A third implementation, run by the reader, verifies the chain and the checkpoint signatures; removal, insertion and reordering are each poison-tested and each fail verification; signing keys live outside the application database; and no API can edit a historical event — a correction is a new event carrying CORRECTS.
**Role surface** — county,state
**⚠ Caution** — Describe this publicly as tamper-evident, never as magically immutable. A privileged attacker holding every database, key, checkpoint and backup could fabricate a replacement history, which is exactly why keys, checkpoints and backups are separated and independently verifiable.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Reporting & Document Core · Observability & Security Core
31 · Evidence Provenance
**What "built in full" means** *(blueprint, verbatim)*
> Origin, collector, capture method, custody, derivation graph, tools/versions, source relationships and findings linkage.
**Purpose** — Record where a piece of evidence came from, who collected it how, what was derived from it with which tool, and what findings rest on it.
**Workflows**
- Record origin, collector and capture method at ingestion
- Build the derivation graph as derivatives are produced
- Record the tool and version used for each derivation
- Link source relationships between related items
- Link findings back to the evidence they rest on
**Primary data objects** — ProvenanceRecord, CaptureMethod, DerivationEdge, ToolVersion, FindingLink
**Domain events** — `PROVENANCE_RECORDED`, `DERIVATIVE_CREATED`, `TOOL_VERSION_RECORDED`, `SOURCE_RELATIONSHIP_LINKED`, `FINDING_LINKED_TO_EVIDENCE`
**Acceptance gate** — Every derivative resolves back to an original through a complete, unbroken graph, no derivation exists without a recorded tool and version, and a finding cannot be published without at least one evidence link.
**Role surface** — manager,county,state
**⚠ Caution** — Provenance answers where a record came from and how it was handled. It does not evaluate whether the content is true.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Reporting & Document Core
32 · Photo / Video Evidence Capture
**What "built in full" means** *(blueprint, verbatim)*
> Managed-device capture, encrypted offline storage, upload acknowledgement, metadata, restricted originals and redaction derivatives.
**Purpose** — Capture photo and video on managed devices, hold it encrypted offline until acknowledged, and release only redacted derivatives by default.
**Workflows**
- Capture on a managed, enrolled device with device identity bound to the media
- Store encrypted locally and queue for upload
- Confirm server receipt and show an unambiguous acknowledgement state
- Attach capture metadata and classification
- Produce a redaction derivative and restrict the original
**Primary data objects** — MediaCapture, DeviceIdentity, UploadQueueItem, CaptureMetadata, RedactionDerivative
**Domain events** — `MEDIA_CAPTURED`, `MEDIA_QUEUED_ENCRYPTED`, `MEDIA_UPLOAD_ACKNOWLEDGED`, `REDACTION_DERIVATIVE_CREATED`, `ORIGINAL_ACCESS_RESTRICTED`
**Acceptance gate** — Capture is refused on an unmanaged device, local storage is encrypted at rest, the acknowledged state is visually distinct from the queued state, and the original is unreachable to any role that only holds derivative permission.
**Role surface** — worker,manager,county
**⚠ Caution** — Redact at the point of storage: a derivative is generated for release, and the original stays restricted rather than being trimmed after the fact.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Reporting & Document Core · Observability & Security Core
33 · Document Authentication
**What "built in full" means** *(blueprint, verbatim)*
> Hash/signature verification, trusted-source registry, version comparison and explicit distinction among integrity, authority and truth.
**Purpose** — Verify document hashes and signatures against a trusted-source registry, compare versions, and state plainly what verification does and does not establish.
**Workflows**
- Register a trusted source and its verification material
- Verify a document hash and signature against that registry
- Compare two versions of a document section by section
- Report a verification result in three separate axes: integrity, authority, truth
- Record a failed verification as a finding rather than discarding it
**Primary data objects** — DocumentRecord, TrustedSource, VerificationResult, VersionComparison, IntegrityFinding
**Domain events** — `TRUSTED_SOURCE_REGISTERED`, `DOCUMENT_VERIFIED`, `VERIFICATION_FAILED`, `VERSION_COMPARED`, `INTEGRITY_FINDING_RAISED`
**Acceptance gate** — The result surface always separates integrity, authority and truth, verification runs against known-good and known-bad fixtures in the test suite, and a failure is recorded and alerted rather than swallowed.
**Role surface** — manager,county,state
**⚠ Caution** — Maintain the explicit distinction among integrity, authority and truth. A verified signature shows the bytes are unaltered and who signed them; it says nothing about whether the content is correct.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Election Knowledge Currency Engine · Reporting & Document Core
34 · Audit Workspace
**What "built in full" means** *(blueprint, verbatim)*
> Scope, sampling, workpapers, evidence requests, findings, management responses and closure.
**Purpose** — Give auditors a working surface: defined scope, defensible sampling, workpapers, evidence requests, findings, responses and closure.
**Workflows**
- Define audit scope and record the sampling method and its parameters
- Maintain workpapers linked to the evidence they cite
- Issue an evidence request and track its fulfilment
- Raise a finding and record the management response
- Close the audit with a report that reproduces from its own workpapers
**Primary data objects** — AuditEngagement, SamplingPlan, Workpaper, EvidenceRequest, AuditFinding
**Domain events** — `AUDIT_SCOPE_DEFINED`, `SAMPLE_DRAWN`, `EVIDENCE_REQUEST_ISSUED`, `AUDIT_FINDING_RAISED`, `AUDIT_CLOSED`
**Acceptance gate** — The sample is reproducible from its recorded parameters and seed, every finding cites a workpaper which cites evidence, and management responses are attributed and time-stamped.
**Role surface** — county,state
**⚠ Caution** — Explicitly not exposed to ordinary field users: the Audit Workspace does not belong in a poll worker’s cognitive environment.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
35 · Evidence Export / Legal Package Generator
**What "built in full" means** *(blueprint, verbatim)*
> Manifest, hashes, provenance, custody history, redactions, index, approvals and independent verification instructions.
**Purpose** — Assemble a self-verifying legal package: manifest, hashes, provenance, custody, applied redactions, index, approvals and instructions to verify it without BB2G.
**Workflows**
- Select the scope of a package and resolve every included item
- Generate a manifest with hashes and a human-readable index
- Apply and record the redactions the classification requires
- Route the package for approval before release
- Emit independent verification instructions alongside the package
**Primary data objects** — EvidencePackage, PackageManifest, RedactionRecord, PackageApproval, VerificationInstructions
**Domain events** — `PACKAGE_ASSEMBLED`, `PACKAGE_MANIFEST_HASHED`, `REDACTION_APPLIED`, `PACKAGE_APPROVED`, `PACKAGE_RELEASED`
**Acceptance gate** — A recipient with no BB2G access can verify every hash and the chain position of every item using only the instructions in the package, and an unapproved package cannot be released.
**Role surface** — manager,county,state
**⚠ Caution** — The package proves provenance, sequence, integrity and accountable handling. The verification instructions must say, in the package itself, that this is not proof that any allegation inside the records is true.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
36 · Incident Intake
**What "built in full" means** *(blueprint, verbatim)*
> Sub-minute structured reporting, category, urgency, location, evidence, offline submission and immediate-safety branch.
**Purpose** — Let a field user report a structured incident in under a minute, offline, with an immediate-safety branch that comes first.
**Workflows**
- Ask the immediate-danger question before anything else and branch on the answer
- Capture category, urgency, location and description in a structured form
- Attach photo or video evidence from the managed device
- Submit offline into the encrypted queue and show an honest queued state
- Confirm server receipt distinctly from local save
**Primary data objects** — Incident, IncidentCategory, UrgencyLevel, IncidentEvidence, SubmissionState
**Domain events** — `INCIDENT_REPORTED`, `IMMEDIATE_DANGER_PATH_TAKEN`, `INCIDENT_EVIDENCE_ATTACHED`, `INCIDENT_QUEUED_OFFLINE`, `INCIDENT_RECEIVED_BY_COMMAND`
**Acceptance gate** — A timed test proves a routine report completes in under a minute on a field device, the whole flow works with no connectivity, and the queued state can never be mistaken for the received state.
**Role surface** — worker,manager,county,state
**⚠ Caution** — The form separates observed behaviour from interpretation and from suspected motive, and never asks the reporter to diagnose why.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Observability & Security Core
37 · Incident Triage
**What "built in full" means** *(blueprint, verbatim)*
> Urgency/impact rubric, responsible team, current procedure retrieval, assignment and transparent reclassification.
**Purpose** — Classify an incident against a published rubric, retrieve the current procedure for it, assign it, and make every reclassification visible.
**Workflows**
- Score urgency and impact against the published rubric
- Retrieve the current applicable procedure with its authority and effective date
- Route to the responsible team and assign an owner
- Reclassify with a reason that is retained alongside the original classification
- Escalate when triage thresholds are met
**Primary data objects** — TriageAssessment, UrgencyImpactRubric, ResponsibleTeam, ProcedureRetrieval, Reclassification
**Domain events** — `INCIDENT_TRIAGED`, `PROCEDURE_RETRIEVED`, `INCIDENT_ASSIGNED`, `INCIDENT_RECLASSIFIED`, `TRIAGE_THRESHOLD_MET`
**Acceptance gate** — The rubric is visible to whoever is being scored by it, a reclassification never overwrites the prior classification, and procedure retrieval abstains rather than guessing when current authority cannot be established.
**Role surface** — manager,county,state
**⚠ Caution** — If the current authority for a procedure cannot be established, the module says so and routes to a human instead of retrieving a stale procedure silently.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · AI Election Copilot · Notifications & Escalation Core · Reporting & Document Core
38 · Incident Escalation
**What "built in full" means** *(blueprint, verbatim)*
> Jurisdiction-specific escalation matrix, timers, acknowledgements, SME routing, executive escalation and documented de-escalation.
**Purpose** — Drive escalation off a jurisdiction-specific matrix with real timers, real acknowledgements, subject-matter routing and a documented way back down.
**Workflows**
- Load the jurisdiction escalation matrix for the incident type
- Start escalation timers and record acknowledgements against them
- Route to a subject-matter expert when the matrix calls for one
- Escalate to executive level when timers expire unacknowledged
- De-escalate with a documented reason and an accountable approver
**Primary data objects** — EscalationMatrix, EscalationTimer, Acknowledgement, SMERouting, DeEscalationRecord
**Domain events** — `ESCALATION_STARTED`, `ESCALATION_TIMER_EXPIRED`, `ESCALATION_ACKNOWLEDGED`, `EXECUTIVE_ESCALATION_TRIGGERED`, `DE_ESCALATION_DOCUMENTED`
**Acceptance gate** — A timer that expires unacknowledged always escalates, delivery history is retained per channel, and de-escalation requires a reason and an approver rather than a silent close.
**Role surface** — worker,manager,county,state
**⚠ Caution** — An escalation path that has never been tested is not an escalation path; timers and delivery must be poison-tested against a dead channel.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
39 · Physical Security
**What "built in full" means** *(blueprint, verbatim)*
> Facility zones, locks/access controls, cameras, lighting, keys, alarms, observations, findings and remediation.
**Purpose** — Hold the physical security posture of each facility — zones, access controls, cameras, lighting, keys, alarms — and drive observations to remediation.
**Workflows**
- Define facility zones and their access controls
- Register keys, alarms, cameras and lighting as tracked controls
- Record an observation during a walk-through with evidence
- Raise a finding and assign remediation with a deadline
- Verify remediation and close the finding
**Primary data objects** — Facility, SecurityZone, AccessControl, SecurityObservation, SecurityFinding
**Domain events** — `FACILITY_ZONE_DEFINED`, `ACCESS_CONTROL_REGISTERED`, `SECURITY_OBSERVATION_RECORDED`, `SECURITY_FINDING_RAISED`, `SECURITY_REMEDIATION_VERIFIED`
**Acceptance gate** — Key custody reconciles, a finding closes only on verified remediation, and observations record what was seen and when rather than a conclusion about it.
**Role surface** — manager,county,state
**⚠ Caution** — Physical security, chain of custody, system security, incident response and continuity are interconnected; a finding here must be linkable to the custody and cyber records it touches.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
40 · Emergency Response
**What "built in full" means** *(blueprint, verbatim)*
> Large HELP control, immediate-danger path, evacuation/shelter guidance, command notification, continuity and recovery.
**Purpose** — Give the field one large, unmistakable HELP control that asks the right question first and then serves the jurisdiction-approved procedure.
**Workflows**
- Present the large HELP control and ask whether anyone is in immediate danger
- On yes, display the jurisdiction-approved emergency procedure and the emergency-services option
- On no, offer the structured urgent categories: threat or disturbance, medical, equipment or safety hazard, need supervisor, need security assistance, other urgent issue
- Notify command immediately with location and reporter
- Serve evacuation or shelter guidance, then continuity and recovery steps
**Primary data objects** — EmergencyActivation, DangerBranch, ApprovedEmergencyProcedure, CommandNotification, ContinuityStep
**Domain events** — `HELP_ACTIVATED`, `IMMEDIATE_DANGER_CONFIRMED`, `APPROVED_PROCEDURE_DISPLAYED`, `COMMAND_NOTIFIED`, `CONTINUITY_MODE_ENTERED`
**Acceptance gate** — The emergency procedure is available offline on every field device, the danger question always precedes any action, command notification is proven under degraded connectivity, and an unacknowledged activation escalates.
**Role surface** — worker,manager,county,state
**⚠ Caution** — Not every button press is a police call. The immediate-danger question comes first, and the non-danger branch routes to the structured urgent categories instead.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Observability & Security Core
41 · Threat / Safety Reporting
**What "built in full" means** *(blueprint, verbatim)*
> Threats, harassment, hazards and safety concerns with restricted identities, evidence and protective-action workflow.
**Purpose** — Take reports of threats, harassment, hazards and safety concerns with the reporter and subject identities restricted, and drive protective action.
**Workflows**
- Accept a report with restricted identity handling by default
- Attach evidence without widening who can see the identities
- Assess and open a protective action
- Route to the authorized handler only, with access logged
- Track the protective action to a documented outcome
**Primary data objects** — ThreatReport, RestrictedIdentity, SafetyConcern, ProtectiveAction, HandlerAssignment
**Domain events** — `THREAT_REPORTED`, `IDENTITY_RESTRICTED`, `PROTECTIVE_ACTION_OPENED`, `HANDLER_ASSIGNED`, `PROTECTIVE_ACTION_CLOSED`
**Acceptance gate** — An authorization test proves identities are unreachable outside the authorized handler set, every access to a restricted identity is logged, and the record separates observed behaviour from interpretation and from suspected motive.
**Role surface** — worker,manager,county,state
**⚠ Caution** — A person can be agitated, make a threat or violate a rule without the software attempting to diagnose why. Record the behaviour, restrict the identity, route to a human.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core
42 · Election Worker Safety
**What "built in full" means** *(blueprint, verbatim)*
> Safety briefings, check-ins, de-escalation tools, buddy rules, post-incident support and training.
**Purpose** — Look after the people: briefings, check-ins, de-escalation aids, buddy rules and support after something happens.
**Workflows**
- Deliver and acknowledge a safety briefing for the shift
- Run scheduled check-ins and flag a missed one
- Serve de-escalation and situational-awareness tools at the point of need
- Enforce buddy rules for defined tasks and locations
- Offer post-incident support and record only that support was offered and accepted
**Primary data objects** — SafetyBriefing, CheckIn, DeEscalationTool, BuddyRule, PostIncidentSupport
**Domain events** — `SAFETY_BRIEFING_ACKNOWLEDGED`, `CHECK_IN_RECORDED`, `CHECK_IN_MISSED`, `BUDDY_RULE_ENFORCED`, `POST_INCIDENT_SUPPORT_OFFERED`
**Acceptance gate** — A missed check-in raises an alert rather than only a log line, de-escalation tools are available offline, and post-incident support records participation without recording clinical content.
**Role surface** — worker,manager,county
**⚠ Caution** — Support records are minimal by design: who was offered support and whether they accepted, never the content of it.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core
43 · Election Cyber Command
**What "built in full" means** *(blueprint, verbatim)*
> BB2G/supporting-system alerts, asset risk, identity events, integrations and incident status, with system-boundary labels.
**Purpose** — Give security operations one picture of BB2G and supporting systems, with every panel labelled by the system boundary it actually covers.
**Workflows**
- Aggregate alerts from BB2G and integrated supporting systems
- Show asset risk and identity events in one place
- Label every panel with the system boundary it covers and what it does not
- Track open cyber incidents to closure
- Escalate on unacknowledged critical alerts
**Primary data objects** — SecurityAlert, SystemBoundary, AssetRisk, IdentityEvent, IntegrationStatus
**Domain events** — `SECURITY_ALERT_RAISED`, `BOUNDARY_LABEL_APPLIED`, `IDENTITY_EVENT_OBSERVED`, `INTEGRATION_DEGRADED`, `CYBER_INCIDENT_OPENED`
**Acceptance gate** — No panel is displayed without its system-boundary label, an integration that has stopped reporting shows as unknown rather than as clean, and every critical alert has an acknowledgement or a visible absence of one.
**Role surface** — county,state
**⚠ Caution** — A quiet panel for a system BB2G does not monitor must read as out of scope, never as secure.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
44 · Asset Inventory
**What "built in full" means** *(blueprint, verbatim)*
> Endpoints, applications, servers, services, integrations, owners, software components, lifecycle and criticality.
**Purpose** — Maintain the inventory of endpoints, applications, servers, services and integrations with owners, components, lifecycle and criticality.
**Workflows**
- Register an asset with an accountable owner and a criticality rating
- Record software components and their versions
- Track lifecycle from procurement through end of support
- Reconcile discovered assets against registered ones and flag the difference
- Flag an asset past end of support or without an owner
**Primary data objects** — CyberAsset, SoftwareComponent, AssetOwner, LifecycleStage, CriticalityRating
**Domain events** — `CYBER_ASSET_REGISTERED`, `SOFTWARE_COMPONENT_RECORDED`, `ASSET_OWNER_ASSIGNED`, `LIFECYCLE_STAGE_CHANGED`, `UNOWNED_ASSET_FLAGGED`
**Acceptance gate** — Every asset has an accountable owner or is visibly flagged, discovered-but-unregistered assets are surfaced rather than silently merged, and criticality is used by the risk and vulnerability modules rather than being decorative.
**Role surface** — county,state
**⚠ Caution** — Voting-system assets are inventoried as references only; discovery must never reach across the boundary into them.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Reporting & Document Core · Observability & Security Core
45 · Network / System Risk Registry
**What "built in full" means** *(blueprint, verbatim)*
> Risks, affected assets, likelihood/impact rationale, controls, owners, treatment, residual risk and acceptance.
**Purpose** — Hold risks with the reasoning behind them: affected assets, likelihood and impact rationale, controls, treatment, residual risk and who accepted it.
**Workflows**
- Open a risk against named assets with a written likelihood and impact rationale
- Map controls to the risk and record their effectiveness
- Assign a treatment plan and an accountable owner
- Compute and record residual risk after treatment
- Record a formal risk acceptance with the accepting authority and a review date
**Primary data objects** — Risk, AffectedAsset, Control, TreatmentPlan, RiskAcceptance
**Domain events** — `RISK_REGISTERED`, `CONTROL_MAPPED`, `TREATMENT_ASSIGNED`, `RESIDUAL_RISK_RECORDED`, `RISK_ACCEPTED`
**Acceptance gate** — No risk score exists without a written rationale, an acceptance names an authority and a review date, and an accepted risk past its review date resurfaces automatically.
**Role surface** — county,state
**⚠ Caution** — Explicitly not exposed to ordinary field users: the Cyber Risk Register does not belong in a poll worker’s cognitive environment.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
46 · Vulnerability Management
**What "built in full" means** *(blueprint, verbatim)*
> Vulnerability intake/scanning for authorized BB2G systems, prioritization, remediation, exception and retest.
**Purpose** — Take in and scan for vulnerabilities on authorized BB2G systems only, prioritise them against asset criticality, and retest what was fixed.
**Workflows**
- Intake a vulnerability from a report or an authorized scan
- Check the target against the authorization register before any scan runs
- Prioritise against asset criticality and exposure
- Assign remediation, or record a time-bound exception with an approver
- Retest and close only on a passing retest
**Primary data objects** — Vulnerability, ScanAuthorization, ApprovedTestPlan, RemediationTask, RetestResult
**Domain events** — `VULNERABILITY_INTAKEN`, `SCAN_AUTHORIZATION_CHECKED`, `SCAN_BLOCKED_UNAUTHORIZED_TARGET`, `REMEDIATION_ASSIGNED`, `RETEST_PASSED`
**Acceptance gate** — A poison test aims a scan at a registered voting-system target and proves it is blocked with the message that an explicit authorization and an approved test plan are required; no exception can be open-ended; and closure requires a passing retest, not an assertion.
**Role surface** — county,state
**⚠ Caution** — Voting-system target detected: the automated security scan is blocked unless an explicit authorization and an approved test plan exist. A scanner creates operational risk of its own, and cybersecurity is never a justification for casually probing an election system.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
47 · Access-Control Monitoring
**What "built in full" means** *(blueprint, verbatim)*
> MFA, accounts, privileged access, device trust, authentication anomalies, revocation and periodic certification.
**Purpose** — Watch the identity layer: MFA coverage, account state, privileged access, device trust, anomalies, revocation and periodic recertification.
**Workflows**
- Monitor MFA enrolment and coverage across accounts
- Track privileged access grants with expiry
- Evaluate device trust before granting a session
- Detect authentication anomalies and route them
- Run periodic access certification and revoke what is not recertified
**Primary data objects** — Account, PrivilegedGrant, DeviceTrustState, AuthenticationAnomaly, AccessCertification
**Domain events** — `MFA_ENROLLED`, `PRIVILEGED_ACCESS_GRANTED`, `DEVICE_TRUST_EVALUATED`, `AUTH_ANOMALY_DETECTED`, `ACCESS_REVOKED`
**Acceptance gate** — Privileged grants expire by default, a failed device-trust evaluation denies rather than warns, uncertified access is revoked on schedule, and every revocation is provable from the ledger.
**Role surface** — county,state
**⚠ Caution** — Trust is not inferred from network location or affiliation; every session is evaluated on identity, device and scope.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
48 · Cyber Incident Response
**What "built in full" means** *(blueprint, verbatim)*
> Preparation, detection, analysis, containment, eradication, recovery, communication, evidence and after-action.
**Purpose** — Run a cyber incident through the full lifecycle with evidence preserved at each phase and an after-action that produces owned actions.
**Workflows**
- Maintain preparation artifacts: playbooks, contacts, exercise records
- Move an incident through detection, analysis, containment, eradication and recovery
- Preserve evidence at each phase into the Evidence Vault under legal hold
- Run communications with approval and delivery history
- Complete an after-action with owned corrective actions
**Primary data objects** — CyberIncident, ResponsePhase, ContainmentAction, ResponseCommunication, AfterActionItem
**Domain events** — `CYBER_INCIDENT_DECLARED`, `RESPONSE_PHASE_ENTERED`, `CONTAINMENT_ACTION_TAKEN`, `RESPONSE_COMMUNICATION_APPROVED`, `CYBER_AFTER_ACTION_CLOSED`
**Acceptance gate** — Evidence is preserved before containment destroys it, every external communication carries an approval, and the incident cannot close with an unassigned after-action item.
**Role surface** — county,state
**⚠ Caution** — The response record describes what was observed and what was done. Attribution is a conclusion and requires evidence and, in some contexts, legal determination.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
49 · Backup / Recovery / Continuity
**What "built in full" means** *(blueprint, verbatim)*
> Encrypted backups, isolated copies, restore testing, RPO/RTO, continuity mode and disaster exercises.
**Purpose** — Prove the system can come back: encrypted backups, isolated copies, tested restores, declared RPO and RTO, a continuity mode and rehearsed disasters.
**Workflows**
- Run and verify encrypted backups, including an isolated copy
- Execute a restore test and record the measured time and data loss
- Compare measured results against declared RPO and RTO
- Enter and exit continuity mode with a documented decision
- Schedule and record disaster exercises with findings
**Primary data objects** — BackupJob, IsolatedCopy, RestoreTest, RPORTOTarget, DisasterExercise
**Domain events** — `BACKUP_COMPLETED`, `ISOLATED_COPY_VERIFIED`, `RESTORE_TEST_EXECUTED`, `CONTINUITY_MODE_ENTERED`, `DISASTER_EXERCISE_COMPLETED`
**Acceptance gate** — A restore is actually performed and measured rather than asserted, the isolated copy is proven unreachable from production credentials, and a backup that has never been restored is reported as unverified.
**Role surface** — county,state
**⚠ Caution** — Backup and retention controls are kept separate from the application and its signing keys; a single compromised administrator must not be able to rewrite history and its backups together.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core · Observability & Security Core
50 · Election Anomaly Review
**What "built in full" means** *(blueprint, verbatim)*
> Explainable detection rules, source quality, trigger reason, human review, disposition and false-positive feedback.
**Purpose** — Surface operational anomalies through rules a human can read, with the trigger reason stated, and route every one of them to human review.
**Workflows**
- Author an explainable detection rule with its inputs and thresholds
- Evaluate the rule and record why it fired, in plain language
- Rate the quality of the sources the rule used
- Route to human review and record a reasoned disposition
- Feed false positives back to tune the rule, with the change versioned
**Primary data objects** — DetectionRule, AnomalyTrigger, SourceQualityRating, HumanReview, FalsePositiveFeedback
**Domain events** — `DETECTION_RULE_PUBLISHED`, `ANOMALY_TRIGGERED`, `TRIGGER_REASON_RECORDED`, `ANOMALY_REVIEWED`, `FALSE_POSITIVE_RECORDED`
**Acceptance gate** — Every trigger states its reason in language the reviewer can check, no anomaly can reach a disposition without a named human, and a language gate proves no output path can emit a fraud, conspiracy, tampering, suppression or malfeasance conclusion.
**Role surface** — manager,county,state
**⚠ Caution** — Explainable rules, human review, and no automatic fraud conclusion. The system may say the expected seal value differs from the observed value and review is required. It may not say fraud, criminal conspiracy, election tampering, intentional suppression or malfeasance.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
51 · Cross-Jurisdiction Pattern Engine
**What "built in full" means** *(blueprint, verbatim)*
> Normalized operational events, privacy-preserving comparisons, tenant/data-sharing controls and review cases.
**Purpose** — Compare normalized operational events across jurisdictions under explicit sharing controls, and open a review case when a pattern holds.
**Workflows**
- Normalize operational events into a shared comparison schema
- Apply tenant and data-sharing controls before any comparison runs
- Run privacy-preserving comparisons that do not move underlying records
- Open a review case when a pattern crosses its threshold
- Record the disposition of the case back to each participating tenant
**Primary data objects** — NormalizedEvent, SharingAgreement, ComparisonRun, PatternCandidate, ReviewCase
**Domain events** — `EVENT_NORMALIZED`, `SHARING_CONTROL_APPLIED`, `COMPARISON_RUN_EXECUTED`, `PATTERN_CANDIDATE_RAISED`, `CROSS_JURISDICTION_CASE_OPENED`
**Acceptance gate** — A comparison is impossible without an active sharing agreement, a re-identification test proves no participant can recover another tenant’s underlying records from the comparison output, and a pattern is a candidate for review rather than a finding.
**Role surface** — county,state
**⚠ Caution** — Statewide analytics is explicitly not exposed to ordinary field users, and a correlation is stated as a correlation detected, never as a cause.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core · Observability & Security Core
52 · Timeline Correlation
**What "built in full" means** *(blueprint, verbatim)*
> Chronological linking of incidents, custody, equipment, communication and audit events with timestamp-quality metadata.
**Purpose** — Build one chronology across incidents, custody, equipment, communications and audit events, and carry the quality of each timestamp with it.
**Workflows**
- Assemble a timeline from ledger events across modules
- Attach timestamp-quality metadata: source clock, offline capture, sync delay, precision
- Link related events into a correlation with a stated basis
- Show gaps and undocumented intervals explicitly
- Export the timeline with its quality metadata intact
**Primary data objects** — TimelineView, TimelineEntry, TimestampQuality, CorrelationLink, TimelineGap
**Domain events** — `TIMELINE_ASSEMBLED`, `TIMESTAMP_QUALITY_ASSESSED`, `CORRELATION_LINKED`, `TIMELINE_GAP_DETECTED`, `TIMELINE_EXPORTED`
**Acceptance gate** — A timestamp captured offline and synced later is visually distinguished from one recorded live, gaps are shown rather than smoothed, and no correlation is displayed without the basis on which it was drawn.
**Role surface** — manager,county,state
**⚠ Caution** — A correlation is a correlation. The module reports that events co-occurred and how confidently they are timed, and never asserts that one caused the other.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Reporting & Document Core
53 · Relationship / Entity Mapping
**What "built in full" means** *(blueprint, verbatim)*
> Operational graph of facilities, assets, vendors, incidents, organizations, personnel roles and documents, each relationship sourced.
**Purpose** — Maintain an operational graph of facilities, assets, vendors, incidents, organizations, personnel roles and documents, with a source on every edge.
**Workflows**
- Register entities within the permitted operational entity types
- Create a relationship only with a cited source record
- Traverse the graph within the caller’s jurisdiction and classification scope
- Review and retire relationships whose source has been superseded
- Export a scoped subgraph with its sources attached
**Primary data objects** — GraphEntity, Relationship, RelationshipSource, EntityType, GraphScope
**Domain events** — `ENTITY_REGISTERED`, `RELATIONSHIP_ASSERTED`, `RELATIONSHIP_SOURCE_ATTACHED`, `RELATIONSHIP_RETIRED`, `SUBGRAPH_EXPORTED`
**Acceptance gate** — No edge can be created without a source record, an entity-type allow-list is enforced in the schema, and a poison test proves the graph cannot express a political attribute or affiliation for a voter, poll worker or observer.
**Role surface** — county,state
**⚠ Caution** — Automatic political profiling of voters, poll workers or observers based on unrelated data is prohibited. The graph principally concerns assets, locations, organizations, vendors, incidents, documents, responsibilities and authorized operational personnel relationships. The Entity Graph is also not exposed to ordinary field users.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
54 · Human Review & Disposition
**What "built in full" means** *(blueprint, verbatim)*
> Evidence review, conflict disclosure, reasoned disposition, second review, appeal/reopen and permanent attribution.
**Purpose** — Be the place a human decides: review the evidence, disclose conflicts, give reasons, get a second review, and stay permanently attributed.
**Workflows**
- Assign a review and require conflict-of-interest disclosure before it opens
- Present the evidence with its provenance and quality
- Record a reasoned disposition attributed to the reviewer
- Route to a second reviewer who is not the first
- Handle an appeal or reopen without erasing the original disposition
**Primary data objects** — ReviewAssignment, ConflictDisclosure, Disposition, SecondReview, AppealRecord
**Domain events** — `REVIEW_ASSIGNED`, `CONFLICT_DISCLOSED`, `DISPOSITION_RECORDED`, `SECOND_REVIEW_COMPLETED`, `DISPOSITION_APPEALED`
**Acceptance gate** — A disposition without reasons cannot be saved, the second reviewer is enforced as a distinct identity, attribution is permanent and survives a reopen, and a reopen appends rather than replaces.
**Role surface** — manager,county,state
**⚠ Caution** — The reviewer works up the ladder deliberately: DATA, OBSERVATION, ALLEGATION, ANOMALY, EVIDENCE, FINDING, CONCLUSION. The UI must not let a step be skipped silently.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Notifications & Escalation Core · Reporting & Document Core
55 · Public Records Repository
**What "built in full" means** *(blueprint, verbatim)*
> Classified source records, searchable authorized derivatives, release versions, provenance and retention.
**Purpose** — Hold classified source records and serve only authorized, searchable derivatives with release versions, provenance and retention attached.
**Workflows**
- Ingest and classify a source record
- Generate an authorized derivative for search and release
- Version each release and retain the superseded ones
- Attach provenance and retention to every record and derivative
- Serve search over derivatives only, scoped by classification
**Primary data objects** — SourceRecord, AuthorizedDerivative, ReleaseVersion, ProvenanceRecord, RetentionBinding
**Domain events** — `SOURCE_RECORD_INGESTED`, `DERIVATIVE_AUTHORIZED`, `RELEASE_VERSION_PUBLISHED`, `RECORD_RETENTION_BOUND`, `DERIVATIVE_SEARCHED`
**Acceptance gate** — Search cannot reach an unauthorized source record through any query path, a released derivative names its release version and provenance, and retention is bound at ingestion rather than applied later.
**Role surface** — manager,county,state
**⚠ Caution** — Permission attaches to the value: a redacted derivative is what is searchable and releasable, and the classified source stays behind it.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
56 · FOIA / Public Records Request Manager
**What "built in full" means** *(blueprint, verbatim)*
> Jurisdiction-specific request rules, deadlines, custodian tasks, search logs, redaction/review, production and appeals.
**Purpose** — Run a public-records request end to end under the rule pack of the jurisdiction that actually governs it.
**Workflows**
- Register a PublicRecordsRequest and load the applicable jurisdiction rule pack
- Compute deadlines from that rule pack, never from a default
- Assign custodian search tasks and log every search performed
- Run redaction and review with the basis recorded for each redaction
- Produce the response, and handle an appeal as a linked proceeding
**Primary data objects** — PublicRecordsRequest, JurisdictionRulePack, CustodianTask, SearchLog, ProductionPackage
**Domain events** — `RECORDS_REQUEST_RECEIVED`, `RULE_PACK_APPLIED`, `CUSTODIAN_SEARCH_LOGGED`, `REDACTION_BASIS_RECORDED`, `PRODUCTION_RELEASED`
**Acceptance gate** — The domain model is generically named and carries no federal-statute assumption, a request cannot proceed without a resolved jurisdiction rule pack, every redaction records a basis, and the search log reconstructs what was actually searched.
**Role surface** — manager,county,state
**⚠ Caution** — This is not "everything is FOIA." Federal FOIA and state and local public-records laws are different legal regimes. The domain object is a generic PublicRecordsRequest that loads the appropriate jurisdiction rule pack.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core
57 · Statute & Regulation Library
**What "built in full" means** *(blueprint, verbatim)*
> Section-level legal/procedural corpus, jurisdiction, effective dates, court-order overlays, supersession and verification.
**Purpose** — Hold the legal and procedural corpus at section level with jurisdiction, effective dates, court-order overlays, supersession and human verification.
**Workflows**
- Retrieve a source and hash it section by section
- Bind each section to a jurisdiction and an effective date
- Overlay a court order onto the sections it affects
- Detect a change or a supersession and open a verification task
- Resolve the controlling authority for a question of jurisdiction, election and date
**Primary data objects** — LegalSource, CorpusSection, EffectiveDateRange, CourtOrderOverlay, VerificationTask
**Domain events** — `LEGAL_SOURCE_RETRIEVED`, `SECTION_HASHED`, `SECTION_SUPERSEDED`, `COURT_ORDER_OVERLAID`, `SECTION_HUMAN_VERIFIED`
**Acceptance gate** — Currency is asserted at section level and never at page level, a section that has not been human-verified since its last change is marked unverified everywhere it is cited, and the resolver returns the controlling authority with its reasoning rather than a bare answer.
**Role surface** — county,state
**⚠ Caution** — Retrieving a page today does not make every paragraph on it current, which is why sections carry their own dates and require human verification. The resolver must not reason that a federal source outranks controlling state law; it asks what jurisdiction, what authority, what instrument type, what effective date, what election, whether superseded and whether a more specific controlling authority applies. Legal Source Administration is also not exposed to ordinary field users.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core
58 · Retention Rules Engine
**What "built in full" means** *(blueprint, verbatim)*
> Record classes, federal/state/local retention, holds, conflicts, disposition approval and certificates.
**Purpose** — Decide how long each record class must be kept under overlapping federal, state and local rules, surface conflicts, and certify disposition.
**Workflows**
- Define record classes and map records to them
- Resolve the applicable retention period across federal, state and local rules
- Surface a conflict between rules rather than silently picking one
- Apply and release holds that override scheduled disposition
- Approve disposition and issue a certificate
**Primary data objects** — RecordClass, RetentionRule, RetentionConflict, RetentionHold, DispositionCertificate
**Domain events** — `RECORD_CLASS_DEFINED`, `RETENTION_RESOLVED`, `RETENTION_CONFLICT_RAISED`, `RETENTION_HOLD_APPLIED`, `DISPOSITION_APPROVED`
**Acceptance gate** — Where rules conflict the longest applicable period is applied and the conflict is printed rather than smoothed, a hold blocks disposition in code, and no disposition happens without an approval and a certificate.
**Role surface** — county,state
**⚠ Caution** — Explicitly not exposed to ordinary field users: Retention Rules do not belong in a poll worker’s cognitive environment.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Reporting & Document Core
59 · Policy / Procedure Management
**What "built in full" means** *(blueprint, verbatim)*
> Draft, review, approval, effective date, publication, targeted acknowledgement, supersession and rollback.
**Purpose** — Carry a policy or procedure from draft through approval, effective date and publication, with targeted acknowledgement, supersession and rollback.
**Workflows**
- Draft a procedure and route it through review to approval
- Set an effective date and publish it to the jurisdictions it binds
- Target acknowledgement at the roles the change actually affects
- Supersede the prior version and retain it
- Roll back to a prior version with a recorded reason
**Primary data objects** — Policy, PolicyVersion, ApprovalRecord, PublicationScope, Acknowledgement
**Domain events** — `POLICY_DRAFTED`, `POLICY_APPROVED`, `POLICY_PUBLISHED`, `POLICY_ACKNOWLEDGED`, `POLICY_SUPERSEDED`
**Acceptance gate** — A procedure cannot be effective before its approval, the version in force for any past date is reconstructible, acknowledgement is tracked per person and per version, and a rollback is an event rather than an edit.
**Role surface** — worker,manager,county,state
**⚠ Caution** — With the statute library, this is the foundation the Copilot stands on: an answer is only as current as the policy version and effective date behind it.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Notifications & Escalation Core · Reporting & Document Core
60 · Compliance Evidence Generator
**What "built in full" means** *(blueprint, verbatim)*
> Control mapping, objective evidence, gap analysis, freshness/expiration and exportable compliance packages.
**Purpose** — Map controls to objective evidence, show the gaps and the staleness honestly, and export a compliance package that stands up to inspection.
**Workflows**
- Map a control framework onto BB2G controls and modules
- Bind objective evidence to each control
- Run gap analysis and list the unmapped and unevidenced controls
- Track evidence freshness and expiry
- Export a compliance package with manifest and verification instructions
**Primary data objects** — ControlFramework, ControlMapping, ObjectiveEvidence, ComplianceGap, CompliancePackage
**Domain events** — `FRAMEWORK_MAPPED`, `CONTROL_EVIDENCE_BOUND`, `COMPLIANCE_GAP_IDENTIFIED`, `EVIDENCE_EXPIRED`, `COMPLIANCE_PACKAGE_EXPORTED`
**Acceptance gate** — A control with expired evidence reads as not evidenced rather than as satisfied, gaps appear in the export instead of being omitted, and the package verifies independently.
**Role surface** — manager,county,state
**⚠ Caution** — A stamp cannot carry a caveat: if a control is only partially evidenced the package must say so in the control row, not in a footnote.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Election Knowledge Currency Engine · Reporting & Document Core
61 · Observer Management
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve rather than fold into the sixty. Accreditation, scheduling and attendance for authorized observers at the activities where observation is provided for, with the minimum personal information the activity requires.
**Purpose** — Manage authorized observer accreditation, scheduling and attendance for observable activities, collecting only what attendance requires.
**Workflows**
- Register an observer and the organization they represent
- Accredit the observer for a jurisdiction and election under the applicable rules
- Schedule observers against observable activities such as testing sessions
- Record attendance at the activity
- Record and route an observer-related incident without profiling the observer
**Primary data objects** — Observer, ObserverOrganization, Accreditation, ObservableActivity, AttendanceRecord
**Domain events** — `OBSERVER_REGISTERED`, `OBSERVER_ACCREDITED`, `OBSERVER_SCHEDULED`, `OBSERVER_ATTENDANCE_RECORDED`, `OBSERVER_ACCREDITATION_REVOKED`
**Acceptance gate** — Accreditation rules come from the jurisdiction rule pack rather than from code, attendance is recorded without collecting more than attendance requires, and a data test proves no political attribute can be stored against an observer.
**Role surface** — manager,county,state
**⚠ Caution** — Automatic political profiling of observers is prohibited; this module records accreditation, schedule and attendance only.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
62 · Warehouse Logistics
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. The warehouse side of the supply and equipment chain: receiving, staging, pick and pack, load out, return processing and cycle counts, feeding the same custody spine as the field.
**Purpose** — Run the warehouse behind the fleet: receive, stage, pick, load out, return and count, with custody continuous from dock to location and back.
**Workflows**
- Receive stock and equipment into the warehouse with custody
- Stage and pick kits and assets against a location schedule
- Load out to a route with a custodian and acknowledgement
- Process returns and route damaged or missing items to exception
- Run cycle counts and reconcile against the registry
**Primary data objects** — WarehouseLocation, ReceivingRecord, PickList, LoadOut, CycleCount
**Domain events** — `STOCK_RECEIVED`, `PICK_LIST_COMPLETED`, `LOAD_OUT_DISPATCHED`, `RETURN_PROCESSED`, `CYCLE_COUNT_RECONCILED`
**Acceptance gate** — Warehouse custody events join the same chain as field custody with no gap at the dock, cycle counts reconcile against the equipment and supply registries, and every variance carries a reason and an approver.
**Role surface** — worker,manager,county
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Notifications & Escalation Core · Reporting & Document Core
63 · Election Communications
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Approved internal and external communications for an election: templates, approval, targeted distribution, delivery history and a retained record of what was sent, to whom and when.
**Purpose** — Send approved communications to the right audience through the right channel, and retain a verifiable record of every send.
**Workflows**
- Author a communication from an approved template
- Route it for approval before any external send
- Target an audience by role, location, jurisdiction or election
- Deliver across channels and retain delivery history per recipient
- Retain the sent record under the applicable retention schedule
**Primary data objects** — CommunicationTemplate, CommunicationDraft, CommunicationApproval, AudienceSegment, DeliveryRecord
**Domain events** — `COMMUNICATION_DRAFTED`, `COMMUNICATION_APPROVED`, `COMMUNICATION_SENT`, `DELIVERY_CONFIRMED`, `DELIVERY_FAILED`
**Acceptance gate** — No external communication leaves without a recorded approval, delivery success and failure are both retained per recipient, and the sent record is retained and produceable under a public-records request.
**Role surface** — manager,county,state
**⚠ Caution** — Public-facing communications carry no address or phone contact surface, and an unapproved draft can never be sent.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core
64 · Facility Acquisition
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Sourcing and securing polling and support facilities: candidate sites, suitability and accessibility survey, agreement, scheduling, readiness handover and release.
**Purpose** — Find, assess, secure and release the facilities an election runs in, with accessibility assessed before the agreement rather than after.
**Workflows**
- Register a candidate facility and its contact of record
- Survey suitability, capacity and accessibility on site
- Negotiate and record an agreement with its term and conditions
- Schedule the facility to an election and hand it over ready
- Release the facility with a condition record at the end of the term
**Primary data objects** — CandidateFacility, SuitabilitySurvey, AccessibilityAssessment, FacilityAgreement, FacilityHandover
**Domain events** — `FACILITY_CANDIDATE_REGISTERED`, `FACILITY_SURVEYED`, `FACILITY_AGREEMENT_EXECUTED`, `FACILITY_HANDOVER_COMPLETED`, `FACILITY_RELEASED`
**Acceptance gate** — A facility cannot be scheduled to an election without a completed accessibility assessment or a recorded, approved mitigation, and the handover and release condition records both carry evidence.
**Role surface** — manager,county,state
**⚠ Caution** — Accessibility findings from the survey flow to the accessibility module as findings; they are never closed inside a procurement workflow.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Reporting & Document Core
65 · Courier Operations
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Courier teams, routes, assignments and transport-state tracking into the command centre, joined to the transfer and custody record rather than parallel to it.
**Purpose** — Run courier teams and routes with transport state visible to command and every leg joined to the ballot transfer and custody chain.
**Workflows**
- Form courier teams under the composition rules the jurisdiction requires
- Plan a route with its stops and expected timing
- Assign a transfer order to a route leg
- Track transport state into the command centre with consent-scoped location handling
- Close a leg against the receiving acknowledgement and open a discrepancy where it does not match
**Primary data objects** — CourierTeam, CourierRoute, RouteLeg, TransportState, RouteException
**Domain events** — `COURIER_TEAM_FORMED`, `ROUTE_PLANNED`, `LEG_STARTED`, `LEG_LOCATION_REPORTED`, `LEG_CLOSED`
**Acceptance gate** — Every leg resolves to a transfer order and a custody event, team composition rules are enforced rather than advisory, location tracking is scoped to the active leg only, and a leg that closes without a receiving acknowledgement raises a discrepancy.
**Role surface** — worker,manager,county
**⚠ Caution** — Courier location is operational tracking bound to an active leg; it is not personnel surveillance and must stop when the leg closes.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Observability & Security Core
66 · Election Scenario Exercises
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Design, run and evaluate tabletop and field exercises — offline exercise, disaster exercise, incident-response test — with findings that become owned corrective actions.
**Purpose** — Rehearse the failure modes before they happen and turn what the rehearsal exposes into owned corrective actions.
**Workflows**
- Design a scenario with objectives, injects and participants
- Run the exercise in an environment clearly marked as an exercise
- Record observations and participant performance against the objectives
- Produce findings and assign corrective actions with owners and deadlines
- Retain the exercise record as production-acceptance evidence
**Primary data objects** — ExerciseScenario, ExerciseInject, ExerciseRun, ExerciseObservation, ExerciseFinding
**Domain events** — `SCENARIO_DESIGNED`, `EXERCISE_STARTED`, `INJECT_DELIVERED`, `EXERCISE_FINDING_RAISED`, `EXERCISE_CLOSED`
**Acceptance gate** — Exercise data is unmistakably marked as exercise data in every surface and export and can never enter the controlling operational record, and every exercise finding produces an owned corrective action.
**Role surface** — worker,manager,county,state
**⚠ Caution** — Nothing produced during an exercise becomes the controlling official record; the marking must be structural, not a banner.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Offline Sync Core · Notifications & Escalation Core · Reporting & Document Core
67 · MDM Fleet Management
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Enrollment, policy state, health, application version and retirement for the managed tablet fleet the field surfaces depend on — the device side of the identity and offline cores.
**Purpose** — Keep the managed device fleet enrolled, compliant, current and accounted for, since managed devices are a precondition of field capture and field authorization.
**Workflows**
- Enroll a device and bind it to a device identity
- Evaluate policy compliance and report drift
- Track application version and push an update to the fleet
- Monitor device health, storage and the size of the offline queue
- Retire, wipe and account for a device at end of life or on loss
**Primary data objects** — ManagedDevice, EnrollmentRecord, DevicePolicyState, AppVersionState, RetirementRecord
**Domain events** — `DEVICE_ENROLLED`, `DEVICE_POLICY_EVALUATED`, `DEVICE_NONCOMPLIANT`, `DEVICE_APP_UPDATED`, `DEVICE_RETIRED`
**Acceptance gate** — A non-compliant or unenrolled device cannot capture evidence or hold an authorized session, a lost device can be retired and its queued events accounted for, and fleet-wide version state is visible to command.
**Role surface** — county,state
**⚠ Caution** — Device management covers BB2G managed devices only; it has no reach into voting-system equipment of any kind.
**Shared services** — LockChain Ledger Core · Identity & Authorization Core · Offline Sync Core · Notifications & Escalation Core · Observability & Security Core
68 · Vendor Assurance
**Named by the blueprint, not specified by it.** The blueprint lists this
module as existing BB2G functionality to preserve, without a "built in full"
paragraph. The summary below is this build's own honest description, not a
quotation:
> Named in the blueprint as existing BB2G functionality to preserve. Vendor and supplier registry, contract and service obligations, security and privacy review, access grants, performance and incident history, and offboarding.
**Purpose** — Know who has access and obligations to the election operation, on what terms, reviewed how recently, and remove it cleanly when the relationship ends.
**Workflows**
- Register a vendor with its services, contacts and criticality
- Record contract and service obligations and their review dates
- Run a security and privacy review and record the outcome
- Grant, review and revoke vendor access to BB2G systems and facilities
- Track vendor incidents and offboard with access revocation verified
**Primary data objects** — Vendor, VendorService, ContractObligation, VendorReview, VendorAccessGrant
**Domain events** — `VENDOR_REGISTERED`, `VENDOR_REVIEW_COMPLETED`, `VENDOR_ACCESS_GRANTED`, `VENDOR_INCIDENT_RECORDED`, `VENDOR_OFFBOARDED`
**Acceptance gate** — Every vendor access grant has an expiry and an accountable owner, an overdue review flags the vendor rather than lapsing quietly, and offboarding is not complete until revocation is verified in the access-control record.
**Role surface** — county,state
**⚠ Caution** — Vendor assurance covers vendors of BB2G and supporting systems; it does not assert or evaluate certification status for voting systems, which is read from source records in the certification module.
**Shared services** — LockChain Ledger Core · Evidence Core · Identity & Authorization Core · Jurisdiction Rules Engine · Notifications & Escalation Core · Reporting & Document Core