Election CommandBorn Between 2 Generals

The build map

The sixty-eight

Ten groups. Sixty modules from the blueprint, plus the eight it says to preserve rather than force into the original list. Each one names what it consumes and what it is forbidden to do.

The build map

Sixty-eight modules, not sixty applications

The blueprint's executive finding is that this should not be built as sixty independent election applications. It should be one election-operations platform with domain modules sitting on a small number of shared, hardened services. The modules below are therefore comparatively thin. The hard infrastructure — LockChain, identity, evidence, offline sync, jurisdiction rules, source currency — lives once.

The blueprint is also explicit that the sixty are a minimum, not a cap. Where legitimate functionality already exists outside the original list it should be preserved rather than forced awkwardly into it. Eight such modules are carried here as beyond the sixty.

The strongest pilot candidate

Ballot Transfer, Chain of Custody and LockChain together are the combination the blueprint names as the first county pilot.

01–06 · 6 modules

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.

01

Master Election Command Center

Role-aware county/state operating picture, jurisdiction/election selector, site health, incidents, tasks, custody and evidence drill-down, handoff summary and current-data timestamps.

Constraint. A green tile must never be produced from stale or unreachable data; freshness is part of the reading, not decoration.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityjurisdictionnotifyreportingobservability

02

Election Calendar & Milestones

Versioned statutory and operational milestones, dependencies, authoritative-source citations, alerts, escalations and completion evidence.

Constraint. Dates are read from cited authority with effective dates; the module must never carry a hard-coded statutory deadline of its own.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidencejurisdictioncurrencynotifyreporting

03

Jurisdiction Configuration Engine

Country/state/county/local inheritance, approved overrides, election-specific configuration, feature flags, configuration diff and rollback.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityjurisdictionreportingobservability

04

Election Readiness Score

Evidence-backed operational-readiness controls with transparent weighting and missing-evidence flags. It must explicitly avoid claiming that a readiness score proves election validity.

Constraint. The readiness score must explicitly avoid claiming that it proves election validity; it measures operational controls and evidence, nothing more.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidencejurisdictioncurrencyreporting

05

Election-Day Operations Console

Live tasks, location state, support requests, personnel/logistics, incident escalation, communications and offline synchronization state.

Constraint. A yellow saved-locally state must never be visually indistinguishable from a green received-by-county-command acknowledgement.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityofflinejurisdictionnotifyreportingobservability

06

After-Action Command Center

Timeline, incident clustering, root-cause analysis, corrective actions, accountable owners, deadlines, training feedback and closure evidence.

Constraint. Root-cause analysis records observations and findings; it does not assign motive or culpability the evidence does not support.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentitynotifyreporting

07–14 · 8 modules

Polling-Place Operations

Everything a vote centre does between opening and closing: people, checklists, supplies, capacity and accessibility. Because a county runs a large fleet of vote centres, this must behave as a fleet-management surface rather than a collection of isolated tablets.

07

Polling-Place Opening

Identity/role check, current opening checklist, facility inspection, equipment/seal references, supplies, exceptions, evidence and supervisor release.

Constraint. Equipment and seals are referenced by inventory identifier and scan; the module never opens a control channel to a voting system.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionnotify

08

Polling-Place Closing

Closing sequence, reconciliation references, seal capture, equipment closeout, custody transfer, open-issue review and signed completion package.

Constraint. Reconciliation is referenced, not recomputed here, and no ballot content is ever read or stored by this module.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionreporting

09

Poll Worker Management

Worker roster, qualifications, shifts, attendance, replacement workflow, role restrictions and minimal sensitive-personnel exposure.

Constraint. Minimal sensitive-personnel exposure is a hard requirement: the field surface sees assignment and role, not a personnel file.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityofflinejurisdictionnotifyreporting

10

Poll Worker Training

Versioned election-specific curriculum, scenario training, assessments, certifications, expirations and changed-procedure acknowledgement.

Constraint. A certification against a superseded procedure version must read as stale, never as current.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityjurisdictioncurrencynotifyreporting

11

Polling-Place Checklist

Conditional checklist engine, evidence-required steps, dual verification, offline execution, exceptions and version locking.

