STR Operating Data Platform: Architecture Principles

Product thesis#

The company is not another property management system. It is the client-owned operating data, intelligence, and automation layer that sits across property management software and every adjacent administrative tool.

The product must combine two strengths:

1. A beautiful, simple client experience for viewing, approving, searching, and using information.
2. An open technical foundation that clients, partners, developers, and AI agents can extend without our permission or professional services.

Platform constitution#

1. Client data sovereignty#

The client owns its data. The platform must make all client data available for viewing, bulk export, incremental synchronization, and transformation in documented machine-readable formats.

Exports must include the information needed to preserve meaning, not only flattened values. This includes identifiers, relationships, provenance, version history, timestamps, approval state, and deletion markers where applicable.

2. Beautiful by default, headless when desired#

Every core capability needs a polished human interface. The same capability must also be available through a stable programmatic contract when practical.

The interface is a product advantage. The API is a client right.

3. Composable and AI-native#

Clients must be able to connect their own AI tools and build their own workflows. The extension surface should eventually include:

• Stable, versioned APIs.
• Outbound webhooks with delivery history and replay.
• An event stream with documented event schemas.
• Scoped service accounts and OAuth applications.
• Agent-readable schemas and action descriptions.
• Safe agent actions with dry runs, approvals, idempotency, and receipts.
• Connector and application development kits after the internal contracts stabilize.

AI agents are untrusted callers. They receive only explicit, revocable scopes and must never bypass the normal policy and audit layer.

4. Vendor independence#

Property management systems, CRMs, accounting platforms, guidebooks, messaging systems, and website platforms are replaceable systems of transaction or presentation.

The canonical operating-data layer is the durable system of record for reusable property and business knowledge. Vendor-specific identifiers and payloads belong in connector mappings, not in the canonical model.

Changing vendors should follow a repeatable migration workflow:

1. Connect the destination.
2. Map its schema to the canonical model.
3. Run a non-destructive preview.
4. Reconcile differences and unsupported fields.
5. Obtain approval for material changes.
6. Execute an idempotent cutover.
7. Verify counts, values, and relationships.
8. Produce a migration receipt and rollback package.

5. Wide base, narrow launch#

The data model must be extensible across guest communications, listings, websites, CRM, social media, compliance, and bookkeeping. Version one should implement only the shared primitives and the first complete outcome.

The first outcome remains:

Approved canonical property facts to a versioned AI guest-messaging knowledge export.

A wide base means durable identifiers, provenance, relationships, extensible schemas, permissions, audit events, and connector contracts. It does not mean building every vertical module now.

6. Safe agent enablement#

The platform should enable and encourage clients to build with our agents or their own agents. All agents use the same safety boundary and are treated as untrusted callers.

Agents never receive direct database access. Every read, proposal, and action passes through an agent safety gateway that provides:

• A distinct machine identity tied to one tenant.
• Explicit, revocable scopes for data and actions.
• Purpose and data-use restrictions.
• Data classification and model-routing policy.
• Read-only, proposal, approval-required, and execution modes.
• Sandboxed tools with validated inputs and outputs.
• Rate, cost, concurrency, and time limits.
• Idempotency keys and replay protection.
• Prompt-injection and data-exfiltration defenses.
• Human approval for sensitive or irreversible actions.
• Immediate revocation and kill switches.
• Complete, attributable action receipts.

The goal is not to prevent clients from building. The goal is to make safe building easier than unsafe building.

7. Private Compute mode#

Clients should be able to process protected data with local AI models on hardware or private infrastructure they control. In strict local-only mode, frontier AI labs never receive the protected data.

That guarantee is valid only when the complete sensitive workload remains inside the private boundary, including:

• Document parsing and optical character recognition.
• Embedding generation and vector search.
• Retrieval and prompt assembly.
• Model inference and agent tool execution.
• Intermediate files, caches, traces, and logs.
• Secrets and model credentials.

Strict mode must enforce outbound network restrictions, not merely rely on application configuration. The system should produce evidence showing where each workload ran, which model handled it, which policy applied, and whether network egress occurred.

Private Compute may run on a managed client appliance, an on-premises server, or a client-controlled private cloud. A random employee laptop should not become required production infrastructure.

The platform can also support policy-based hybrid routing. Public or low-risk tasks may use approved cloud models while sensitive tasks run locally. A workspace-level zero-frontier policy must be available for clients that require it.

Required architectural layers#

Client experience layer#

• Portfolio and property views.
• Search and structured browsing.
• Source evidence and conflict review.
• Approval queues and change history.
• Export center and integration status.
• Freshness, completeness, and delivery health.

Canonical operating-data layer#

