The Architecture Behind NaviStrat

Every NaviStrat experience is a conversation between five layers. A person (on any device) talks to the App Shell, which hands the message to the AI Engine. The engine picks a brain (LLM Provider), reads and writes memories (Data Layer), and reaches out to the outside world through Integrations and Workflows.

When you press send, the message doesn't go straight to an AI. It first passes through a context tier selector that decides how much "brain" the question deserves. A quick "thanks!" needs almost no context; a request to "draft a board paper from last quarter's cash data" needs the full memory vault and your saved documents.

The engine then assembles a single package: the system prompt (Sirius's personality and rules), the most relevant memories, and any vault documents that might matter. That package is handed to wingmanChat, which calls the chosen provider directly and streams the reply back.

Not every message deserves the same brain. A two-word reply shouldn't cost the same as a 2,000-word analysis. The tier selector reads each message and routes it to one of three tiers — each with a different model, a different amount of conversation history, and a different price.

In a long conversation, the system prompt and early messages are identical on every turn. Without caching, you pay full price for them every single time. With prompt caching, the provider stores that stable prefix once and reuses it — charging about 10% of normal for the cached portion.

For a product like Wingman, where a single chat can run 40+ turns, this is the difference between a sustainable business and a money pit. The wingmanChat function places two cache breakpoints: one on the system prompt, one at the end of the stable history — so each new turn reuses everything before it.

Three providers, each with its own account and billing. You might be testing on Google's free tier, have a few dollars of OpenAI credit, and not yet have an Anthropic API key. The system handles all of that gracefully.

Toggle: an admin sets WINGMAN_PROVIDER_CONFIG (a JSON secret) to enable/disable any provider. A provider is "available" only if enabled and its API key is set. During testing you'd leave only Google on; flip OpenAI on once funded; flip Anthropic on later.

Failover: if the chosen provider returns a quota, billing, or overload error (429, 402, 403, 5xx), the call silently retries on the next available provider — so a free tier exhausting mid-session self-heals onto the next live provider instead of breaking.

Everything NaviStrat knows about you lives in entities — structured database tables with built-in security. But NaviStrat isn't a generic chat app; it handles treasury-grade sensitive data: bank account numbers, trading positions, payment templates, cash forecasts, FX exposures, and client files. The data layer is designed around that reality.

What NaviStrat stores

The platform holds a wide range of entity types, each serving a specific module. Conversations and memories power Sirius. Vault documents hold reports, plans, and drafts. Bank accounts and statements (masked, never raw credentials) feed the TMS cash management module. Trading positions and investment plans drive PRISM. Payment templates and their audit logs govern the payments module. Client files and engagement updates support the consulting practice. Open items and decisions track your commitments across all modules.

Row-level security: the foundation

Every entity carries an rls block that defines who can create, read, update, and delete its records. For user-scoped data (conversations, memories, vault docs, open items, decisions), the rule is simple: read: { created_by_id: {{user.id}} } — you only ever see your own records, even though everyone's data sits in the same table. For admin-only data (GTM leads, blog management, platform activity logs, change logs), the rule is user_condition: { role: 'admin' } — only admins can access them. Some entities use compound rules: a document you own or one shared with you or an admin viewing everything.

Sensitive data categories

NaviStrat handles several categories of sensitive data, each with its own protections. Bank data — account numbers are masked, balances and transactions are stored as entities but access is controlled by BankDataAccessRule records that specify which users can see which accounts. Trading data — positions and P&L are RLS-locked to the owner. Payment data — every payment template and execution is logged in PaymentAuditLog with who/what/when. Client files — engagement notes and client data are admin-only. Contract profiles — recruiter and job application data is scoped to the owner.

Audit trails: who did what, when

For a treasury platform, auditability is non-negotiable. Three audit entities track everything: PaymentAuditLog records every payment action (created, modified, authorized, executed). PlatformActivityLog tracks user actions across all modules — which tool, what action, what entity, what result. TMSEnvSnapshot captures environment states over time so you can see what changed and when. Every entry is admin-readable and immutable.

Passcode-locked conversations

Sirius conversations can be passcode-protected for sensitive topics — M&A discussions, personal financial matters, anything you don't want visible if someone glances at your screen. The passcode is SHA-256 hashed before storage; the plaintext is never saved. A locked conversation shows a gate screen until the correct passcode is entered, and the hash is verified client-side so the server never sees the plaintext either.

Sentinel: the security & compliance module

Sentinel is NaviStrat's dedicated security layer. It maintains an access control matrix (who can do what in each module), enforces segregation of duties (the person who authorizes a payment can't be the one who executes it), tracks a risk register and fraud alerts, and maps compliance against frameworks (SOX, ISO 27001, etc.). It's the module that turns "we handle sensitive treasury data" into "we can prove we handle it right."

Multi-tenant workspace isolation

For the TMS, NaviStrat supports multi-tenant isolation through TMSWorkspace and TMSWorkspaceMember entities. Each workspace is its own isolated environment — its own bank accounts, GL accounts, counterparties, and configurations. Members are scoped to their workspace, so a user in Workspace A cannot see Workspace B's data even if they have an account on the platform.

Cross-device continuity

Conversations sync across devices in real time. Send a message on your laptop and it appears on your phone within a second — no refresh needed. The platform uses realtime subscriptions so each device is notified the moment a record changes, backed by a 60-second interval and window-focus handler for anything missed.

The platform connects to your Google workspace through OAuth connectors — Gmail, Calendar, Drive, and Sheets. Once authorized, it can read your email, manage your calendar, save files to Drive, and sync rows to Sheets — all on your behalf.

Workflows are the automation layer: "when X happens, do Y." A new blog submission triggers a reviewer notification. A published article auto-saves to Drive. A TMS issue syncs to Sheets. They run even when no one is watching.

Under the hood, all these modules share the same five layers from the map above. PRISM's AI advisor and Sirius use the same wingmanChat engine. The TMS and Sentinel share the same data layer and RLS. This is why a memory you save in Sirius can inform a PRISM investment plan — they're one brain, not eight disconnected apps.

There are three ways to pay for AI. Base44 credits are the simplest — one flat per-call price, no API keys, no billing setup. Perfect for early stage. Direct API is wholesale — you pay the provider's raw rate and unlock prompt caching, which drops long-conversation costs by ~90%. BYOK (Bring Your Own Key) is for Enterprise — the customer supplies their own provider key, so their usage never touches our margin.

The same engine handles a one-word question and a multi-step financial analysis. The difference is which tier fires, how much context is loaded, and how many calls chain together.