Constraint. Dual verification means two distinct people; one device and one session can never satisfy both halves.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionreporting

12

Supply & Inventory Management

Supply kits, scanning, stock thresholds, issue/return, controlled materials, lost/damaged items and warehouse reconciliation.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinenotifyreporting

13

Wait-Time / Capacity Monitoring

Timed observations, stale-data indicators, trends, capacity thresholds, dispatch triggers and authorized public-feed adapter.

Constraint. An observation is an observation: the module reports what was measured and when, and never presents an extrapolation as a measurement.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainidentityofflinejurisdictionnotifyreportingobservability

14

Accessibility Compliance

Site inspection, accessible route, service/equipment availability, digital accessibility checks, remediation and verification.

Constraint. WCAG 2.2 applies to the field surfaces themselves; the module cannot report accessibility while being inaccessible.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinejurisdictionnotifyreporting

15–21 · 7 modules

Ballot Operations

Batch- and container-level custody of ballot materials without ever storing voter selections. Arizona guidance requires secure retrieval and chain-of-custody procedures, and the blueprint calls Ballot Transfer + Chain of Custody + LockChain the strongest candidate for a first county pilot.

15

Ballot Inventory

Batch/container inventory, counts, location, seals, controlled count adjustments, reconciliation and exceptions—without storing voter selections.

Constraint. Batch and container level only — without storing voter selections, ever, in any field, derivative or export.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionreporting

16

Ballot Transfer

Transfer orders, sending/receiving custodians, seals, dual acknowledgement where required, transport state and discrepancies.

Constraint. Until a county formally accepts the electronic procedure, the existing county documentation remains the controlling record and BB2G runs in parallel.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionnotifyreporting

17

Ballot Chain of Custody

Append-oriented custody history, seals, timestamps, custodians, locations, evidence, LockChain receipts, gap detection and exports.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinejurisdictionnotifyreportingobservability

18

Mail-Ballot Workflow

Batch-level operational stages and custody while minimizing duplication of protected voter information.

Constraint. Minimize duplication of protected voter information: reference the official system of record, do not mirror it.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionreporting

19

Provisional-Ballot Workflow

Material/custody/process tracking while keeping eligibility decisions with authorized election officials and official systems.

Constraint. Eligibility decisions stay with authorized election officials and official systems. This module tracks material, custody and process only.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionreporting

20

Ballot Reconciliation

Expected-versus-actual counts, source provenance, transparent formulas, variances, second review, exceptions and closure.

Constraint. A variance is a variance: the module reports the difference and requires review, and never characterises the cause.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreporting

21

Ballot Storage & Retention

Secure storage registry, access history, seals, retention schedules, legal holds, disposition approval and certificates.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionnotifyreporting

22–28 · 7 modules

Equipment & Technology

Registry, testing, seals, baselines and certification references for voting equipment. This group carries the hardest network boundary in the platform: BB2G sits beside the voting system and never inside it, with no unauthorised control channel of any kind.

22

Voting Equipment Registry

Asset/serial/model/version/certification references, location, custody, service status and history, with no unauthorized control channel.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinejurisdictionreportingobservability

23

Equipment Testing

Test plans, equipment scope, witnesses, test artifacts, failures, remediation, retesting and approval.

Constraint. Testing is documented in BB2G; it is executed on the equipment through the approved procedure, never driven by BB2G.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreporting

24

Logic & Accuracy Documentation

L&A schedules, equipment references, authorized procedure, witnesses/observers, artifacts, exceptions and post-election records.

Constraint. The authorized procedure comes from the jurisdiction source pack with its effective date; the module must not carry its own copy of the procedure.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictioncurrencyreporting

25

Equipment Seal Tracking

Seal inventory, application, verification, scan/photo evidence, mismatch workflow, replacement and dual verification.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionnotifyreporting

26

Device Configuration Registry

Approved baselines, version/hash references, configuration validation, drift detection and change approval.

Constraint. Detection only on voting-system assets: BB2G observes and reports configuration state and never pushes a configuration to one.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityjurisdictionnotifyreportingobservability

27

Maintenance / Failure Tracking