• Tenant, portfolio, property, unit, and organization identities.
• Immutable source observations.
• Canonical facts and typed relationships.
• Provenance, confidence, freshness, and approval state.
• Schema and taxonomy versions.
• Append-only audit history.

Policy and action layer#

• Tenant isolation and role-based access.
• Fine-grained scopes for users, applications, connectors, and agents.
• Risk classification by field and action.
• Required approvals for sensitive writes.
• Idempotency, rate limits, dry runs, and action receipts.

Agent safety gateway#

• Agent registration, machine identity, and credential rotation.
• Tool registry with typed read, propose, and execute contracts.
• Data classification, purpose restrictions, and policy decisions.
• Model and execution routing by sensitivity and client policy.
• Sandboxing, budgets, rate limits, approvals, and kill switches.
• Input and output inspection for injection and exfiltration attempts.
• Attributable logs and tamper-evident receipts.

Private Compute plane#

• Local model runtime with replaceable model adapters.
• Local parsing, embeddings, retrieval, and vector storage.
• Encrypted local data and secrets.
• Outbound network-deny controls for strict local-only mode.
• Signed software and model update process.
• Health reporting that reveals no client payloads.
• Workload attestation and egress evidence.
• Queueing and recovery when a private node is offline.

Extension fabric#

• Public API gateway.
• Webhook subscriptions and replay.
• Versioned event schemas.
• Import and export jobs.
• Agent tool registry and action contracts.
• Developer portal, documentation, and test environment when market demand justifies them.

Connector layer#

• Source-specific authentication and rate-limit handling.
• Mapping between vendor schemas and canonical schemas.
• Cursor and checkpoint management.
• Read, preview, write, verify, and rollback capabilities where the vendor permits them.
• Connector health, drift detection, and reconciliation reports.

MVP boundaries#

Locked decision: Private Compute in the MVP#

Decision date: July 10, 2026.

Private Compute is a first-class platform mode from the beginning. The Roam Free MVP must prove one complete protected workflow using a local model without sending protected payloads to a frontier AI lab.

The MVP includes the contracts and policy boundaries required for this mode, plus one working internal path. It does not include a commercial appliance, broad hardware support, or customer fleet management.

The proof is complete only when:

1. The workload is classified for local-only execution.
2. Parsing, retrieval, inference, intermediate state, and logs remain inside the private boundary.
3. Outbound model access is technically blocked and a deliberate egress attempt fails closed.
4. The same agent gateway and approval rules govern the local workload.
5. The resulting receipt identifies the policy, runtime, model, and egress outcome without exposing the protected payload.

Build now:

• Canonical property facts and immutable source observations.
• Versioned STR taxonomy and extension fields.
• Evidence, conflicts, approvals, freshness, and audit receipts.
• Internal connector contract used by every ingestion and publishing path.
• Complete portfolio and property export.
• One client-facing information experience.
• One outbound knowledge export.
• Webhook and API foundations for the operations implemented in the MVP.
• A shared agent gateway contract used by first-party and future client-built agents.
• Data classifications and execution-routing policy fields.
• One internal local-model path proving that protected inference can run without sending payloads to a frontier lab.

Design now but defer:

• Public developer portal and application marketplace.
• Third-party connector SDK.
• Client-authored agent marketplace.
• Fully generic workflow builder.
• High-volume event streaming product.
• Automated cross-PMS migration execution.
• Customer-facing Private Compute appliances and fleet management.
• A broad catalog of locally supported models and hardware profiles.

The MVP should prove that these deferred capabilities can be added without changing the canonical model or bypassing the policy layer.

Non-negotiable acceptance tests#

• A client can export all canonical data and the metadata required to interpret it.
• Replacing one destination connector does not change canonical identifiers.
• Every external write has an initiating principal, policy decision, payload version, result, and receipt.
• Revoking an application or agent immediately prevents new access.
• Replayed webhooks and retried writes do not create duplicate effects.
• Vendor-specific fields can be preserved without contaminating shared schemas.
• A client can use the core product without connecting any third-party AI tool.
• An approved third-party AI tool can read or act only within its granted scopes.
• First-party and client-built agents are governed by the same policy layer.
• A strict local-only test fails closed when outbound network access is attempted.
• Private workload receipts identify the runtime and model without exposing the protected payload.
• Disabling a private node or agent credential prevents further actions and creates an alert.

Current architecture recommendation#

Treat the platform as the system of record for reusable operating knowledge. Keep the PMS as the system of transaction for reservations, availability, rates, and accounting events until there is a compelling reason to own those domains.

This boundary creates leverage without forcing the platform to become a PMS. It also supports the core promise: clients can change transaction systems without losing their governed data, integrations, automation logic, or AI foundation.