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 is a read-only Property Data Health scorecard for Austin East Bird. It proves permanent identity, authorized source observations, governed values, conflict visibility, provenance, recommendations, and complete ordinary exports without production mutation or model processing.

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: read-only shadow MVP#

Decision date: July 12, 2026. This supersedes the July 10 proposal to execute a local-model workflow inside the MVP.

Private Compute remains a first-class architectural mode, but no AI model receives real client or source-response content in the MVP. The first release is a read-only Roam Free shadow pilot for Austin East Bird.

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.
• A mobile-friendly standard Property Data Health scorecard.
• JSON, CSV, and evidence-manifest exports.
• Human-confirmed identity and location governance.
• Data classifications and execution-routing policy fields without model execution.
• Versioned contracts for future APIs, scorecards, agents, workflows, and Private Compute.

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.
• Any local or frontier-model processing of real source content.
• Production writeback, autonomous agents, and automated remediation.
• The full drag-and-drop scorecard builder.

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.
• Future first-party and client-built agents are represented by the same versioned capability, policy, budget, and action contracts.
• No model route is reachable in the MVP's real-data shadow workflow.
• The scorecard and exports remain reconstructable from approved evidence and versioned deterministic logic.

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.