Institutional Vocabulary Reference

CommunityPay uses a controlled vocabulary for its institutional artifacts and enforcement mechanisms. This reference defines each term precisely, maps it to the production code artifact that implements it, and identifies the lineage classification that governs its mutability.

This page is intended for CPAs, underwriters, escrow officers, and integration partners who need to understand exactly what CommunityPay means when it uses these terms in evidence packs, exports, and attestations.

Lineage Classifications

Every data artifact in CommunityPay has a lineage classification that determines its mutability rules:

These classifications are enforced at the application layer through save() and delete(). ARTIFACT records use ImmutableModelMixin or an equivalent override, which refuses any attempt to update or delete through those methods. A queryset update does not call them, which is why ARTIFACT records also carry content hashes and why the ledger's own rules are held by database triggers and constraints.

Enforcement Constructs

EnforcementDecision

An immutable record of a financial authorization decision. Every production financial flow — journal entries, fund transfers, bill payments, invoice creation, payment receipts, and year-end closures — produces an EnforcementDecision before execution.

Lineage: ARTIFACT (immutable via ImmutableModelMixin)

Production status: Blocking has been live since the cutover on January 24, 2025. A database constraint trigger refuses any journal entry that carries no decision.

EnforcementDispatcher

The mandatory choke point for all enforcement decisions. A service — not a model. Every protected flow calls dispatcher.enforce_pre_persist() and receives an EnforcementOutcome.

Design law: "No decision logged = precise signal of bypass or bug."

Guard

A stateless enforcement primitive that checks one specific invariant. Guards are:

• Stateless: Same inputs produce same outputs
• Independent: No guard depends on another guard's result
• Composable: Guards combine into chains via Flow configuration

18 production guards are registered in the Guard Manifest:

Guard Manifest

A registry of all guards, validated by a test in the suite. Guard IDs are stable — changing or removing a guard ID would break the audit trail. The manifest includes a get_manifest_hash() function that produces a SHA-256 fingerprint of the entire guard configuration.

Flow

A named mapping from transaction type to guard sequence. Flows determine which guards run for each transaction type.

10 canonical flows exist. The guard column is the set the manifest selects for that flow, in evaluation order:

Bills and fund transfers are the only documents an approval step opens. A workflow recorded against any other document type is marked "Not enforced" and is never consulted.

AuditOverride

A controlled bypass of a guard decision. Overrides are never automatic. They require explicit user action, a documented reason, and an expiration.

A VENDOR_RISK or DISBURSE_COMP override — the two that stand between association money and an external bank account — names one bill and one amount, and one posting uses it up. A second payment needs a second override, authorized separately. Before this binding shipped, these two named nothing but the association and were never used up: one override cleared every disbursement in the association for 24 hours.

A VENDOR_RISK or DISBURSE_COMP override is stamped with the entry that used it up, inside the posting that used it, and a posting that names no user is refused rather than overridden. Every use is also written to an immutable AuditOverrideUsage row naming the user, the journal entry, and the enforcement decision. For the four other scopes that row is the only record of a use, and the recorder that writes it logs a failure rather than refusing the posting.

Lineage: ROOT_EVENT (status updates tracked)

EnforcementOutcome

The return type from enforcement evaluation. Contains the decision, all guard results, timing, blocking guard identification, and context fields for POST_PERSIST recording. This is a runtime dataclass — not persisted directly. The EnforcementDecision model is the persisted form.

Institutional Packet Types

InstitutionalPacket

The canonical record for every institutional output. All packet types share this model with type-specific evidence snapshots.

Lineage: ROOT_EVENT (lifecycle status mutable; evidence fields immutable)

HDEP (HOA Disclosure & Evidence Packet)

A comprehensive disclosure package for resale transactions. Contains financial summaries, reserve study status, governance attestation, vendor compliance, and assessment schedules for a specific unit.

Scope: Per unit (e.g., A204 for unit A204)

GCA (Governance Controls Attestation)

A board-facing report on internal control effectiveness. Measures control pass rates, override patterns, exclusion activity, and vendor compliance across a reporting period.

Scope: Per HOA/period (e.g., 2025-Q1)

Assessment levels: STRONG (a pass rate of 95% or more, with no high-severity flag), ADEQUATE (85% or more), NEEDS_IMPROVEMENT (70% or more), DEFICIENT (below 70%)

FADR (Funds Authorization & Disbursement Record)

A complete payment evidence chain for escrow and audit. Documents every step from bill creation through payment execution, including the full approval chain, policy snapshots, journal entry lines, and vendor compliance status at payment time.

Scope: Per HOA/period (e.g., 2025-01)

Verification status: VERIFIED, NEEDS_REVIEW, FLAGGED

RC (Resale Certificate)

A statute-mapped resale disclosure for unit sales. Generated from compliance profiles that define jurisdiction-specific requirements (e.g., WA RCW 64.34.425 for Washington condominiums).

Scope: Per unit

RSR (Reserve Funding Status Report)

A reserve funding analysis with component inventory, remaining useful life calculations, funding scenarios, and 30-year cash flow projections.

