Managed Business Acceleration Infrastructure

Approved architecture blueprint#

Status: Approved foundation
Date: 2026-07-10
Initial proving tenant: Roam Free
First external design partner: Lake Tahoe Accommodations (LTA)
First implementation slice: Property Knowledge Reliability

This document converts the approved founder decisions into a build contract. It should be used with the evidence-backed current-workflow and data-shape audit, which identifies existing code to reuse, generalize, wrap, or retire.

Executive architecture decision#

Build a client-owned operating data and governance layer between source systems and changing applications, AI models, agents, dashboards, and service workflows.

The platform is not another property-management SaaS suite. It is managed acceleration infrastructure that:

Preserves what every source actually provided.
Resolves that evidence into explicit, time-bounded client decisions.
Makes conflicts, uncertainty, lineage, freshness, and sensitivity visible.
Produces governed outputs that can move between vendors.
Lets clients view, export, transform, and eventually build on their data.
Supports private and local execution when protected data must not reach an external model.
Reuses proven LTA and Roam Free mechanics instead of rewriting them.

The central rule is:

Preserve the proven mechanics; replace the tenant-specific data contract.

Goals#

Give each client a durable, vendor-neutral operating graph.
Preserve lossless source evidence and complete lineage.
Make canonical truth an explicit decision, not an overwritable row.
Support unknown data types and future verticals without redesigning the core.
Govern human and AI-generated outputs through reusable controls.
Keep premium client data planes isolated while sharing reusable code and management tooling.
Make vendor migration controlled and reconstructable rather than a ground-up rebuild.
Prove every capability on Roam Free before LTA or broader release.

Non-goals for the first implementation#

Replacing OwnerRez, Streamline, Breezeway, Conduit, PriceLabs, RevA, or other operating applications.
Building a public connector marketplace or broad SDK before demand is proven.
Modeling every future business domain before the property-knowledge slice works.
Enabling automatic two-way synchronization.
Allowing AI to promote guessed operational facts into runtime knowledge.
Treating Notion, Sheets, a PMS, or generated prose as the permanent source of truth.
Enabling production writeback from the new system during the read-only MVP.

System context#

flowchart LR
    subgraph Sources["Client-selected sources and workspaces"]
        PMS["PMS / operational SaaS"]
        OPS["Breezeway / field operations"]
        DOCS["Drive / Docs / Sheets / Notion"]
        AI["Conduit and other AI systems"]
        FILES["Files / images / PDFs / email / messages"]
        FUTURE["Unknown future sources"]
    end

    subgraph Plane["Separate client data plane"]
        CAPTURE["Immutable capture and evidence vault"]
        CANDIDATES["Fact candidates and identity resolution"]
        DECISIONS["Canonical decisions and relationships"]
        POLICY["Authority, access, safety, freshness and retention policy"]
        ARTIFACTS["Versioned artifacts, approvals and receipts"]
    end

    subgraph Consumers["Client and partner consumers"]
        AUDIT["Read-only audit and operating intelligence"]
        EXPORT["Exports / APIs / webhooks / agent tools"]
        CONTENT["Listings / captions / knowledge packs / websites"]
        LATER["CRM / social / compliance / bookkeeping"]
    end

    Sources --> CAPTURE
    CAPTURE --> CANDIDATES
    CANDIDATES --> DECISIONS
    POLICY --> CANDIDATES
    POLICY --> DECISIONS
    DECISIONS --> ARTIFACTS
    POLICY --> ARTIFACTS
    DECISIONS --> AUDIT
    DECISIONS --> EXPORT
    ARTIFACTS --> CONTENT
    DECISIONS --> LATER

The stable kernel#

The core remains deliberately small. New verticals extend definitions and policies rather than adding customer-specific forks.

Core resources#