Failure tickets, triage, dispatch, replacement equipment, parts, downtime, remediation and return-to-service evidence.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinenotifyreportingobservability

28

Certified-System Reference Center

Live EAC and state certification/approval references, version mapping, systems under test, withdrawals, source history and freshness.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainjurisdictioncurrencynotifyreportingobservability

29–35 · 7 modules

Evidence & Auditability

The evidentiary spine: write-once originals, provenance, an append-only hash-chained log, audit workpapers and exportable legal packages. The same Evidence Core is intended to serve other BB2G domains, which is what makes it a platform rather than a page.

29

Evidence Vault

Immutable originals, hashes, classifications, metadata, custody, legal holds, access history, controlled previews and exports.

Constraint. Permission attaches to the value, not to the page: a classified item stays classified through every derivative, preview and export.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreportingobservability

30

Immutable Audit Log

Append-only canonical events, hash chain, signed checkpoints, key rotation, independent verification and tamper alerts.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityofflinereportingobservability

31

Evidence Provenance

Origin, collector, capture method, custody, derivation graph, tools/versions, source relationships and findings linkage.

Constraint. Provenance answers where a record came from and how it was handled. It does not evaluate whether the content is true.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityreporting

32

Photo / Video Evidence Capture

Managed-device capture, encrypted offline storage, upload acknowledgement, metadata, restricted originals and redaction derivatives.

Constraint. Redact at the point of storage: a derivative is generated for release, and the original stays restricted rather than being trimmed after the fact.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinereportingobservability

33

Document Authentication

Hash/signature verification, trusted-source registry, version comparison and explicit distinction among integrity, authority and truth.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentitycurrencyreporting

34

Audit Workspace

Scope, sampling, workpapers, evidence requests, findings, management responses and closure.

Constraint. Explicitly not exposed to ordinary field users: the Audit Workspace does not belong in a poll worker’s cognitive environment.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentityjurisdictionreporting

35

Evidence Export / Legal Package Generator

Manifest, hashes, provenance, custody history, redactions, index, approvals and independent verification instructions.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreporting

36–42 · 7 modules

Incident & Safety

Structured reporting, triage, escalation, physical security and worker safety. The large HELP control stays, but it first asks whether anyone is in immediate danger rather than turning every press into a police call, and it keeps observed behaviour separate from interpretation and suspected motive.

36

Incident Intake

Sub-minute structured reporting, category, urgency, location, evidence, offline submission and immediate-safety branch.

Constraint. The form separates observed behaviour from interpretation and from suspected motive, and never asks the reporter to diagnose why.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinejurisdictionnotifyobservability

37

Incident Triage

Urgency/impact rubric, responsible team, current procedure retrieval, assignment and transparent reclassification.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityjurisdictioncurrencycopilotnotifyreporting

38

Incident Escalation

Jurisdiction-specific escalation matrix, timers, acknowledgements, SME routing, executive escalation and documented de-escalation.

Constraint. An escalation path that has never been tested is not an escalation path; timers and delivery must be poison-tested against a dead channel.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainidentityjurisdictionnotifyreportingobservability

39

Physical Security

Facility zones, locks/access controls, cameras, lighting, keys, alarms, observations, findings and remediation.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityofflinejurisdictionnotifyreporting

40

Emergency Response

Large HELP control, immediate-danger path, evacuation/shelter guidance, command notification, continuity and recovery.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainidentityofflinejurisdictionnotifyobservability

41

Threat / Safety Reporting

Threats, harassment, hazards and safety concerns with restricted identities, evidence and protective-action workflow.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinejurisdictionnotify

42

Election Worker Safety

Safety briefings, check-ins, de-escalation tools, buddy rules, post-incident support and training.

Constraint. Support records are minimal by design: who was offered support and whether they accepted, never the content of it.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainidentityofflinejurisdictionnotify

43–49 · 7 modules

Cybersecurity

Risk-based security for the information systems supporting the election, anchored on established public standards rather than a proprietary security vocabulary. Scanning is a privilege, not a default: cybersecurity must never become the justification for casually probing an election system.

43

Election Cyber Command

BB2G/supporting-system alerts, asset risk, identity events, integrations and incident status, with system-boundary labels.

