How CommunityPay maintains its institutional layer.

Four pillars: the legal corpus, the resale certificate, the CARI score, and the ledger itself. Each is built on a defined methodology — primary sources, deterministic computation, hash-chained outputs, and a review cycle. This page is the canonical reference. Auditors, lenders, insurers, and CPAs should bookmark it.

By Scott Vuilleumier · Last reviewed May 10, 2026

Legal Corpus Methodology

719 statutes · 52 jurisdictions · 365 verified thresholds

The corpus tracks every statute, case, session law, and regulation relevant to community associations in every state we cover. It is not a citation index. It is a living archive of the primary sources themselves — text, snapshot, hash, effective date, and revision chain.

Sources

Statute text and case law are fetched from the official source of record — state legislature pages (e.g., app.leg.wa.gov for Washington), state court opinion publications, and federal regulators. Third-party legal databases are not the supply line. The corpus depends on no aggregator that can sunset its API or relicense its data.

How the corpus is maintained

  • LegalSourceSnapshot. Every statute, case, and regulation is captured as frozen text with a SHA-256 content hash and a snapshot date. Snapshots are immutable. To "update" a source, a new snapshot is created.
  • LawChangeEvent. When a scraper or human review detects drift between the current source and the latest snapshot, a LawChangeEvent records the change with previous/new snapshot references and a narrative summary.
  • ContentCitation. Every factual legal claim in every published article is pinned to a specific LegalSourceSnapshot via a polymorphic ContentCitation record. When the source changes, every dependent citation is automatically flagged for re-verification.
  • ContentRevision. Each public-facing update to an article is recorded as an immutable revision with a content hash, a public summary, and a link back to the triggering LawChangeEvent. The revision history block on every cornerstone article displays this trail.

Review cycle

Statutes are re-verified on a 90-day rolling cycle. The verify_statutes management command produces an overdue list. Articles touching the corpus are reviewed at least every 6 months. The last_reviewed_at field on each article is populated by a named reviewer and surfaced in the article footer.

Evidence
  • Primary sources fetched directly from state legislatures and court systems, not aggregators
  • SHA-256 content hash on every snapshot, computed from normalized text
  • Append-only LegalSourceSnapshot and LawChangeEvent records — never edited, never deleted
  • Article-to-source binding is FK-enforced (ContentCitation), not string-matched
  • Public revision history visible on every article with citations

For the full system spec, including all seven data models and the citation pattern API, see the canonical reference: Law Center.

Resale Certificate Methodology

10 compliance profiles · 7 states · live ledger generation

Every resale certificate is generated from live ledger data against a state-specific statutory compliance profile. No board self-attestation, no copy-paste from prior certificates, no spreadsheet. The certificate is hash-bound to the underlying evidence at the moment of issuance.

Compliance profiles

Each supported state has one or more compliance profiles defining the required disclosure items, mapped to specific statutory subsections. The profile registry is authoritative — when a statute amends, the profile updates, and the certificate output changes on the next generation. Profiles cover:

  • Washington — RCW 64.34.425 (condominiums), RCW 64.90.640 (WUCIOA, universal as of 2026)
  • California — Cal. Civ. Code §4525-4530
  • Oregon — ORS 94.670
  • Florida — Fla. Stat. §720.30851 (HOA), §718.116 (condo)
  • Texas — Tex. Prop. Code §207 (HOA), §82.157 (condo)
  • Colorado — C.R.S. §38-33.3-316 (CCIOA, unified)
  • Nevada — NRS 116.4109 (CIC Act, unified)

How a certificate is generated

  • Determine the profile based on the unit's HOA configuration and state.
  • Assemble the evidence snapshot by querying the live ledger — assessment balances from invoice records, reserve fund balance from the fund-accounting layer, insurance from HOAInsurancePolicy records, governance from BoardMemberTenure and GovernanceAttestation, anticipated repairs from FixedAsset and Budget, and so on.
  • Run the compliance check against the profile's required items. Missing data is recorded as a first-class unknown payload with an explanatory statement — never omitted.
  • Compute the SHA-256 content hash from the canonical JSON of the snapshot. Bind that hash to the resulting InstitutionalPacket.
  • Render the PDF with the hash printed on the cover and embedded in the certificate metadata. Log a PacketEvent for the issuance.

Restatement chain

A certificate is never edited after issuance. If the underlying ledger changes or a disclosure error is identified, a new packet is generated via generate_restatement(), linked to the original via a restatement_of FK with a documented reason. The original packet is marked RESTATED in its event log. The chain is auditable end to end.

Evidence
  • Statute-mapped compliance profiles, FK-bound to live corpus snapshots
  • SHA-256 content hash on every InstitutionalPacket — verifiable by third parties
  • Append-only PacketEvent log for every state transition
  • Restatement chain via restatement_of FK and is_restatement flag
  • "Unknown" disclosures are first-class payloads, never omitted
  • PII redaction available via redact_pii_from_snapshot() with audited PII_REDACTED event