Tenant: the client legal and operating boundary.
Data plane: the client's database, storage, secrets, queues, workers, backups, and optional local-model runtime.
Resource: a permanent client-owned object such as property, space, owner, guest, reservation, conversation, task, vendor, account, document, or media asset.
Relationship: a typed, time-bounded connection between resources.
External identity: a vendor or source identifier mapped to a permanent resource.
Source connection: a scoped connector identity, capability set, and sync policy.
Raw object version/event: an immutable source-native capture.
Fact definition: the versioned contract for a field.
Fact candidate: one source's claim about a resource.
Canonical decision: the accepted value, evidence, policy, validity, and approval.
Conflict: competing claims and their downstream impact.
Artifact/version: a generated or assembled business output.
Approval: authorization for an exact version and use.
Publication receipt: proof of a planned, executed, and verified delivery.
Policy: access, authority, data classification, execution, retention, freshness, approval, and writeback rules.

Extensible definitions#

Clients and verticals may register new:

Resource and relationship types.
Fields, units, enumerations, and validation rules.
Sensitivity, audience, allowed-use, and retention classifications.
Freshness requirements.
Source-authority rules.
Client-specific namespaced fields.
Artifact recipes and risk policies.

Definitions are versioned. Unknown source fields remain preserved in raw captures even before they are promoted into the canonical model.

The governed data lifecycle#

flowchart LR
    R["Immutable raw versions"] --> C["Preserved fact candidates"]
    C --> X{"Conflict / authority evaluation"}
    X --> D["Explicit canonical decision"]
    X --> U["Unknown or unresolved"]
    D --> A["Derived artifact or intelligence"]
    A --> P["Policy-based approval"]
    P --> W["Publication / delivery"]
    W --> V["Readback verification and receipt"]

Non-negotiable rules#

No last-write-wins canonical truth.
No generated projection implicitly becomes canonical.
Corrections supersede prior decisions; they never erase them.
Every canonical value must trace to source evidence and an explicit decision.
Unknowns remain unknown.
AI inferences remain labeled inferences unless an authorized policy or person promotes them.
High-risk uncertainty fails closed.

Universal source capture contract#

Every connector emits two products.

Immutable raw history#

Each capture records:

Tenant and source connection.
External object type and identifier.
Observed time and source-effective time when available.
Source version, ETag, revision, cursor, or event identifier.
Content hash.
Native payload, file, or durable object reference.
Schema, media type, or MIME type.
Original metadata and permissions.
Sensitivity and retention classification.
Connector and parser versions.
Sync run, error, and retry context.

Rebuildable current mirror#

A current-source mirror makes operational queries convenient. It is always rebuildable from immutable history and is never canonical truth.

Adding a connector must not require widening a core vendor enumeration or inventing a new core data lifecycle.

Client evidence vault#

Permitted documents, images, and media are stored in a client-owned content-addressed vault.

Actual source content is preserved where permissions and policy allow; external links alone are insufficient.
Cryptographic hashes provide stable object identity and deduplication.
Different source locations retain separate lineage even when bytes are identical.
Each later version remains separately reconstructable.
Extracted text, thumbnails, embeddings, summaries, and classifications are derived and rebuildable.
Retention and deletion policies apply to both originals and derivatives.

Identity model#

Every resource receives a permanent client-owned identifier.
Vendor IDs and human codes live only in external-identity mappings.
Trusted exact mappings may connect automatically.
Probabilistic matches become review candidates with evidence and confidence.
Ambiguous records are never silently merged.
Merges are auditable and reversible.
Historical vendor identities remain linked after migrations.

Source authority and canonical decisions#

Authority belongs to the client's business process, not to a vendor category.

Notion, Google Sheets, a PMS, Breezeway, an owner attestation, a document, or a future tool may be authoritative for a particular field and context.

Each authority rule can specify:

Tenant, resource type, field, audience, and purpose.
Primary source and fallback order.
Effective dates.
Required evidence and freshness.
Conflict and escalation behavior.
Human override authority and expiration.

A single global source precedence is insufficient. Streamline may own reservation status while an owner-approved guidebook owns parking instructions. Conduit may own message events but not the property facts mentioned in a response.

Time model#

All governed facts and relationships are bitemporal:

Effective time: when the fact was true in the client's business.
Recorded time: when the platform learned, changed, or corrected it.

This allows the platform to reconstruct what was believed at any point, what later evidence says was actually effective, and which outputs relied on a mistaken belief.