Scope: Per HOA/period

LDS (Loan Disclosure Statement)

The disclosure packet for a loan. Contains the loan instrument terms, the full amortization schedule, the balance rollforward, covenant status, and the reconciliation of the loan subledger to the general ledger.

Scope: Per loan

CEP (Close Evidence Pack)

The month-end close bundle. Captures the fiscal period at close: trial balance, bank reconciliation proof, enforcement decisions, integrity scans, budget variance, and the exception register, in 12 evidence sections with 14 deterministic risk flags.

Scope: Per fiscal period (YYYY-MM)

BP (Board Packet)

The packet a board reads each month, assembled from the report services in the order a treasurer reads them: cash position and bank reconciliations first, then the statements, the agings, the budget comparison, and the schedules and registers. A board can set its own order; a stored order cannot drop a section.

Scope: Per HOA/period

FSR (Fiduciary Shield Report)

Governance proof from enforcement telemetry: guard performance, block analysis, override audit, and risk flags, aggregated for a period.

Scope: Per HOA/period (e.g., 2026-02)

CMR (CARI Market Report)

A CARI report generated through the same attestation service as the other CARI reports.

Risk Intelligence Constructs

ExclusionTrigger

A versioned definition of conditions that create exclusions (bind blocks). Triggers define what signals to evaluate, what thresholds to apply, and what effect fires when conditions are met.

Lineage: SNAPSHOT (conditions immutable once ACTIVE; versioned)

Exclusion

An active hold on an entity. Created when an ExclusionTrigger fires. Exclusions are never deleted — they are lifted, expired, or overturned on appeal.

Lineage: ROOT_EVENT (status transitions tracked via ExclusionStatusHistory)

ExclusionTriggerHit

An immutable record that a trigger's conditions were met for a specific entity at a specific time. Contains the evaluated signals, computed values, and the trigger version that was active.

Lineage: ARTIFACT (fully immutable)

EligibilityRule

A declarative rule that defines eligibility criteria. Rules are versioned and immutable once published.

Lineage: SNAPSHOT (expression immutable once ACTIVE)

EligibilityEvaluation

An immutable record of a complete eligibility evaluation. Captures all rule versions active at evaluation time, all signal values, and the per-rule pass/fail results.

Lineage: ARTIFACT (fully immutable)

Signal Provider

A component that gathers the values eligibility and exclusion evaluation read. Signals are registered in one registry, in five namespaces — RISK_SIGNAL, TELEMETRY, UNDERWRITING, VENDOR_COMPLIANCE, and DEBT_SERVICE — and return typed key-value pairs.

Vendor Intelligence Constructs

VECR (Vendor Eligibility & Compliance Record)

A vendor attestation. Contains credential status (COI, license, bond, W9), compliance history, performance metrics, and an eligibility determination.

Eligibility statuses: ELIGIBLE, CONDITIONAL, INELIGIBLE, REVIEW_REQUIRED

Content hash: SHA-256 of all sections for tamper detection.

BuildRated Score

A composite vendor quality score (0-100) computed from five components: licensing, insurance, bonding, payment history, and violations.

Compliance Alert

A notification raised for a vendor linked to a contractor record when a certificate of insurance, license, or bond approaches or passes expiration, or a W-9 is missing. Alert types are COI_EXPIRING, COI_EXPIRED, LICENSE_EXPIRING, LICENSE_EXPIRED, BOND_EXPIRING, BOND_EXPIRED, W9_MISSING, and MULTIPLE_ISSUES. Alerts are raised when the vendor compliance sweep runs; no scheduled sweep runs today.

CARI Constructs (Community Association Risk Index)

CARI

Community Association Risk Index. A deterministic, consent-gated index that summarizes attested governance, financial, and operational risk signals for community associations, derived directly from an authoritative system of record. CARI is not a credit score and does not make eligibility or lending decisions. See What Is a Community Association Risk Index? for an introduction and CARI Methodology and Scoring Framework for the full technical specification.

CARI Score

A composite numeric value (0-100, higher = healthier) computed from five weighted components: Financial Health (30%), Governance (25%), Vendor Risk (15%), Enforcement Integrity (15%), and Payment Behavior (15%). Scores are immutable after computation and include a SHA-256 calculation hash for deterministic verification.

Lineage: ARTIFACT (immutable via save override; append-only time series)

CARI Grade

A letter grade (A+ through F) derived from the CARI Score using published threshold mappings. Grade thresholds are defined in the active ScoreMethodology version.

CARI Confidence

An assessment of data completeness behind a CARI Score. Three tiers:

ScoreMethodology

A versioned, immutable record of scoring weights, grade thresholds, and confidence tiers. Only one methodology version is ACTIVE at any time. Historical scores always reference the methodology version used at computation time.

Lineage: SNAPSHOT (immutable once ACTIVE)

CariConsent

An HOA's explicit authorization for third-party access to its CARI data. Score queries are rejected without active consent. Consent can be scoped to all subscribers, a specific subscriber, or a subscriber type.