Constraint. A quiet panel for a system BB2G does not monitor must read as out of scope, never as secure.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentitynotifyreportingobservability

44

Asset Inventory

Endpoints, applications, servers, services, integrations, owners, software components, lifecycle and criticality.

Constraint. Voting-system assets are inventoried as references only; discovery must never reach across the boundary into them.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityreportingobservability

45

Network / System Risk Registry

Risks, affected assets, likelihood/impact rationale, controls, owners, treatment, residual risk and acceptance.

Constraint. Explicitly not exposed to ordinary field users: the Cyber Risk Register does not belong in a poll worker’s cognitive environment.

Workflows, objects, events, 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 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 surfaces
county · state

lockchainidentityjurisdictionnotifyreporting

46

Vulnerability Management

Vulnerability intake/scanning for authorized BB2G systems, prioritization, remediation, exception and retest.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityjurisdictionnotifyreportingobservability

47

Access-Control Monitoring

MFA, accounts, privileged access, device trust, authentication anomalies, revocation and periodic certification.

Constraint. Trust is not inferred from network location or affiliation; every session is evaluated on identity, device and scope.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentitynotifyreportingobservability

48

Cyber Incident Response

Preparation, detection, analysis, containment, eradication, recovery, communication, evidence and after-action.

Constraint. The response record describes what was observed and what was done. Attribution is a conclusion and requires evidence and, in some contexts, legal determination.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentitynotifyreportingobservability

49

Backup / Recovery / Continuity

Encrypted backups, isolated copies, restore testing, RPO/RTO, continuity mode and disaster exercises.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentitynotifyreportingobservability

50–54 · 5 modules

Intelligence / Review

Explainable review of anomalies, cross-jurisdiction patterns, timelines, entities and dispositions. The software may say "review required"; it may not conclude fraud, conspiracy, tampering, suppression or malfeasance, and the DATA -> OBSERVATION -> ALLEGATION -> ANOMALY -> EVIDENCE -> FINDING -> CONCLUSION ladder stays in the schema, the APIs, the prompts and the UI.

50

Election Anomaly Review

Explainable detection rules, source quality, trigger reason, human review, disposition and false-positive feedback.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionnotifyreporting

51

Cross-Jurisdiction Pattern Engine

Normalized operational events, privacy-preserving comparisons, tenant/data-sharing controls and review cases.

Constraint. Statewide analytics is explicitly not exposed to ordinary field users, and a correlation is stated as a correlation detected, never as a cause.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityjurisdictionreportingobservability

52

Timeline Correlation

Chronological linking of incidents, custody, equipment, communication and audit events with timestamp-quality metadata.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityofflinereporting

53

Relationship / Entity Mapping

Operational graph of facilities, assets, vendors, incidents, organizations, personnel roles and documents, each relationship sourced.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentityjurisdictionreporting

54

Human Review & Disposition

Evidence review, conflict disclosure, reasoned disposition, second review, appeal/reopen and permanent attribution.

Constraint. The reviewer works up the ladder deliberately: DATA, OBSERVATION, ALLEGATION, ANOMALY, EVIDENCE, FINDING, CONCLUSION. The UI must not let a step be skipped silently.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentitynotifyreporting

55–60 · 6 modules

Records & Compliance

Records, public-records requests, the legal source corpus, retention and exportable compliance evidence. Public-records law is a jurisdiction rule pack rather than one federal regime, and the statute library plus policy management are the foundation the AI Copilot stands on.

55

Public Records Repository

Classified source records, searchable authorized derivatives, release versions, provenance and retention.

Constraint. Permission attaches to the value: a redacted derivative is what is searchable and releasable, and the classified source stays behind it.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreporting

56

FOIA / Public Records Request Manager

Jurisdiction-specific request rules, deadlines, custodian tasks, search logs, redaction/review, production and appeals.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictioncurrencynotifyreporting

57

Statute & Regulation Library

Section-level legal/procedural corpus, jurisdiction, effective dates, court-order overlays, supersession and verification.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentityjurisdictioncurrencynotifyreporting

58

Retention Rules Engine

Record classes, federal/state/local retention, holds, conflicts, disposition approval and certificates.