Facts, derived values, AI inferences, and unknowns#

These states are separate:

Canonical fact: supported by authoritative evidence or an explicit authorized decision.
Derived value: calculated deterministically from canonical facts.
AI inference: a labeled prediction with model, evidence, confidence, and expiration.
Unknown: missing or unresolved information.

AI may extract, classify, propose, compare, and recommend. It may not silently turn a guess into operational truth.

Certification and release bundles#

Facts move through:

captured -> conflicted/proposed -> verified -> approved -> certified for a defined use

Certification is claim-level and purpose-specific. Release bundles group the exact certified claims needed for outputs such as:

Listing copy.
Photo captions.
Guest-messaging knowledge.
Safety and access instructions.
Owner reporting.

An output may publish only when every claim it relies on is certified for that audience and purpose.

Universal artifact lifecycle#

All business outputs share a common envelope:

artifact -> version -> evidence -> review -> approval -> publication -> verification receipt

The policy varies by risk. A dashboard calculation may publish automatically; a social post may need one approval; a guest access instruction may require current verified evidence; a compliance output may require multiple approvers.

Each version records:

Canonical snapshot and fact decisions used.
Recipe, prompt, transform, code, and model versions.
Human or software author.
Data-classification and execution policy.
Review findings and exact approval hash.
Destination, before/after state, readback, and rollback reference.

Corrections#

Every correction uses the same workflow regardless of whether it begins in the dashboard, Notion, Sheets, support, or an AI review:

Preserve the current value and create a proposal.
Record proposed value, evidence, effective date, requester, and reason.
Calculate conflicts and affected outputs.
Route approval by field authority and risk.
Create a superseding canonical decision.
Invalidate affected certifications.
Queue review or regeneration of downstream artifacts.

Data classification and AI execution#

Every field and artifact carries a classification:

Public
Internal
Sensitive
Restricted

Classification and client policy determine permissible tools, models, destinations, and retention.

Restricted data remains inside the client-controlled data plane.
Sensitive data defaults to private/local execution.
External models receive only explicitly allowed, minimized data.
Secrets are retrieved for an authorized person, reservation, and purpose; they are not embedded in reusable prompts or knowledge bases.
Every agent has scoped tools, budgets, approval boundaries, audit records, and a kill switch.

Access control#

Use role-based and attribute-based controls together.

Roles include owner, executive, manager, operator, accountant, marketer, contractor, auditor, and administrator.
Attributes include property, department, purpose, sensitivity, reservation relationship, and time window.
Users, integrations, and AI agents have separate identities.
Privileged access is temporary and expiring.
The client controls routine access administration.
Our support access is explicit, temporary, and fully audited.
Sensitive reads, exports, permission changes, and writes are attributable.

Retention and deletion#

Immutability does not mean unlimited storage.

Retention is policy-driven by data class and client requirement.
Sensitive data is minimized and expires appropriately.
Holds can suspend deletion.
Deletion propagates to indexes, embeddings, caches, derivatives, and backups according to policy.
Deletion leaves a non-sensitive audit tombstone rather than the deleted content.
Per-object or per-domain encryption keys support cryptographic erasure.
Clients receive complete export and defensible exit-deletion rights.

Freshness and synchronization#

There is no universal real-time promise.

Use webhooks or streams when trustworthy.
Poll at source-appropriate intervals otherwise.
Allow manual refresh for files and systems without dependable APIs.
Define freshness requirements by field, source, and use.
Display source, observed time, effective time, and staleness.
Fail closed when a high-risk output depends on stale evidence.
Monitor sync health by connector, resource, and domain.

Controlled writebacks#

Read access never implies write permission. Every outbound change follows:

proposal -> destination diff -> policy check -> approval -> scoped/canary write -> readback -> receipt/rollback

Synchronization direction is explicit per field and destination.
Generic two-way synchronization is prohibited.
The system recognizes its own projections to prevent feedback loops.
Unexpected vendor drift pauses a write.
Bulk writes begin with a canary.
Each connector has a kill switch.

Tenancy and deployment#

Premium clients use:

One reusable codebase and shared management tooling.
A separate data plane per client: database, storage, secrets, encryption boundary, queues/workers, and backups.
Deployment flexibility for our cloud, the client's cloud, or client-controlled/local hardware.

A future highly automated, low-cost product may use a multi-tenant data plane. It must not weaken the premium isolation contract.

Extensibility#

Design the interfaces we use internally as future product contracts from day one:

Stable resource IDs and versioned schemas.
Read APIs and complete exports.
Event and webhook contracts.
Scoped service accounts.
Policy-enforced AI agent tools.
Standard connector interfaces.

Do not launch a public SDK, marketplace, or broad self-service platform until Roam Free and LTA validate the contracts and at least two real external integrations require them.

Reuse and migration policy#

Use a strangler migration:

wrap -> shadow -> compare -> repoint -> retire

Preserve#

Generic fact reconciliation and publish gates.
Deterministic listing and caption dossiers.
Claim tracing and adversarial review.
Human approval separation.
Write guards, canary writes, readback verification, and receipts.
Content hashing and immutable-capture conventions.

Generalize#

LTA run state machines.
Property and caption dossiers.
Onboarding field registry.
CanonicalRecord compatibility views.
Notion/knowledge exports.
Media-object identity.

Keep as adapters#

OwnerRez, Streamline, Breezeway, Conduit, Notion, Google Drive, Reva, PriceLabs, Slack, and future source/destination code.

Retire after parity#

Guessed AI-DRAFTED runtime facts.
Duplicate or conflicting generation prompts.
Local-path-only evidence.
Vendor IDs as permanent identity.
Direct unredacted-secret delivery to external AI knowledge stores.
Globally unique property codes without tenant scope.

LTA forensic-preservation mode#

LTA migration is a forensic reconstruction before it is a data migration.

An original snapshot proves what existed at capture time; it does not automatically prove correctness. Current production may also contain mistakes introduced during prior updates.

The system must separately reconstruct:

Original captured state.
Each later observed or authored change.
Current live state.
Proposed corrected state.
Approved canonical decision.

Requirements:

Immutable hashes for all source captures.
Exact string-level and structured-field diffs.
Effective and recorded time.
Actor, reason, evidence, transform version, and approval.
Backups, readback verification, and rollback references for every write.
Historical mistakes remain visible as superseded mistakes.
No new-system LTA writeback until the relevant property and purpose-specific release bundle is certified.

First implementation slice: Property Knowledge Reliability#

Initial resource scope#

Property and spaces.
Amenities and equipment.
Policies, instructions, access, and safety information.
Media assets and placements.
Documents and source evidence.
External identities.
Content artifacts, approvals, and receipts.

The kernel supports reservations, owners, guests, conversations, tasks, CRM, financial records, compliance, and websites later, but those domains do not block this slice.

Initial source scope#

The final order comes from the Source Discovery Manifest, not from a remembered list. Known candidates include:

OwnerRez.
Breezeway.
Google Drive, Docs, and Sheets.
Supabase and Notion.
Conduit.
Airbnb, Vrbo, and direct websites.
Onboarding forms, owner documents, guidebooks, manuals, PDFs, images, email, Slack, local files, and later-discovered sources.

First consumer#

The first release is a read-only Property Knowledge Audit showing:

Source inventory, coverage, and freshness.
Permanent property identity and external mappings.
Candidate facts, canonical decisions, conflicts, unknowns, and AI inferences.
Evidence and claim-level certification.
Differences between source, canonical, and currently published values.
Current listing, caption, and Conduit projections.
Complete machine-readable export.

Roam Free MVP acceptance gates#

The read-only MVP passes only when:

Every known source is inventoried and unconnected sources remain visibly flagged.
Every active property has a permanent ID and verified external mappings.
Selected source captures are immutable, hashed, and replayable.
At least 95% of the target fact catalog is populated or explicitly unknown/conflicted.
Every displayed or exported canonical value traces to evidence and a decision.
Every target field has authority, sensitivity, audience, freshness, and retention rules.
Restricted-data external-model egress tests fail closed.
Published listing, caption, and Conduit content can be compared without treating prose as truth.
No unresolved critical safety, access, policy, or identity conflicts remain.
A complete export and independent restore test succeed.
Setup, review, correction, and maintenance time is measured.
Production writeback remains disabled.

