Kairos × Simonas — data access

Today 13:30 · Lee + Šaras · MN data
Walk out with a named, governed, read-only path into MN's operational data — systems, owner, method, and one concrete delivery agreed for this week. A promise of data "through Claude" is not an integration until sources, permissions, freshness and auditability are named. A demo is not access.

Close first — who he actually is

Three unknowns, two minutes: Is he the data owner, the engineer, or the access administrator — or all three? Who authorizes external read access — him, Ieva's operating ring, or the fund side? Which systems does he personally control?

The asks — in order

  1. System inventory. Which systems hold: payments/billing (VPN subs), GoProxies revenue, node/network telemetry, product analytics, finance/accounting, CRM/support, internal docs. Ask for the written list with owners after the call — not table names live.
  2. Metric dictionary. How MN defines revenue, MRR, churn, active user. Anchor to show we're informed: "The 08-07 All Hands showed July around $288k — which perimeter is that: VPN only, plus GoProxies, gross or net?"
  3. Access method. Read-only how — API, DB replica, scheduled exports? And concretely: "When you say through Claude — what did you build? An MCP server, a claude.ai project, something else?" This one answer shapes everything downstream.
  4. Coverage & cadence. How far back does history go; how fresh is it (hourly / daily / monthly close)?
  5. Scope & PII. What's excluded. Signal we want user PII and secrets excluded — Kairos needs economics (aggregates), not people. It turns his decision from scary to easy.
  6. Auditability. Can any number be traced to source rows and a time window on request?
  7. All Hands archive. Historical decks, speaker notes, recordings — standing Kairos ask; Simonas may be the fastest path. Reference: our gated analysis of the 08-07 deck is already live.

The proposal — reconciliation test this week

A dashboard can say anything — before Kairos builds board-level recommendations on his surface, we prove once that its numbers trace to reality. Three probes, one per pipeline: revenue — "show me the payment transactions that sum to July's ≈$288k"; customers — "what rule defines 'active subscriber', and do a handful of real records match it?"; cost/headcount — one figure traced to accounting entries or the HR list. Three different systems; three clean traces → the whole pipeline is trustworthy. A mismatch is normal (gross vs net, refunds, timezone of "July") — finding it quietly in week one beats discovering it in front of the board in month two.

The framing: "Anything we show leadership will get challenged — help us make your numbers bulletproof, so we defend them together." His pipeline gets certified; he becomes the guy whose data survived scrutiny. Validation, not audit.

Give value — make him the winner

The endgame (Robertas's own vision): a company hub where every teammate's AI agent self-serves his data. His ad-hoc query queue disappears; his data finally drives decisions daily.

Ask his pain: "What requests eat most of your time?" · "What do you wish leadership asked about the data?"

Offer: as we work, we structure the metric dictionary and docs and hand them back — he gets documentation for free.

Traps — don't step in

  • A chat interface is not an evidence layer — keep the source-trace requirement.
  • A title is not authority — ask who signs off on access.
  • Promise ≠ integration; don't report access until creds work.
  • If asked "where do you want it": read-only credentials, or exports into governed storage — never email attachments (uncontrolled copies, no revocation), never into git (git never forgets; datasets bloat it permanently).

Context if infra comes up: the Kairos/MN git hub is being set up on Robertas's Forgejo server today — conclusions and dictionaries live in git; operational data lives in governed storage, reached read-only.