Constraint. Explicitly not exposed to ordinary field users: Retention Rules do not belong in a poll worker’s cognitive environment.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentityjurisdictioncurrencyreporting

59

Policy / Procedure Management

Draft, review, approval, effective date, publication, targeted acknowledgement, supersession and rollback.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityjurisdictioncurrencynotifyreporting

60

Compliance Evidence Generator

Control mapping, objective evidence, gap analysis, freshness/expiration and exportable compliance packages.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictioncurrencyreporting

61–68 · 8 modules

Beyond the Sixty

Functions the blueprint names as legitimate BB2G capability that sits outside the original sixty. The instruction is explicit: preserve them rather than force them awkwardly into the sixty. The blueprint supplies names only, so these carry no verbatim "built in full" text.

61 · beyond the sixty

Observer Management

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.

Constraint. Automatic political profiling of observers is prohibited; this module records accreditation, schedule and attendance only.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityjurisdictionnotifyreporting

62 · beyond the sixty

Warehouse Logistics

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.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinenotifyreporting

63 · beyond the sixty

Election Communications

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.

Constraint. Public-facing communications carry no address or phone contact surface, and an unapproved draft can never be sent.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainidentityjurisdictionnotifyreporting

64 · beyond the sixty

Facility Acquisition

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.

Constraint. Accessibility findings from the survey flow to the accessibility module as findings; they are never closed inside a procurement workflow.

Workflows, objects, events, acceptance
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 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 surfaces
manager · county · state

lockchainevidenceidentityjurisdictionreporting

65 · beyond the sixty

Courier Operations

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.

Constraint. Courier location is operational tracking bound to an active leg; it is not personnel surveillance and must stop when the leg closes.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county

lockchainevidenceidentityofflinejurisdictionnotifyobservability

66 · beyond the sixty

Election Scenario Exercises

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.

Constraint. Nothing produced during an exercise becomes the controlling official record; the marking must be structural, not a banner.

Workflows, objects, events, acceptance
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 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 surfaces
worker · manager · county · state

lockchainevidenceidentityofflinenotifyreporting

67 · beyond the sixty

MDM Fleet Management

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.

Constraint. Device management covers BB2G managed devices only; it has no reach into voting-system equipment of any kind.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainidentityofflinenotifyobservability

68 · beyond the sixty

Vendor Assurance

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.

Constraint. 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.

Workflows, objects, events, acceptance
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 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 surfaces
county · state

lockchainevidenceidentityjurisdictionnotifyreporting

What a module consumes

The tags on each card name the shared services that module actually uses. They are deliberately not uniform: a module claiming all ten would be a module nobody had thought about.

LockChain Ledger Core

Event canonicalization, hash chain, signed receipts/checkpoints, correction links, independent verification

Consumed by
68 of 68 modules

Evidence Core

Immutable originals, derivatives, provenance, classification, legal holds, custody and evidence manifests

Consumed by
46 of 68 modules

Identity & Authorization Core

MFA, managed devices, RBAC + ABAC, jurisdiction scope, least privilege, privileged-access review

Consumed by
65 of 68 modules

Offline Sync Core

Encrypted local event queue, idempotent replay, conflict handling, server acknowledgements

Consumed by
28 of 68 modules

Jurisdiction Rules Engine

State/county/election applicability, effective dates, controlling authority and procedure selection

Consumed by
51 of 68 modules

Election Knowledge Currency Engine

Source retrieval, section hashes, changes, supersession, stale-source warnings and human review

Consumed by
12 of 68 modules

AI Election Copilot

Citation-grounded procedural retrieval with mandatory abstention when current authority is unavailable

Consumed by
1 of 68 modules

Notifications & Escalation Core

Alerting, acknowledgements, escalation timers, delivery history

Consumed by
42 of 68 modules

Reporting & Document Core

PDF/CSV/JSON outputs, custody receipts, evidence packages, audit reports and manifests

Consumed by
61 of 68 modules

Observability & Security Core

Application health, security events, sync failures, source freshness, backup health and operational telemetry

Consumed by
24 of 68 modules
Provenance, sequence, integrity — not truth Append, never overwrite Beside the voting system, never inside it