Roam Free proves technical function and governance. It does not prove external willingness to pay.

Implementation sequence#

Phase 0: discovery and contract freeze#

Complete the Roam Free Source Discovery Manifest.
Classify current tables, files, and integrations as source, mirror, candidate, canonical decision, projection, artifact, or scratch.
Freeze existing LTA/Roam Free fact, dossier, approval, and write-gate behavior as acceptance fixtures.
Capture current schemas and golden outputs.

Phase 1: isolated Roam Free foundation#

Create the client data plane skeleton.
Implement stable kernel resources, external identities, definitions, policies, raw capture, candidates, decisions, conflicts, artifacts, and audit ledger.
Add classification, retention, access-control, and model-routing enforcement.
Implement export, backup, restore, and emergency rebuild paths before writeback.

Phase 2: wrap existing connectors#

Put thin standard interfaces around existing OwnerRez, Breezeway, Drive, Notion, Conduit, and published-channel code.
Capture immutable raw versions and rebuildable mirrors.
Preserve existing behavior; do not repoint production consumers.

Phase 3: shadow and reconcile#

Seed permanent IDs from trusted current identifiers.
Extract fact candidates through reusable parsers.
Apply source-authority rules and compare results with current CanonicalRecord/atomic facts.
Explain every mismatch before acceptance.

Phase 4: read-only Property Knowledge Audit#

Build the source, fact, conflict, certification, projection-diff, freshness, and export views.
Run the Roam Free acceptance gates.
Measure labor and record missing capabilities without broadening scope.

Phase 5: governed outputs on Roam Free#

Repoint listing and caption dossiers in shadow mode.
Add Conduit knowledge projection in shadow mode.
Store all outputs in the universal artifact ledger.
Activate one destination at a time only after hash, claim, redaction, approval, and receipt parity.

Phase 6: LTA forensic read-only deployment#

Deploy an isolated LTA data plane.
Import immutable snapshots and existing ledgers without rewriting them.
Reconstruct original, updated, current, and proposed-corrected states.
Certify claims and release bundles property by property.
Keep all new-system outbound writes disabled.

Phase 7: controlled LTA writebacks#

Enable only a certified, purpose-scoped destination.
Require backup, approval manifest, canary, drift check, readback, and rollback receipt.
Expand destinations only after successful reconciliation.

Later gates#

Add reservations, owners, guests, conversations, tasks, financial, compliance, website, and CRM domains only when a paid workflow reuses the stable kernel.
Formalize public APIs/SDK only after real external integration demand.
Evaluate commercial private-compute deployments only after paid demand and delivery economics justify them.

Reliability and recovery#

Independent encrypted backups per client data plane.
Point-in-time database recovery and versioned object recovery.
Backup credentials isolated from production.
Residency-aware backup placement.
Automated integrity checks and scheduled restore drills.
Durable connector checkpoints and idempotent replay.
Fail-closed writebacks during uncertain state.
Reconciliation report required before outbound synchronization resumes.
Complete client-owned emergency export.

Architecture invariants to test continuously#

No row crosses a tenant boundary.
No vendor ID is used as permanent internal identity.
No canonical decision exists without evidence and policy.
No projection can silently re-enter as truth.
No AI inference is mislabeled as canonical.
No restricted value reaches an unapproved model or tool.
No outbound write lacks authorization, readback, and a receipt.
No deletion leaves an uncontrolled derived copy.
No artifact claim lacks lineage to a certified decision.
No restore process depends on the failed production boundary.

Decisions intentionally deferred#

Final product and company name.
Exact cloud, database, queue, and local-model vendors.
Public API pricing and marketplace economics.
Future low-cost multi-tenant architecture details.
Exact commercial Private Compute appliance.
Domains beyond the first Property Knowledge Reliability slice.

These implementation choices must satisfy this blueprint rather than redefine it accidentally.