Product page: Resale Certificates. Statutory deep dive (Washington): Washington Condo Resale Certificate Requirements.

CARI Methodology

5 weighted components · methodology v1.0 frozen · third-party verifiable

The Community Association Risk Index summarizes governance, financial, and operational risk for community associations as a 0–100 score with letter-grade band. Consent-gated, deterministic, hash-chained, and exposed via authenticated API for lenders, insurers, and title companies.

Component weights

  • Financial health — 30%
  • Governance — 25%
  • Vendor risk — 15%
  • Enforcement integrity — 15%
  • Payment behavior — 15%

Where the full methodology lives

CARI is operated under the cariscore.com brand and its complete methodology — component computation, grade thresholds, confidence assessment, hash chain integrity, dispute and recalculation policy, and version history — is published at cariscore.com/cari/methodology/. Methodology v1.0 was frozen on 2026-05-02 via data migration and is immutable while marked ACTIVE.

Embedment pattern

Every institutional artifact CommunityPay issues — resale certificates, reserve funding reports, close evidence packs, vendor records, and governance attestations — carries a hash-bound cari block in its evidence snapshot when the issuing HOA has embed consent. The block is part of the artifact's content hash, so it cannot be stripped or altered without invalidating the artifact. This is the FICO-stamp-on-every-document pattern translated to community associations.

Evidence
  • Immutable CariScore records — .save() rejects updates after creation
  • Deterministic SHA-256 calculation_hash bound to inputs (signals, weights, methodology version)
  • Consent-gated — no score query without active CariConsent from the HOA
  • Methodology versioning with a frozen v1.0 ACTIVE row; calibration validated pre-freeze via synthetic-HOA backtesting
  • Public verification endpoint resolves any calculation_hash to its source record — no auth required

Ledger Integrity Methodology

JournalEngine choke point · 14 enforcement guards · daily integrity scan

Every financial decision flows through a single posting interface (the JournalEngine) and a mandatory decision point (the Enforcement Dispatcher). Every journal entry has a corresponding immutable EnforcementDecision record. No decision logged means a bypass or a bug — and the integrity scan catches both.

The two choke points

  • JournalEngine. The only interface for creating journal entries. No code path in the codebase creates a JournalEntry directly. Every entry must declare its transaction type, lines, and enforcement context.
  • Enforcement Dispatcher. Every journal entry runs through a transaction-type-specific guard chain. Decisions are ALLOW, BLOCK, or OVERRIDE. Every outcome is logged with a full signal snapshot at decision time.

The 14 production guards

Each guard enforces one invariant: balance (debits = credits), closed-period rejection, fund segregation, trust segregation, subledger reconciliation, fund eligibility, bill-payment limits, vendor risk, reversal validity, loan covenant evaluation, payment-split correctness, interest-calculation correctness, the accounting equation, and trust commingling prevention. Guards are stateless, independent, and composable.

Ledger Integrity Scan

A daily scan verifies six properties: unbalanced entries, orphaned journal lines, missing enforcement decisions, unassigned funds, closed-period violations, and control-account vs subledger reconciliation (AR, AP, loans). Findings are recorded as immutable IntegritySnapshot + IntegrityFinding records with severity bands. CRITICAL findings raise alerts; INFO findings build the audit trail.

Evidence
  • Single posting interface — direct JournalEntry creation is architecturally impossible in business code
  • Two-phase enforcement design preserves balanced JEs even if telemetry creation fails — never lose a valid financial transaction to a logging bug
  • Daily LedgerIntegrityScan with SHA-256 content hash on every snapshot
  • All EnforcementDecision, EligibilityEvaluation, and IntegritySnapshot records are immutable
  • Control-account reconciliation enforces GL ↔ subledger consistency with $0.02 tolerance

Architectural deep dive: The Missing Layer in HOA Accounting.

Governance & Updates

Methodology changes are deliberate and recorded. We do not silently re-weight, rename, or backdate.

How methodology evolves

  • Statutory changes propagate from the legal corpus to dependent profiles and articles automatically via the ContentCitation drift-detection chain. The article's revision history records the change.
  • CARI weights are frozen at the methodology version level. Material changes require a new version with public documentation and a transition window.
  • Ledger guards are versioned in the manifest and CI-enforced. Adding, removing, or re-ordering a guard requires manifest updates and corresponding test coverage.

How to dispute or report a methodology issue

Contact scott@communitypay.us with the artifact identifier (hash, packet ID, or score ID) and the specific concern. Disputes are logged and tracked. Score recalculations follow the dispute and recalculation policy published at cariscore.com/cari/methodology/.

Review schedule

  • Legal corpus statutes — every 90 days (rolling)
  • Cornerstone articles — every 6 months
  • CARI methodology version — annual review; material changes require new version
  • Compliance profiles — on every legislative session for the covered state
  • Ledger integrity scan — daily automated, monthly summary review

Scott Vuilleumier

Last reviewed May 10, 2026.

© 2026 CommunityPay, Inc. All rights reserved.

Privacy Policy Terms of Service
Login