Lineage: ROOT_EVENT (revocable; status transitions tracked)

CariSubscriber

A third-party organization authorized to consume CARI data via API. Subscribers are classified by type (Lender, Insurer, Title Company, Escrow, Real Estate, Other) and tier (Basic, Professional, Enterprise) which governs rate limits and feature access.

APIKey

A hashed API credential for machine-to-machine authentication. The raw key is shown once at creation and stored as a SHA-256 hash. Keys have scoped permissions (score:read, report:generate, monitor:subscribe, webhook:manage) and optional expiration.

Lineage: ROOT_EVENT (revocable; last_used_at updated on use)

CARI Monitor

A subscriber's request to receive a notification when an HOA's CARI Score changes. Scores are computed nightly. Monitors can filter by event type (score.changed, score.grade_changed, score.threshold_breached, score.state_changed) and custom thresholds (floor/ceiling alerts).

One event ignores the filter. score.state_changed fires when an association's score stops carrying a number, or starts carrying one again, and it reaches every active monitor on that association. A withheld score breaches no threshold and moves no grade, so a narrowed subscription would otherwise receive nothing and hold its last known score on file as the current answer.

CARI Report Types

All CARI reports are generated as InstitutionalPackets with SHA-256 content hashes, version chains, and full audit trails via BaseAttestationService.

Money-Out Constructs

Step-Up Confirmation

A fresh authenticator or recovery code, given within the last ten minutes, before an action that moves money or decides who may. A text-message code never confirms one. A new authenticator cannot confirm until the account's owner approves it from an email.

Bank PIN

An association secret, separate from any login, checked on the server. Changing it takes the current PIN and a step-up confirmation. Five wrong tries lock it. Staff cannot set it.

ConnectExternalAccount

One row for each bank on an association's processor account, with a fixed role — the association's payout bank or a vendor destination — and a flag for the one pinned payout bank. Database constraints refuse a vendor bank as the pin and refuse two pins.

Payout Bank Pin

The one bank to which an association's automatic payouts may sweep. It is verified against the processor every hour and on every bank and payout event. If the processor's default bank is not the pin, automatic payouts pause until a person releases them. Changing the pin takes two board members, and the first payout to the new bank is held.

VendorPayment

The record of one vendor payment, written in the same transaction as the posting and the bill's payment application. Processor events stamp it; they never post.

VendorBankChange

A change of a vendor's bank. The new bank waits three business days before the rail pays it. A different board member can end the wait early, with a step-up confirmation and the bank PIN, after calling the vendor at a number already on file.

DutySettingChange

One change to one separation-of-duties setting, never updated and never deleted.

Invoice Inbox Gate

One of 23 deterministic checks run on an emailed invoice. The strongest gate that fails sets the outcome: submitted for approval, drafted, or held with one plain sentence. The inbox never approves and never pays.

Bank Feed

Daily posted transactions and the live bank balance, read through Stripe Financial Connections. The feed matches one to one by machine and never posts an entry. A person reconciles and completes the month.

Decision Chain

Each enforcement decision carries a hash that includes the one before it. The chain is anchored in an immutable integrity snapshot, so deleting a decision and recomputing the links after it is detected.

Ledger Rules

The eight database triggers and 29 constraints the database holds on the ledger. A nightly probe reads the database catalog to confirm each is installed.

ArtifactAttestation

A board member's attestation on an institutional artifact. Identity and binding fields are locked; the lifecycle status can move.

Governance Constructs

GovernanceAttestation

A formal attestation of governance effectiveness for a specific period. Generated from weekly GovernanceDigest aggregations and exception register data.

Exception Register

An automatically generated register of governance exceptions. Populated from exclusion events, escalation events, and SLA breaches. Auditors typically build these manually; CommunityPay generates them from source data.

Control Plane Health Snapshot

Technical metrics about enforcement dispatcher operation: guard execution statistics, decision distribution, average evaluation time, and guard-specific performance data.

Export Constructs

Institutional Export

A machine-parseable JSON export designed for consumption by external validators.

All exports include ExportMetadata with a SHA-256 content hash.

Cryptographic Constructs

Content Hash

SHA-256 hex digest computed from canonical JSON serialization of an evidence snapshot. Canonical JSON uses sorted keys, minimal separators ((",",":")) and UTF-8 encoding to ensure identical data always produces identical hashes.

Previous Packet Hash

The content hash of the preceding version of the same packet type/scope, stored on successor packets to create a tamper-evident chain.

Conditions Hash

SHA-256 hex digest of an ExclusionTrigger's conditions JSON, computed at save time. Used to enforce immutability of ACTIVE trigger conditions — if the hash changes, the save is rejected.

Manifest Hash

SHA-256 fingerprint of the entire Guard Manifest configuration. Changes to the manifest (adding, removing, or modifying guard definitions) produce a different hash, enabling a test in the suite to verify that the manifest hasn't been silently altered.

This reference describes production constructs as of October 2026. Definitions evolve with the platform; request a current vocabulary reference for diligence.