Loading...
CATEGORY DEFINITION · GOVERNED TRUTH
A single source of truth assumes one system can be right.Several of yours are right at once.
That is why consolidation projects stall. The problem is not that data is scattered; it is that no one has been given the authority to say what the business accepts as true when legitimate systems disagree. When systems disagree, the operator governs.
Senior housing has many systems but no governed enterprise operating record. SeniorCRE provides operator-controlled operating infrastructure that establishes that record. Operators can govern the systems they already have or run selected domains directly on SeniorCRE. In either case, the operator determines what is authoritative.
Definitions, Authority, Reconciliation and Lineage turn data into governed truth; the Operator Authority Chain™ carries that truth into human decisions and authorized execution. AI comes after governance, not before it.
Two forms of operator authority: data authority — who decides what is true? — and architecture authority — who decides what systems remain or are replaced? Both answers are the operator.
Unified data is not governed truth
Moving every number into one warehouse produces agreement about location, not agreement about meaning. Two systems can both be correct and still disagree — a census figure recorded at midnight and one recorded at billing cutoff are both real. Governance is what determines which figure the business is authorized to act on.
Definitions · Authority · Reconciliation · Lineage
Illustrative governance diagram. It depicts the governance model and design intent, not operator results, customer deployments, production performance, or verified outcomes.
The wrong model, and the model that holds
- One system holds the truth.
- One record governs the truth. Source authority is assigned per metric, entity and period.
- Truth is whichever system reported most recently.
- Truth is what the operator has authorized the business to rely on, with the rule written down.
- Integration ends disagreement.
- Integration moves data. Reconciliation is a governed discipline that resolves disagreement.
- Consolidation requires replacing incumbent systems.
- Govern first. Replace only by choice — including when SeniorCRE is selected as the clinical system of record.
The four governance disciplines
- Definitions — what the number means, stated once for the organization.
- Authority — which source governs for this metric, entity and period.
- Reconciliation — what happens when valid sources disagree, decided by rule rather than repeated by hand.
- Lineage — the ability to reconstruct the governed value and the decision made on it.
Definition
What “canonical” means here
Canonical means the governed representation produced after definitions, source authority and reconciliation have been applied — not a database that is right about everything.
- Definition
- The metric, entity or period has an approved definition the operator authorized — not a vendor default.
- Source authority
- A declared source governs each field. The EHR can be authoritative for clinical data, payroll for labor, the GL for finance. That authority is legitimate and is preserved, not overwritten.
- Reconciliation
- Where authoritative systems disagree, the disagreement is detected and resolved once under the operator’s approved rules, with lineage from disagreement through authorized value.
Authority stays with the operator and with the source systems that legitimately hold it. What SeniorCRE keeps is the reconciled value the operator has declared the enterprise accepts as true, and the lineage proving how it was reached.
What it never means
- — SeniorCRE is the one system that is right about everything.
- — Source systems stop being authoritative for their own domains.
- — Truth is a storage location rather than an authority decision.
- — A copy of operating data is authoritative because it is centralized.
Govern first. Replace only by choice.
One Operator-Controlled Operating Record. Explicit source authority.
The four governance disciplines
Definitions — what the number means
Authority — which source governs
Reconciliation — what happens when sources disagree
Lineage — how the governed value can be reconstructed
Claim status: what is proven, what is designed
Status as of October 16, 2026 (last modified 2026-10-16)
| Claim | Evidence step | What is true today | Proof to inspect |
|---|---|---|---|
| Operator and portfolio workspace foundation built (roles, hierarchy, entity tree). | Validation-exercised | Provisioning controls have been exercised repeatedly in controlled SeniorCRE conditions, including the operator onboarding wizard. Not yet performed for an operator in production; no standard duration is published. | Control test record; synthetic or de-identified data; no operator PHI. |
| Single-community acceptance boundary. | Designed | A gate sequence derived from the migration and acceptance model. No community has gone live for an operator, so no observed duration exists. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Portfolio-wide rollout acceptance across multi-community scope. | Designed | A wave-cadence model from the deployment plan. Sequencing depends on community count, system count, data condition, source access, and operator authority decisions. Not a completed rollout. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Connectors to PointClickCare®, MatrixCare®, Yardi®, and QuickBooks®. | Built | Built in a SeniorCRE test environment and demonstrable with synthetic extracts only. No named connector is live, and none runs in operator production. | Test-environment demonstration on request; demonstration data only; no operator data. |
| Operator-Controlled Operating Record: source authority, reconciliation, field-level lineage. | Designed | The Operator-Controlled Operating Record is designed and not yet implemented in any community. Authority rules, reconciliation, and field-level lineage are design intent; synthetic examples do not establish working governance. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Clinical configuration: SeniorCRE as clinical system of record, or alongside an incumbent eMAR read one direction only. | Designed | Designed, not built for operator use. SeniorCRE's native medication administration and eMAR are roadmap and not built; the read-only configuration alongside an incumbent eMAR depends on the Operator-Controlled Operating Record, which is designed and not yet implemented in any community. One authoritative medication record at all times is a design rule. | Written deployment plan and acceptance-gate model. No execution record exists. |
| Barcode-verified administration with an automated five-rights check at the point of medication pass. | Designed | Not built. Corrected September 7, 2026: earlier pages, operator training guides, and generated answers described this control as running, which was false. Implementation boundary: four of the five medication scan surfaces open a camera preview with no decoder and match only a manually typed NDC; one mobile surface decodes frames through the browser-native BarcodeDetector API where the browser supports it (Chromium/Android; not iOS Safari, not most desktops) and compares the NDC alone. No decoding library is bundled, no surface verifies resident, dose, route, or time, and no scan result blocks an administration. The five rights are verified by the administering clinician, not by SeniorCRE. | Build-queue entry with scope and dependencies. No implementation exists. |
| Live write-back into operator payroll and scheduling systems. | Designed | Specified and in the build queue. Read-side ingestion only today. | Build-queue entry with scope and dependencies. No implementation exists. |
| Implementation effort required from the operator. | Designed | Deployment is staged, not effortless: platform access, source access, authority rules, reconciliation, security review, and any history migration are scoped work with operator-side effort. Any claim of zero implementation would be false. | Written deployment plan and acceptance-gate model. No execution record exists. |
- Validation-exercised
- Controls can be shown in controlled SeniorCRE conditions using synthetic or de-identified data only.
- Built
- Implemented and demonstrable in a controlled SeniorCRE test environment with demonstration data only. Not validated with an operator.
- Designed
- Specified and sequenced by readiness and acceptance gates — but not yet executed with an operator. Not a duration claim.
- Designed
- Specified and in the build queue. No built capability exists to demonstrate.
Status and evidence class as of October 16, 2026. SeniorCRE has no operator-production deployment. Public timing is gate-based and operator-specific; no standard go-live duration is published. Maintained and reviewed by John Hauber, Founder, SeniorCRE, LLC. A medication-safety control was described on earlier pages as running when it was not; that correction is published in full at /medication-safety-claim.
Bring institutional discipline to your senior housing portfolio.
SeniorCRE is the operating, compliance, and asset-management layer for REITs, family offices, and institutional capital allocators in senior housing & care.
no SeniorCRE SOC 2 report claimed Multi-Entity Hierarchy Audit-Ready