Loading...
THE · OPERATING · RECORD
Your systems can all be correct and still disagree.
Each system can answer its own question correctly while leadership still has to decide which definition and which source govern a consequential decision. The operating record is not a forced EHR replacement, data warehouse, dashboard, or AI assistant; operators may retain an incumbent or choose SeniorCRE for a system-of-record role.
When systems disagree, the operator governs.
Arrived looking for an AI data platform? A data platform assembles the numbers. This page is about the layer above it: who declared each definition, which system was allowed to be right, and what the operator authorized the enterprise to treat as true before a decision was made.
See the mechanism · Occupancy, current week
Illustrative model
3 readings → 1 approved
One number you can run on, with the evidence attached.
Each field has one approved definition, one governing source, and a reconstructable lineage from decision back to record state.
Illustrative exemplar of the governed workflow, modeled — not measured from an operator deployment. No operator production integrations as of September 29, 2026.
I · The premise
Every organization already has an operating record. Yours is fragmented and informal.
It exists in the census file someone rebuilds each Monday, in the version of the variance a regional trusts, in the corrections a controller remembers making, in the explanation a director gives a surveyor from memory. It is real, it is load-bearing, and it is undocumented.
The question is not whether your organization has an operating record. It is whether the organization governs it — or whether it lives in people, spreadsheets, and habit, and leaves when they do.
II · The definition
The operating record is the record the organization agrees to run from. It shows which number governs, why it governs, and where it came from.
It is not software, and it is not a report. It preserves what happened, which facts were authoritative, how they were reconciled, who approved them, and which decisions they informed — the answer an organization can still give, years later, to the question on what basis did we decide that?
- The general ledger
- What the organization accepts as financial fact.
- The legal entity
- Who is accountable, and for what.
- The audit trail
- What can still be proven after the fact.
- The operating record
- What the organization accepts as operating truth — and which decisions relied on it.
Three of those are already non-negotiable in every serious enterprise. The fourth is the one senior housing & care has been operating without.
III · The structural limit
Your systems can all be right and still disagree.
Each was built for a different purpose and can be authoritative inside its own boundary. None was designed to settle a disagreement that spans care, labor, census, revenue, compliance, NOI, and capital.
- EHR / eMAR
- Built for: Documenting clinical care for the resident in front of you.It was never asked which financial or labor figure the enterprise should accept.
- Accounting / GL
- Built for: Producing a defensible financial statement for a period.It receives operational facts; it does not adjudicate them at the source.
- HR / scheduling / payroll
- Built for: Paying people correctly and staffing the building.Labor truth stops at the pay period, not at the decision.
- CRM / admissions
- Built for: Moving an inquiry to a move-in.It records intent, not the reconciled census the enterprise runs on.
- BI / warehouse
- Built for: Displaying what the systems already said.It reports disagreement faster; it holds no authority to resolve it.
Integration connects these systems. Connection is not authority. Something has to sit above them and hold the answer.
IV · What changes
A reconciliation meeting becomes a decision meeting.
Without a governed record
The first thirty minutes establish which number is real.
Whoever brought the most defensible spreadsheet sets the agenda. The decision happens at the end, if there is time.
With a governed record
The number is settled before the room opens.
The meeting exists to decide and to assign, because definition, source authority, reconciliation, and lineage were governed in advance.
That is the whole reframe. The purpose of leadership time changes from establishing truth to exercising judgment.
V · The smallest undeniable example
A question asked eleven months later.
In March, leadership approved added agency coverage at one community based on an acuity and census reading. In February of the following year, a lender asks why that quarter missed labor plan. Everyone who was in the room has moved on or moved roles.
The figure that was used
Not today’s recomputed number — the value as it stood when the decision was made.
The definition in force
Which version of “occupied” and “acuity-weighted hours” applied in that period.
The governing source
Which system was authoritative for it, and which conflicting reading was set aside.
The approval
Who accepted the figure as the basis for the decision, and when.
The decision it informed
The coverage approval itself, linked to the record state that supported it.
This is not a cleanup. The same disagreement returns with the next schedule and the next close: whether an on-call hour that was never worked belongs in agency hours is a defensible question with two defensible answers. A governed record does not settle it once — it holds the rule that settles it every time, with the reasoning attached.
A better report can recompute the number. It cannot reconstruct the decision. That gap is not a reporting gap — it is a different layer, and this is the test that proves it.
Illustrative walkthrough of governed decision lineage. It is not a measured operator outcome and does not describe a live production integration.
VI · Why it matters beyond operations
When numbers conflict, trust erodes. An operating record is trust infrastructure.
Each unresolved disagreement is small. Their accumulation is not. Teams begin hedging their own figures, leaders discount what they are shown, boards ask for backup instead of recommendations, and lenders price the uncertainty. The cost is not a wrong number. It is diminished confidence in the act of operating.
An Operator-Controlled Operating Record restores that confidence, because it makes truth institutional rather than personal. What the organization remembers no longer depends on who stayed.
One field, governed
What one Operator-Controlled Operating Record actually looks like.
Three defensible readings
- Property managementUnit released on move-out day87.4% occupancy
- Clinical recordUnit held until discharge closed88.1% occupancy
- Billing calendarBilled days, third calendar86.9% occupancy
None is wrong inside its own boundary. That is exactly the problem.
The governed record
- Definition
- Occupancy v4 — operator-approved, versioned, reproducible
- Source authority
- Property management system for unit status
- Reconciliation rule
- Defer to clinical discharge date when the two differ by more than 24 hours
- Approval
- Named accountable role, with timestamp
- Lineage
- Every reading retained, nothing overwritten, replayable later
The governed figure is governed because the approved definition assigns authority for that field, that entity and that period — never because it averages the systems.
Illustrative governance example. Figures are design intent, not operator results, customer deployments, production performance, or verified outcomes.
The core distinction
Leadership can decide from the same operator-controlled operating record.
Census, labor, care, compliance, NOI, and capital decisions can use the number the organization agreed would govern, with the reason and source preserved.
- Definitions
- What does the number mean?
- Authority
- Which source governs for this metric, entity and period?
- Reconciliation
- What happens when valid sources disagree?
- Lineage
- Can the resulting value and decision be reconstructed?
Replacement doctrine
SeniorCRE does not require an operator to replace the systems already in place. Where an incumbent system remains authoritative, SeniorCRE governs its data within the operating record. Where SeniorCRE is deliberately selected to assume a system-of-record role — including clinical configurations using SeniorCRE EHR/eMAR — the operator can replace the incumbent by choice.
Govern first. Replace only by choice.
One Operator-Controlled Operating Record. Explicit source authority.
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.
See it against your own systems
Request an Executive Briefing
Bring us the number your team has to reconcile. We trace its definition, source authority, reconciliation, lineage, and the decision that depends on it.
A small number of operators co-develop this record with us: the Founding Developer Partnership.
Institutional trust markers
Built for multi-community senior housing & care operators — and the procurement teams that evaluate them.
Multi-community operators, REITs, private equity, lenders, and multi-state portfolios evaluate the same nine markers before they sign. Each one is documented, enforced in the platform, and reviewable in the Trust-by-Design procurement package.
Current assurance status
HIPAA-safeguarded controls; no SOC 2 certification or report claimed. No completed independent penetration-test report claimed.
HIPAA posture
HIPAA-safeguarded controls today: encryption at rest and in transit, BAA execution, PHI segregation, and signed-URL access to PHI buckets.
Architecture overview
Operator-controlled definitions, source authority, reconciliation, and lineage across clinical, financial, workforce, compliance, and capital surfaces. Multi-tenant with database-enforced isolation.
Interoperability standards
A documented ingestion path for operator-supplied clinical, property, and accounting exports. Named-vendor connectors are ROADMAP; no third-party integration is live in operator production today. AI reads only the fields the operator declared readable.
Security framework
SOC 2 in progress (underlying AWS infrastructure maintains its own SOC 2 reports), MFA required, session timeout, concurrent-session limits, continuous automated vulnerability scanning.
Audit logging
Immutable, append-only logs with UTC-millisecond timestamps, full user/session context, and 7-year retention.
Role-based permissions
33-role RBAC hierarchy. Property-level tenant and role gates enforced at the API layer (Fastify + tRPC on AWS) with WorkOS-authenticated sessions and defense-in-depth checks in PostgreSQL.
Multi-community scalability
Holding Co → Operator → Region → Property → Unit hierarchy. Portfolio rollups computed from the Operator-Controlled Operating Record at request time. Designed for multi-state, multi-payer, multi-entity ownership.
Full detail on each marker, evidence inventory, and the Trust-by-Design procurement package live on the Trust Center.
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.
Answer First
Updated September 23, 2026What is the operating record?
The operating record is the governed record per resident, care plan, ledger, shift, property/unit, and entity that every surface in senior housing & care reads from and writes to. Canonical here means the representation produced after definitions, source authority, and reconciliation have been applied — not a database that is right about everything. Source systems remain authoritative for their own domains; the record governs what the enterprise accepts as true, with lineage decided once rather than re-argued every month.
Key facts
- Canonical entities
- Six — resident, care plan, ledger, shift, property/unit, entity
- Functional domains
- Nine, resolved into one governed record
- Constituencies served
- Operators, owners, investors, brokers, vendors, lenders
- Reconciliation
- Governed by declared rule, not repeated manual effort
- Ownership
- Operator-owned, exportable with schema
Sources & citations
- Platform Architecture
How the operating record composes the stack.
- Security & Compliance Architecture
Isolation, audit, and access posture behind the record.
- Capital Layer
How owners, investors, and lenders read the operator’s record.
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.
01
ChapterThe category, in one line.
DALLAS, TX · CATEGORY BRIEF
Epic organized healthcare around the patient record. Every clinician, biller, researcher, and auditor reads the same chart. The chart is the record. Senior Housing & Care never had that primitive. Operators run nine vendors, owners read a different set of numbers, lenders read a third, brokers read a fourth, and the resident exists as a near-duplicate in each. SeniorCRE organizes senior housing & care around the operating record — the governed superset that resolves clinical, financial, workforce, and capital views into one governed representation.
Epic organized healthcare around the patient record. SeniorCRE organizes senior housing & care around the operating record.
02
The networkSix constituencies, one record.
| Constituency | What they read from the operating record |
|---|---|
| Operators | Live census, eMAR, shift workload, payer mix, period close — read at request time. |
| Owners & Sponsors | Property-level NOI, occupancy, covenant rollups assembled from the same governed record operators write. |
| Investors & REITs | Portfolio rollups, ESG metrics, threshold alerts — no BI overlay, no nightly ETL. |
| Brokers | Deal-to-ops handoff with audited operating history attached to every transaction. |
| Vendors | Scoped, approval-gated access to the entities they touch — never the whole record. |
| Lenders | Covenant visibility, DSCR, and operating evidence on the same record the operator runs the day on. |
03
PrinciplesWhat makes it a record, not a database.
One governed representation per object
The operating record maintains one governed representation of each governed object — resident, care plan, ledger, property/unit (bed is a unit-level child of Property, not a seventh entity), shift, entity — while preserving authority and lineage to the systems that originate the underlying events. This is not a claim that SeniorCRE physically owns the only resident row in the operator’s stack.
Operator-owned, exportable
The operator owns the operating record and declares which source is authoritative for each governed object. SeniorCRE holds only what the operator declared, and preserves it: the definition, the declared source, the reconciliation rule, and the lineage back to the originating rows. The operator exports the record at any time under the data sovereignty standard.
Audit-grade by construction
Every write to the operating record appends to an immutable log scoped to the same tenant hierarchy as the read path. Survey, SOC 2, and HIPAA evidence assemble from one query.
Governed where it lives
The record is governed where it lives, not where it is displayed. Replacement is not required — govern first, replace only by choice. SeniorCRE may govern an incumbent EHR/eMAR or serve as the clinical system of record where the operator selects it.
AI grounded in the record
The operator decides which parts of the record an assistant may read. Answers cite the record directly, and each one is traceable to a row the operator owns — never an inferred schema.
When SeniorCRE is the native system of record
One authoritative write path can serve multiple SeniorCRE surfaces. A med pass, an admission, a payer posting, or an MDS update is written once and read by the clinical, financial, workforce, compliance, and investor surfaces of the platform.
When an incumbent remains the system of record
SeniorCRE ingests the authoritative event with lineage to its origin system and applies operator-approved reconciliation rules to produce the governed enterprise record. The incumbent keeps its authority; the operator declares what the enterprise accepts as truth, and SeniorCRE keeps that declaration with its lineage.
The operator determines the authority topology — which system is authoritative for medication, workforce, ledger, and census — and those decisions can vary by community and by domain. Reconciled once under operator-approved rules rather than reconstructed repeatedly downstream.
The data model
04
The modelSix canonical entities.
Incumbent stacks were assembled the way the industry was bought: clinical here, finance there, CRM elsewhere, workforce somewhere else. Each product owns a different version of the resident, the ledger, and the bed. The architecture is not deliberate — it is inherited. The operating record replaces that inheritance with six entities, each owned exactly once.
The UI is replaceable. The dashboards are replaceable. The AI is replaceable. The operating record is what lasts.
| Entity | Owns | Surfaces it powers |
|---|---|---|
| Resident | Identity, demographics, payer, acuity, consent | Clinical · Billing · CRM · Family · Survey |
| Care Plan | MDS, ADL, IDT goals, PRN reassessments, QAPI flags | Clinical · QM engine · Survey · Family (gated) |
| Ledger | GL, AR, AP, period close, payer postings, accruals | Finance · Investor · Audit · Portfolio rollup |
| Shift | Schedule, clock, acuity-weighted workload, med-pass events | Workforce · Clinical · Payroll · Workload alerts |
| Property / Unit | Bed board, licensure, capacity, capex, occupancy | Operations · Investor · REIT · Asset management |
| Entity | Holding Co → Operator → Region → Property → Unit hierarchy | Permissions · Rollups · Tenant isolation · Reporting |
One governed record
Six entities. One write. Every surface reads the same governed record.
Hover any entity to trace the surfaces it powers. Click to lock the view. Nothing here is a dashboard — every line is a write path in the operating record.
The moat
Reconcile once under governed rules. Stop re-reconciling downstream.
Every surface — clinical, financial, workforce, compliance, investor — reads from the same governed record. A med-pass, an admission, a payer posting, an MDS update writes once.
- Entities
- 0
- Metric latency
- Request time
- Vendors collapsed
- 0–12
- Reconciliation hrs / wk
- 0
Visualization renders the canonical entity graph enforced at the database layer via RLS and has_role(uid, role).
05
ProofWhy the record is what lasts.
01
One write path, by configuration
When SeniorCRE is selected as the system of record, a med-pass scan, an admission, a payer posting, or an MDS update writes once and every SeniorCRE surface reads that write — not a copy, not a sync, not a nightly job. When an incumbent remains the system of record, SeniorCRE ingests the authoritative event with lineage to its origin system and applies operator-approved reconciliation rules to produce the governed enterprise record. The operator chooses which applies, by domain and by community; the record preserves that choice and the lineage under it.
02
Reconciliation governed once, not repeated daily
Reconciliation is one of the four disciplines of the operating record: definitions, source authority, reconciliation, lineage. Rules are decided once, in writing, and then enforced by the record — so census, ADT, billing, eMAR, and payroll disagreement is resolved by governed rule instead of by manual reconciliation in the recurring critical path.
03
Read at request time
Portfolio dashboards, covenant rollups, quality-measure views, and survey evidence are designed to read from accepted records with authority and lineage — no production latency claim is made.
04
Audit-grade by construction
Every event appends to an immutable log scoped to the same entity hierarchy as the read path. Survey, SOC 2, and HIPAA evidence assemble from one query, not nine.
05
Tenant isolation at the database
Isolation is scoped to operator, property, and unit at the data layer — not in middleware, not in a service mesh. Access is mediated by granular role-based access.
06
Queries the declared model, not an inferred one
Assistants are designed to cite the definitions, authority, and lineage the operator declared. Every answer resolves to evidence the operator owns and can export.
The point
This is not a critique of any single product. A modular stack works at one community, strains at ten, and fails at a hundred. The reason is structural, not effort: every product was built around its own data model, and scale multiplies every gap between them.
Record + intelligence
06
DistinctionThe record, and the intelligence above it.
For two decades the market bought senior housing & care software in two layers. The system of record captured what happened. The system of intelligence tried to read across all of it — usually a BI overlay stitched to a warehouse. SeniorCRE collapses the distance: intelligence is computed from the same governed record, at request time.
System of record
eMAR, MDS, ADL, care plans
Clinical events of record — IDT-signed, audit-stamped — mapped to resident evidence with source authority and lineage.
General ledger, AR, AP, period close
Financial events of record across SNF, AL, MC, IL — payer postings, accruals, and close reconciliations governed by accepted ledger definitions.
Schedule, clock, payroll, workload
Workforce events of record — acuity-weighted and ready for payroll and labor analysis with source authority preserved.
Bed board, ADT, occupancy, capex
Property and unit events of record — licensure, capacity, and capital pipeline aligned to the operator-declared entity hierarchy.
Sales CRM and admissions
Lead-to-move-in events of record — inquiry, tour, deposit, admission — connected to resident evidence after operator acceptance.
Survey, QAPI, controlled substances
Compliance events of record — surveyor-ready evidence, QAPI findings, and controlled-substance counts produced from primary rows.
System of intelligence
Portfolio rollups computed at request time
Census, NOI, agency exposure, payer mix, and covenant evidence aggregated across properties, computed from the Operator-Controlled Operating Record at request time — no nightly batch, no warehouse refresh.
NOI and length-of-stay decomposition
NOI bridges decomposed into occupancy, payer mix, agency labor, denials, and length of stay — read from primary records rather than rebuilt in a spreadsheet.
Risk detection across the portfolio
Threshold views on agency saturation, denial cohorts, survey exposure, controlled-substance variance, and nurse workload — propagated property → portfolio.
Quality-measure lineage
Quality measures traced back to the MDS and clinical events that produced them, so a number can always be walked back to its source row.
SeniorCRE Intelligence grounded in the record
Prove on one community, then scale. Every answer traceable to a row the operator owns and can export. Assistants read the declared source rows, not a federated copy.
Capital, REIT, and lender views
Covenant coverage, lease DSCR, IRC §856 income tests, and ESG metrics can be governed with operator-approved definitions, source authority, reconciliation, and lineage.
| Dimension | BI overlay on many systems | Operator-controlled operating record |
|---|---|---|
| How intelligence is produced | BI overlay ETL’d from many systems of record | Read from the canonical operating record |
| Time from event → insight | Hours to days (warehouse refresh) | Computed from the Operator-Controlled Operating Record at request time |
| AI grounding | Federated copies; schema drift | Canonical model; citable, exportable |
| Cross-domain question (admit → bill → covenant) | Multi-vendor stitching | One query against one model |
| Who owns the insight | BI vendor / IT | Operator owns the record — and the intelligence above it |
| When intelligence breaks | When any upstream schema shifts | When the operating record itself changes (versioned, governed) |
07
CoverageNine functional domains, one record.
01
Resident & clinical
Admission, chart, care plan, MDS, eMAR events and assessments resolved into one resident record across IL, AL, MC, and SNF.
02
Workforce
Schedule, clock, credentials, agency exposure, and acuity-weighted workload on the same shift row used for payroll.
03
Revenue cycle & finance
GL, AR, AP, payer postings, denials, accruals, and period close resolved into one ledger view per entity.
04
Census & occupancy
Bed board, ADT, move-ins and move-outs, and quality-occupancy measurement on one bed and one unit row.
05
Compliance & survey
Survey evidence, QAPI findings, policy attestations, and controlled-substance counts assembled from primary rows.
06
Sales & admissions
Inquiry, tour, deposit, and admission connected to the same resident the clinical team opens on day one.
07
Family & engagement
Scoped, consent-aware family visibility into the record — never a separate copy of the resident.
08
Asset & property
Licensure, capacity, capex pipeline, and property performance aligned to the ledger and entity hierarchy.
09
Capital & investor
Portfolio rollups, covenant coverage, DSCR, and disclosure packets read from the operator’s record with audited access.
08
Buyer guideHow to evaluate an operating record.
| Dimension | Operator-controlled operating record | Modular best-of-breed | Single-vendor suite |
|---|---|---|---|
| Architecture | One Operator-Controlled Operating Record above the systems you already run. | Best-of-breed joined by HL7/FHIR/CSV; the operator carries the integration tax. | Single-vendor suite; deep in one domain, thin elsewhere. |
| Care continuum | IL · AL · MC · SNF on one record; mixed acuity native. | Per-tool variation; transitions require re-keying. | Usually AL+MC or SNF, rarely both. |
| Portfolio rollups | HoldCo → REIT → OpCo → PropCo from one hierarchy. | Periodic BI rebuild; drifts each cycle. | Strong only when every property runs the same suite. |
| Data sovereignty | Operator-controlled export with documented schema. | Per-vendor terms; export quality varies. | Vendor-gated; export quality is a switching cost. |
| System replacement | None required — start where you sit. | Rip-and-replace per tool. | Suite migration. |
01
Which system owns the resident, and can you name it in one word?
If two systems both claim the resident, every downstream number is a reconciliation, not a read.
02
Can a portfolio number be walked back to the row that produced it?
Lineage is the difference between an operating record and a dashboard.
03
Who governs access — the operator, or each vendor separately?
Operator-controlled means one access model above the stack, not nine vendor consoles.
04
What happens on acquisition day?
A record you control absorbs a new entity into the hierarchy; a federation of vendors renegotiates six contracts.
05
Can you export the whole record, with schema, without a services engagement?
Data sovereignty is testable at contract time, not after the migration.
06
Does the Operator-Controlled Operating Record preserve operator-approved definitions, source authority, reconciliation, and lineage?
If not, leadership is deciding without a clear authority record.
09
Data pathHow AI reads the record.
- Grounding
- SeniorCRE Intelligence answers from the operating record. Retrieval is scoped to the requesting tenant and role before any model call.
- Minimization
- Prompts carry the narrowest slice of the record needed to answer. Clinical content is excluded from paths that do not require it.
- Contracts
- Where clinical data is in scope, processing runs under executed agreements including BAAs. Model providers are not permitted to train on operator data.
- Audit
- Every AI read appends to the same immutable, tenant-scoped audit log as human reads, so an AI answer can be reconstructed after the fact.
- Posture
- No vendor or payor integration runs in an operator production environment today. Outbound clinical transmission is not enabled; items described here are specified; status is stated item by item.
Context engineering bridge
The record packages governed context for a specific task.
The operating record does more than store data. For an AI answer, it assembles the narrow slice of accepted facts the task requires, plus the definitions, source authority, reconciliation rule, lineage, and authorization boundary that tell the model what it may rely on.
Read the context engineering explainer10
BoundariesWhat this is not.
- Not a data warehouse.
- A warehouse copies operational data on a schedule. The operating record is the governed record itself. Nothing is copied to make it readable.
- Not a BI overlay.
- A BI overlay exists to reconcile disagreement between systems. The record resolves the disagreement instead of displaying it.
- Not integration plumbing.
- Integrations synchronize two sources of truth. The record governs one.
- Replacement is not required.
- Govern first. Replace only by choice. Start where you sit and the record is governed above the systems you run; where an operator selects it, SeniorCRE can also carry the clinical record as the system of record.
11
IngestionHow data reaches the record.
The record is only as governed as the path data takes to get into it. SeniorCRE specifies five ingestion modes, to be chosen per source system and per property rather than imposed portfolio-wide. None is built yet. Modes are ordered by how much the source system has to change — Mode A requires nothing beyond exports the operator already produces.
| Mode | How it works | Cadence | Status |
|---|---|---|---|
| Mode A — Operator-exported files | Census, payroll, GL trial balance, and staffing exports the operator already produces, mapped into canonical entities at load time. | Per export (typically daily to monthly) | Not yet built — specified; depends on the operating record, which is not built yet |
| Mode B — Scheduled report drop | A recurring drop to a governed location (SFTP or object storage) with a fixed file contract, so mapping does not change between periods. | Scheduled — daily or weekly | Not yet built — specified; depends on the operating record, which is not built yet |
| Mode C — Read-only database or replica view | Read-only access to a reporting replica or vendor-provided views, pulled on a defined window with no write path back to the source system. | Defined pull window | Design intent — not live in operator production |
| Mode D — Clinical event feeds (HL7 / FHIR) | ADT, order, and observation events mapped to resident and care-plan evidence, with PHI classification required before storage. | Event-driven | Design intent — outbound clinical transmission not enabled |
| Mode E — Vendor API connectors | Direct system-to-system connectors to EHR, PMS, payroll, and scheduling vendors under executed agreements. | Vendor-defined polling or webhook | Roadmap — no vendor integration is live in operator production today |
- Mapping is declared, not inferred
- Each source field is mapped to a canonical entity field in a versioned mapping contract. Unmapped fields are quarantined rather than silently coerced, so a schema change surfaces as a mapping failure instead of a wrong number.
- Identity resolution before storage
- Inbound rows resolve to an existing resident, bed, shift, ledger, or entity before they are written. Rows that cannot be resolved land in an exception queue attributable to a named source and period.
- Sync metadata travels with the row
- Every ingested row carries its source system, source period, load timestamp, mapping version, and load batch. That metadata is what makes a portfolio figure walkable back to a source row.
- Period integrity
- Restatements create a new versioned load for the period rather than overwriting the prior one, so a number a lender saw last quarter can still be reproduced.
- No write-back by default
- Ingestion is read-only into the record. SeniorCRE does not write into the operator’s EHR, PMS, or payroll system as part of establishing the record.
12
Trust scoreHow trust in the record is measured.
A governed record has to state how much it can be trusted for a given period, per property, per source. The trust score is specified, not built. As designed, it is not a single opaque number: it decomposes into four sub-scores that can each be inspected, and it is reported alongside the figure rather than behind it. A figure with a degraded sub-score is still shown — labeled, not hidden.
| Sub-score | What it measures | What degrades it |
|---|---|---|
| Freshness | Age of the most recent accepted load per source, per property, against that source’s expected cadence. | A late or missed drop, a stalled pull window, or a source that silently stopped producing. |
| Completeness | Share of expected entities and required fields present for the period — properties reporting, beds accounted for, shifts with hours, accounts with balances. | Missing properties, partial payroll periods, unmapped cost centers, gaps in the bed board. |
| Reconciliation | Agreement between sources that should describe the same fact — census vs. billing days, scheduled vs. paid hours, ledger vs. subledger. | Cross-system variance beyond a declared tolerance for the period. |
| Lineage | Share of reported figures that resolve to source rows with intact sync metadata (source, period, batch, mapping version). | Manual adjustments, unattributed overrides, or figures assembled outside the record. |
Methodology
Methodology posture: trust scoring is specified against the ingestion modes above and is not yet built. Thresholds and tolerances are set per operator during governed deployment rather than published as universal defaults, because expected cadence differs by source system.
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.
How SeniorCRE meets you where you are
Integrate where needed. Unify where possible. Operate above the stack.
You do not have to rip out your stack on day one. SeniorCRE reads where authorized, governs where accepted, and becomes the Operating Infrastructure above the fragmented systems you already run — so leadership sees which definition and source governs each figure, while underlying tools are retired only if and when the operator chooses.
Integrate
Read authorized EHR, eMAR, CRM, billing, payroll, and accounting records through governed ingestion patterns — operators retain incumbent systems where they work and replace them only where SeniorCRE is deliberately selected for that role.
Unify
Govern resident, care plan, ledger, shift, property, and entity evidence with explicit definitions, source authority, reconciliation, and lineage.
Operate
Sit above the stack as the Operator-Controlled Operating Record — target-state portfolio visibility, exception alerts, and AI workflows only after authority is declared.
What lives in the operating record
Resident — identity, demographics, payer, acuity, consent
Care plan — MDS, ADL, IDT goals, PRN reassessments, QAPI flags
Ledger — GL, AR, AP, period close, payer postings, accruals
Shift — schedule, clock, acuity-weighted workload, med-pass events
Property / Unit — bed board, licensure, capacity, capex, occupancy
Entity — Holding Co → Operator → Region → Property → Unit hierarchy
Immutable audit log scoped to the same tenant hierarchy as the read path
Claim status: what is proven, what is designed
Status as of September 29, 2026 (last modified 2026-09-29)
| Claim | Evidence step | What is true today | Proof to inspect |
|---|---|---|---|
| Operator and portfolio workspace foundation built (roles, hierarchy, entity tree). | Validated | 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. | Architecture 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. | Architecture 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®. | Validated | Ingestion and normalization exercised against synthetic and de-identified extracts in controlled SeniorCRE conditions. No third-party integration is live in operator production. | Control test record; synthetic or de-identified data; no operator PHI. |
| Operator-Controlled Operating Record: source authority, reconciliation, field-level lineage. | Architecture 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. | Validated | Both configurations are built and exercised in controlled SeniorCRE conditions, with one authoritative MAR at all times. No PHI workload runs in operator production. | Control test record; synthetic or de-identified data; no operator PHI. |
| Barcode-verified administration with an automated five-rights check at the point of medication pass. | Architecture 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. | Architecture 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. | Architecture 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. |
- Validated
- Controls can be shown in controlled SeniorCRE conditions using synthetic or de-identified data only.
- Architecture designed
- Specified and sequenced by readiness and acceptance gates — but not yet executed with an operator. Not a duration claim.
- Architecture designed
- Specified and in the build queue. No built capability exists to demonstrate.
Status and evidence class as of September 29, 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.
Operating record vs. the alternatives
Source authority for census
- SeniorCRE operating record
- One governed representation per resident and bed, with lineage to originating systems
- EHR + PMS + BI
- Disputed across EHR / PMS / CRM
- Spreadsheet rollups
- Whatever was last pasted
Metric latency
- SeniorCRE operating record
- Computed from the Operator-Controlled Operating Record at request time
- EHR + PMS + BI
- Nightly ETL
- Spreadsheet rollups
- Weekly at best
Audit evidence
- SeniorCRE operating record
- One query, one immutable log
- EHR + PMS + BI
- Multi-system stitching
- Spreadsheet rollups
- Manually reassembled
Investor / lender view
- SeniorCRE operating record
- The same governed record the operator wrote
- EHR + PMS + BI
- BI overlay on top of copies
- Spreadsheet rollups
- Emailed file
Data ownership
- SeniorCRE operating record
- Operator-owned, exportable
- EHR + PMS + BI
- Distributed across vendors
- Spreadsheet rollups
- Local to a laptop
AI grounding
- SeniorCRE operating record
- Canonical, citable
- EHR + PMS + BI
- Federated, drift-prone
- Spreadsheet rollups
- Not possible
| Dimension | SeniorCRE operating record | EHR + PMS + BI | Spreadsheet rollups |
|---|---|---|---|
| Source authority for census | One governed representation per resident and bed, with lineage to originating systems | Disputed across EHR / PMS / CRM | Whatever was last pasted |
| Metric latency | Computed from the Operator-Controlled Operating Record at request time | Nightly ETL | Weekly at best |
| Audit evidence | One query, one immutable log | Multi-system stitching | Manually reassembled |
| Investor / lender view | The same governed record the operator wrote | BI overlay on top of copies | Emailed file |
| Data ownership | Operator-owned, exportable | Distributed across vendors | Local to a laptop |
| AI grounding | Canonical, citable | Federated, drift-prone | Not possible |
How a write becomes an operating record
- 1
Capture at the workflow
A med-pass scan, an admission, a payer posting, or an MDS update is captured in the daily workflow — eMAR, CRM, ledger, scheduler.
- 2
Resolve to the canonical entity
The event resolves to the Operator-Controlled Operating Record for the resident, ledger, shift, or bed — never to a side-system copy.
- 3
Append to the audit log
The write appends to an immutable, tenant-scoped audit log that survey, SOC 2, and HIPAA evidence read from.
- 4
Read by every surface
Operator dashboards, investor rollups, lender covenant views, and SeniorCRE Intelligence all read the same governed record — no ETL window, and no manual reconciliation step between them.
Related Institutional Resources
Platform Architecture
Security & Compliance Architecture
Capital Layer
Operating Infrastructure Spec
Stuck With a Stack
Institutional Trust
What makes an operating record governed
“Governed” means more than approved
A record can be complete, auditable, evidence-backed and human-attested and still leave an enterprise question unanswered: which definition had authority to govern this decision?
Senior housing & care enterprises operate across clinical, workforce, occupancy, compliance, financial and capital systems. Those systems can produce different values without any system being wrong. An Operator-Controlled Operating Record preserves those facts, establishes the applicable definition and authority, and records why one meaning governed a particular decision.
A record is not governed merely because:
- The data is centralized.
- Records are unified, matched, merged or deduplicated.
- Institutional context is remembered.
- Evidence is attached.
- A person approved something.
- Every change is logged.
- AI has permissions.
- Workflows follow rules.
- The record is auditable.
Those are important controls, and increasingly standard across enterprise software. Nothing here suggests they are easy or that they are ours. Governed operating truth requires something further.
Seven objects the operator must establish
- 01Definition
What exactly does the fact mean?
The metric, entity, period and measurement moment are written down and approved by the operator — not inherited from whichever system happened to produce the number.
- 02Source authority
Which source is authorized for that definition?
A named system holds authority for that definition, and the reason it holds authority is recorded. Domain systems keep the authority that legitimately belongs to them.
- 03Decision context
For what decision does that authority apply?
Authority is scoped to a decision, not asserted globally. The definition that governs staffing is not necessarily the definition that governs a covenant.
- 04Reconciliation
What happens when another legitimate source differs?
A deterministic rule, written before the disagreement, applied the same way every period, with a stated variance tolerance.
- 05Adjudication
Who possesses authority to resolve disagreement when policy cannot?
A named role, established in advance, whose ruling is recorded against the value — so it does not have to be re-argued next period.
- 06Lineage
Why did this value and this definition govern?
Not only where the number came from. Which definition applied, which source held authority, which rule resolved the difference, and who ruled.
- 07Preservation
What other valid facts existed, and why did they not govern this decision?
Competing legitimate values are kept, not eliminated. A record that deletes the alternative cannot explain the decision it did not make.
Governed truth
Data
Definition
Authority
Decision context
Reconciliation
Governed truth
Decision
Execution
The governing doctrine is unchanged: EVIDENCE → DISAGREEMENT → AUTHORITY → GOVERNING RECORD → INTELLIGENCE → EXECUTION. These seven objects are what the Governing Record contains. Authorization sits between decision and execution; it is not a fifth stage.
Attestation answers: “Who approved this determination?”
Authority answers: “Why did this definition govern this decision?”
Auditability proves what happened. Authority lineage proves why it was allowed to govern.
The question is no longer whether a record is governed. The question is: what does the governance have authority over?
Definitions, source authority, decision context, reconciliation, adjudication, lineage and preservation are built; external operator deployments have not begun. Enforcement of these objects through a single agent gateway — including any MCP-exposed path — is architecture and design intent on the build roadmap, not a live capability.
Human authority
Human-in-the-loop is necessary, and it is not sufficient
Three concepts are routinely treated as one. They are not the same, and only the third settles an enterprise dispute.
- 01
Human review
A person checks AI output.
- 02
Human attestation
A person takes responsibility for a determination.
- 03
Institutional authority
The organization has established that this person or role possesses authority over this definition or this decision.
SeniorCRE supports review and attestation, and is designed around institutional authority: the record of who was established to decide what governs, before the disagreement occurred.
Who approved it?
Who had authority to decide what governs?
Systems hold facts. Decision layers organize evidence. The Operator-Controlled Operating Record establishes what has authority to govern.
Trusted data should be the result of governance — not the assumption that precedes it.
Connected systems provide broader information. Interoperability moves information across workflows. AI can organize that information and support human judgment. Responsible AI governance can constrain how it is used. These are valuable capabilities, increasingly available across enterprise software, and SeniorCRE claims none of them as unique.
Unifying, matching, merging, deduplicating and remembering data can make the available information cleaner and more useful. None of those operations establishes authority when legitimate systems disagree.
When independently authoritative systems contain different legitimate answers, “trusted data” does not by itself determine which definition applies, which source possesses authority, for which decision, during which effective period, under which exception, or why that meaning governed. An Operator-Controlled Operating Record makes those determinations explicit.
Ground truth is not something a platform gets to declare. The operator declares the definition, assigns source authority, governs reconciliation, and preserves the decision with lineage.
An institutional operator should be able to demonstrate not merely that its data is trusted, connected or interoperable, but why a particular definition and source possessed authority for a consequential decision.
Connected information tells the operator more. Operator authority determines what governs.
Illustrative — not operator data
Which trusted value has authority for this decision?
Operational occupancy
91.7%
Source: trusted · Value: valid
Revenue occupancy
89.9%
Source: trusted · Value: valid
The operating record preserves both values. Neither is an error to be eliminated.
- Decision
- Capital planning
- Applicable definition
- Revenue occupancy
- Applicable authority
- Financial Operating Record
- Governed value
- 89.9%
- Alternate valid value
- 91.7% preserved
- Authority lineage
- Recorded
Staffing counterexample
Staffing may legitimately invoke the operational definition instead: operational occupancy governs at 91.7%, while 89.9% remains preserved as a valid revenue value.
Lineage
Why each value governed its decision is preserved — definition, designated source authority, reconciliation state, and the human who adjudicated.
The system should not globally eliminate one value. The operator determines which valid meaning governs each consequential decision.
Trust is important. Authority makes trust institutional.
Definitions, source authority, reconciliation state, lineage and human adjudication are built; external operator deployments have not yet begun. Enforcement of these controls through a single agent gateway — including any MCP-exposed path — is architecture and design intent on the build roadmap, not a live capability.
Where authority sits
Information explains the enterprise. Authority determines what governs.
Enterprise information describes what the organization knows. Operator authority determines which of several legitimate meanings governs a consequential decision.
Systems of record
EHR, CRM, PMS, workforce, ledger — each independently authoritative for its own domain.
Enterprise information
- Data
- Metadata
- Semantics
- Knowledge
- Policies
- Memory
Increasingly available from major enterprise platforms. A genuine improvement over reasoning across raw, disconnected systems.
Operator authority
- Definition
- Decision scope
- Source authority
- Reconciliation
- Human adjudication
- Lineage
Operator-declared, decision by decision. This is the layer SeniorCRE governs.
Governed operating truth
What the organization is authorized to treat as true for this decision.
Approved intelligence
Any authorized model or agent, reading what authority has already established.
Decision
Authorization
Sits between decision and execution. Not a fifth stage of the chain.
Execution
The governing framework is unchanged: EVIDENCE → DISAGREEMENT → AUTHORITY → GOVERNING RECORD → INTELLIGENCE → EXECUTION. Better information strengthens DATA. Operator authority is what produces TRUTH. When systems disagree, the operator governs.
The model can change. The authority should persist.
AI models, assistants and agents will continue to improve and change, and multiple vendors will supply them. The operator’s institutional definitions, authority rules, reconciliation history, decision rights and lineage should persist independently of the intelligence consuming them.
AI can reason. The operator governs.
The owner sets the standard. The operator retains authority. SeniorCRE makes the authority governable.
- The institutional owner
- Sets the standard it must be able to rely upon — and can require evidence of the control environment without dictating which systems the operator buys.
- The institutional operator
- Retains authority over definitions, source designation, reconciliation and adjudication, and demonstrates how operating truth is governed.
- SeniorCRE
- Makes the operator’s definitions, authority, reconciliation and lineage durable and repeatable across systems and communities.
An owner requires a standard of governance and evidence. It does not select the operator’s software stack.
Where truth is governed
Governed execution requires governed truth.
Execution policy determines what may happen. Truth policy determines what the enterprise is authorized to treat as true before it happens.
Source Systems
EHR, CRM, PMS, workforce, ledger — each preserved exactly as asserted.
Evidence & Provenance
Each assertion bound to its origin, timestamp, definition and lineage.
Disagreement Detection
Material conflicts surfaced, never silently averaged or overwritten.
Operator Authority Chain™
- Definitions
- Source authority
- Reconciliation
- Lineage
- Human adjudication
Operator-declared decision rights: who may decide, for which purpose.
Governing Record
The governing determination — what governs for this purpose, and why — with its authority, evidence and lineage.
SeniorCRE Intelligence
Reasons from governed context. Model confidence never creates organizational authority.
Controlled Execution
- Decision rights
- Permissions
- Approval boundaries
- Agent authority
- Audit
Actions only within explicit authority, policy, approval and audit boundaries.
The governing framework is six stages — EVIDENCE → DISAGREEMENT → AUTHORITY → GOVERNING RECORD → INTELLIGENCE → EXECUTION. Authorization and approval controls occur between decision and execution; they do not become a fifth stage. Govern the truth before you automate the decision. When systems disagree, the operator governs.
Controlled execution is not enough
Modern agentic platforms increasingly control AI execution through identity, permissions, deterministic business rules, human approvals, validations, and audit trails. Those controls matter, they are becoming standard properties of enterprise software, and SeniorCRE claims none of them as an invention.
But they begin after another institutional question has been answered: what information is the enterprise authorized to rely upon? If two operating infrastructure contain different legitimate values, an agent can be perfectly authorized to execute while still acting on the wrong definition.
SeniorCRE governs the path from evidence to the Governing Record before SeniorCRE Intelligence and controlled execution apply.
Illustrative — not operator data
An AI agent authorized to update the capital forecast
System A
Operational occupancy — 91.7%
System B
Revenue occupancy — 89.9%
Both values are valid.
- Execution question
- May the agent update the forecast? Action policy answers this.
- Upstream question
- Which occupancy definition governs capital planning? Truth policy answers this.
- Decision contextCapital planning
- Applicable definitionRevenue occupancy
- Applicable authorityFinancial operating record
- Governed value89.9%
Only then: AI recommendation → decision → authorization → execution
Permission to execute does not establish authority over truth.
An agent can be authorized to act. The operator still determines what governs.
Definitions, source authority, reconciliation state, lineage, and human adjudication are built; external operator deployments have not yet begun. Enforcement of truth policy and action policy through a single agent gateway — including any MCP-exposed path — is architecture and design intent on the build roadmap, not a live capability.
A golden record is not the same as governed operating truth
Master data management is excellent architecture when several records represent the same underlying fact and the enterprise needs one canonical representation of it. Senior housing & care decisions also depend on facts whose meanings legitimately differ by domain — and those should not be merged.
Ground truth is not something a platform gets to declare. The operator declares the definition, assigns source authority, governs reconciliation, and preserves the decision with lineage.
Unifying, matching, merging, deduplicating, or remembering data improves context. It does not establish authority when legitimate systems disagree.
Master this
- EHR: Margaret Chen
- CRM: Maggie Chen
- Billing: M. Chen
One person.
These records should normally be matched, mastered, and reconciled. One canonical representation is the right answer, and master data management is the right tool.
Do not merge this
- Clinical / operational occupancy: 91.7%
- Revenue occupancy: 89.9%
Both may be correct.
Neither is bad data. Neither should globally overwrite the other. The question is which definition the operator has authorized to govern the decision in front of them. Illustrative example; figures are not operator results.
When systems disagree
WHEN SYSTEMS DISAGREE
|
IS ONE VALUE WRONG?
/ \
YES NO
| |
DATA QUALITY / MDM BOTH MAY BE VALID
| |
CORRECT / MASTER DEFINITION + AUTHORITY
RECORD |
DECISION CONTEXT
|
GOVERNED TRUTHNot every conflict should be merged
Decision
Staffing
Applicable definition
Clinical / operational occupancy
Governed value
91.7%
Decision
Capital planning
Applicable definition
Revenue occupancy
Governed value
89.9%
No globally surviving value is required. Authority changes with the decision context, and both readings stay preserved with the definition that was in force.
A golden record answers
“What is the mastered value?”
An Operator-Controlled Operating Record answers
“Which valid definition governs this decision?”
| Dimension | Master data / golden record | Operator-Controlled Operating Record |
|---|---|---|
| Problem being solved | Multiple representations of the same entity or fact | Multiple legitimate definitions or authorities affecting a consequential decision |
| Typical action | Match, merge, deduplicate, standardize | Define, authorize, reconcile, adjudicate |
| Conflict handling | Determine which field value survives | Determine which valid meaning governs this decision |
| Authority | Field- or source-based survivorship and mastering rules | Definition + decision context + domain + source + effective period + operator policy |
| Result | Golden / master record | Governed truth for a defined operating purpose |
| Preservation | Source lineage and merge history | Competing valid facts, plus authority and decision lineage |
| AI role | Ground AI in clean, linked, mastered data | Ground AI in operator-authorized meaning for the decision being made |
| Execution | Provide clean context to downstream systems | Govern truth before recommendation, authorization, and permitted execution |
How to read this table. It contrasts two architectures, not two vendors. No column asserts that any named product lacks a capability. Master data management and operator-controlled operating governance answer different questions and can coexist in the same estate. SeniorCRE capability descriptions reflect built, built, or roadmap — not built; no operator-production deployment has completed.
Four forms of lineage
Data lineage tells you where a number came from. Authority lineage tells you why that number governed. Both matter; they are not the same record.
Source lineage
Where did the fact originate?
Transformation lineage
What happened to it technically — mapping, standardization, merge?
Authority lineage
Why did this definition and this source govern?
Decision lineage
Which decision relied on it, who authorized it, and what followed?
Clean data is necessary. Governed meaning is different.
As AI agents become capable of acting directly across enterprise systems, the critical control point moves upstream. Before an agent acts, the enterprise must know not only where a fact came from, but whether that definition is authorized to govern the decision being made.
- Source data
- Mastering
- Clean / linked data
- Definition
- Authority
- Governed truth
- AI reasoning
- Decision
- Authorization
- Execution
Govern the truth before you automate the decision. When systems disagree, the operator governs.
Domain authority belongs where it belongs. Decision authority belongs to the operator. Source precedence is not the same as decision authority.
Before a briefing
Three ways to test the argument without talking to us
An executive briefing is the right next step once the argument holds. It should not be the first step. These three surfaces are self-serve, and none of them gate the substance behind a form.
- No email required to see your resultRun the Authority Chain DiagnosticTwenty-four self-reported statements across the six links of the authority chain. Your result is shown on screen immediately. Contact details are optional and only requested after the result.
- On the site, no formRead the Operator Control BriefThe governance argument in written form: where operating authority breaks, and what an Operator-Controlled Operating Record changes about it.
- Nothing to submitRead the argument firstFive pages, in order: why now, the Operator Authority Chain, the operating record, what it means for operators, and how to start a conversation.
Proof pass
Build status of the operating record
What is built, and what is exercised only. Availability varies by source system and contract; nothing here asserts an enabled vendor or payor integration.
- How Quality Occupancy is measured
One governed representation of resident and unit as the census record, with lineage to the originating systems.
BUILT - Platform overview
Care, labor, revenue and compliance resolve against the same governed record.
BUILT Audit evidence is retrievable as one query against one immutable log.
BUILTExercised against representative data; retention and evidence scope are set per contract. Stated as of September 29, 2026.
Source-system reads keep the operator’s existing systems in place.
BUILTNo vendor or payor integration is asserted as enabled in an operator production environment. Stated as of September 29, 2026.
- AI oversight and governance
AI answers are grounded in the governed record and cite their source.
BUILT - Open Data Governance Center
The operator can export the full record without vendor permission.
BUILT
- BUILT
- Implemented in the platform. Not validated, and not running in an operator production environment as of September 29, 2026.
Status language follows the BUILT / BUILT standard. No claim on this page is asserted as running in a named operator’s production environment as of September 29, 2026. Third-party marks are referenced nominatively and remain the property of their owners.
What changes in 90 days
So what happens Monday?
The argument only matters if it survives contact with an operating week. Ninety days is the honest unit of evaluation: no rip-and-replace, no data migration, no change to the systems your teams already log into.
- 1
Days 1–30
Name the record
Systems inventory, survivorship rules, and the reconciliation set agreed in writing. Nothing is migrated and nothing is replaced — the operator declares which source governs each field.
- 2
Days 31–60
Reconcile in the open
Census, labor, and clinical extracts are reconciled side by side against the operator’s own systems. Every disagreement is shown with its lineage rather than silently resolved.
- 3
Days 61–90
Govern the disagreements
The operator accepts or rejects each reconciled row, and the accepted set becomes the governed evidence used for the board packet, the covenant evidence, and the labor plan.
Sequence and phase content describe the evaluation plan offered to founding-cohort operators as of August 2026. Status of the underlying surfaces follows the BUILT / BUILT nomenclature stated on each capability page; no connector is running in operator production today.
DIAGNOSTIC · FREE · 4 MIN
How fragmented is your stack? Get your Fragmentation Index.
Ten questions. Five dimensions. One number that tells you whether you are leading from one operating record — or being managed by your stack.
IDENTITY · BEFORE & AFTER
The Fragmented Operatorvs.The Governed Operator
The same portfolio. The same residents. The same board. What changes is whether you are managing a stack or leading from one operating record.
The Fragmented Operator
- I don't really know what's happening until it's too late
- My board asked me a question I couldn't answer
- I feel like I'm managing a stack, not a business
The Governed Operator
- I can finally see what is happening
- I am leading a modern, institutional-grade operator
- I can identify risk before it becomes expensive
10-question diagnostic. Browser-only. No email required.
Doctrine
Organizations have long accepted the general ledger as non-negotiable. Decision governance is next. That is the operating record.
Definition. Authority. Reconciliation. Lineage. The four that make data governable.
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