The company, surveyed for your agents

Your agents understand how your company works.

The business, its processes, its people and its numbers, each grounded in the systems that run them. Connectors survey what you run. Your agent writes how the business works on top. Every answer points at the line behind it.

See how it works The private beta

Connectors lay down what you run. Your agent writes the business on top of it, and grounds each answer in a file and a line.

Sheet: 1 of 1 · Trig
Scale: one company
Surveyed: on every trig update
Legend: grounded in codesystem entity

SE 41 86What your agent can answer

Ask about the business, not the servers.

Below, one invented company: Acme, about 80 people selling ordering and invoicing software to 2,400 restaurants across Europe. Each answer comes back drawn the way Trig draws it, and says how each part is known.

How each part is known

declareda file says so
derivedTrig computed it
observedmeasured by a connector
contributedan agent or a person wrote it

01You ask
How does a venue go from signed to live?
Four states and one exit. The contract service moves a signed venue into menu import; the onboarding team moves it into training; a nightly job at 02:00 puts it live. 312 venues sit in menu import and nothing moves them out: Trig flags that pile by itself.
- declared:states from models/venue.ts:22
- observed:counts, 2 h ago
- contributed:phases and triggers, by an agent
- derived:the waiting pile
an automationa person or a customeron a datenot grounded yeta waiting pile
3 of 4 transitions grounded
The lifecycle as a state diagram: stations sized by how many venues sit there, the line style says who moves them.
02You ask
Where do our leads come from?
2,600 leads in 90 days, the largest share through search. The telling number is the grey one: 38% arrive with no source page, because referrals and partner leads come in by phone and email. Until that is tracked, per-site figures undercount.
- observed:weekly counts by channel and first page
- contributed:channels and sites, by an agent
- derived:attribution coverage
Leads by site, 90 days
- acme.example860
- get.acme.example632
- partners.acme.example120
- no source page988
38%
carry no source pageReferral and partner leads arrive by phone and email.
Channel, then site, then outcome, over 90 days. The accent band is the part nobody can attribute.
03You ask
Who owns billing?
Priya Shah owns billing-api and, through it, the invoices it alone writes. Jonas Berg most likely owns payment-webhooks. The dunning workflow is split between two people, so your agent asked once, with what it found and the answer it would give.
- declared:CODEOWNERS
- observed:commits, 90 days
- contributed:a runbook’s author
Billing
- billing-api service
  strong
  Priya ShahCODEOWNERS * @priya-shah64% of commits, 90 days
- invoices collection
  strong
  Priya Shahonly writer: billing-api
- payment-webhooks repository
  likely
  Jonas Berg58% of commits, 90 days
- dunning n8n workflow
  ambiguous
  Jonas Berg · Marta Silvalast edited by Jonas Bergrunbook late-payments.md
Needs youResearched
Who owns the dunning workflow?
What your agent found
- Jonas Berg made its last edit, 5 weeks ago
- the Late payments runbook names Marta Silva
Suggested answerMarta Silva
Owners suggested from evidence, in tiers. Only the ambiguous one reaches a person.
04You ask
What runs by itself?
Six automations touch the venue lifecycle. Two jobs drive a transition, one workflow drives dunning, and three only react to a state. One email campaign still waits for a TRIAL state the code removed, so it will never fire.
- declared:jobs, with file:line
- observed:runs and sends, 30 days
- derived:the orphaned campaign
1234?
- jobcontracts/sign.ts64 in 30 days · sign.ts:112
- jobactivate-venues.ts30 in 30 days · activate-venues.ts:48
- n8nMenu import reminder212 in 30 days
- n8ndunning118 in 30 days
- campaignWelcome to Acme64 in 30 days
- campaignTrial ending◐ waits for TRIAL, which the code no longer has
1. 1 signed → menu import
2. 2 menu import → training
3. 3 training → live
4. 4 live → past due
5. ? acts on nothing we know
drivesreacts
Each automation against the transition it acts on. A dot drives it, a ring reacts to it.
05You ask
Where does the funnel leak?
On get.acme.example, between lead and demo: 11% book a demo there, against 30% on the main site. Visits are not counted yet: this example company has not connected a traffic source, and the agent has asked for one.
- observed:stage counts, 90 days
- contributed:stage definitions, by an agent
- derived:conversion between stages
acme.exampleget.acme.examplepartners.acme.example
Visit
not countedThis example company has not connected a traffic source yet. Your agent has asked for one.
Lead
860
632
120
Demo
25830%
7011%the leak
4840%
Signed
9236%
2434%
2144%
Live
8188%
2083%
1990%
The same funnel for each site. An uncounted stage says why, instead of showing a zero.

SE 43 84How it works

Connectors derive. Your agent writes. People settle only the rest.

Trig has no model inside it. It collects, validates, merges and draws; your agent does the reading and the writing.

01
Connectors run on your machine
Across code, infrastructure, data, knowledge and business, with the logins you already have. Each mode says precisely what it reads and excludes. The server never calls a provider and refuses a snapshot that carries a secret.
02
Every fact says how it is known
Declared by a file, derived by Trig, observed by a connector, or contributed by an agent or a person, each with its age.
03
Your agent writes the business layer
It settles what connectors could only guess, then writes lifecycles, processes, journeys, owners and metrics, each element grounded in the code, data or document behind it.
540proposals, first run
212 confirmed309 rejected19 escalated
then it writes
- Venue lifecyclegrounded
- Onboarding processgrounded
- Billing ownersgrounded
- Live venues metricgrounded
04
People see only what it could not settle
One question at a time, in Needs you, with the agent’s research and the answer it would give. Your answer goes back to the agent.
Needs youResearched
Who owns the dunning workflow?
What your agent found
the Late payments runbook names Marta Silva
Suggested answer: Marta Silva

Explore the complete source library

SE 44 84The source library

One company. Many sources.

Start with what you already use. Explore connectors by business purpose, then inspect exactly what each mode reads. A supported source is not a promise to read everything in that service.

92 source families · 99 implemented connector modes

Connectors run locally. Credentials stay with you. Business sources expose selected structures or approved aggregates—not private customer, employee, payment or message records. Some require an existing report, entitlement or owner-approved schema. Boxtal is excluded.

Complete catalogue without interactive search.

Vercel (production deployments) · Infrastructure

Latest20 production deployment metadata observations for one explicitly approved Vercel project/team. Records deployment IDs, states and timestamps; not full history, current traffic, creator identity or a never-deployed verdict.

Only project/team scope, deployment IDs, statuses and timestamps leave the collector. Native creator/description/build/config/URL details are discarded locally. No environment, user, log, file or mutation endpoints.

Heroku (release observations) · Infrastructure

Latest20 release metadata observations for one explicitly approved Heroku app. Records release IDs, states and timestamps; not dyno liveness, complete history or a never-deployed verdict.

Only app scope, release IDs, statuses and timestamps leave the collector. Native user/description/stream/add-on details are discarded locally. Never requests config-vars, user, logs, streams or mutation endpoints.

Fly.io (machine observations) · Infrastructure

Current machine metadata/status observations for one explicitly approved Fly.io app. Records machine IDs, states, regions and timestamps; not complete deployment history or a never-deployed verdict.

Only app scope, machine IDs, statuses, regions and timestamps leave the collector. Native config/env/images/events/private IPs are discarded locally. Never requests secrets, console, logs or mutation endpoints.

Stripe (approved Sigma aggregates) · Money & accounting

Existing completed aggregate-only Sigma run: active/past-due/unpaid subscription stocks, completed UTC month failed-charge and currency-cohort subscriber-exit flows, or month-end currency-cohort MRR stock. MRR is recurring run rate, not recognized revenue; exits are events, not distinct people or a churn percentage.

SQL metadata is checked against generated aggregate-only templates before any CSV fetch. CSV has exactly one numeric cell, never customer/subscription/charge/event rows; native aggregation executes in Stripe. Query/title/file labels discarded locally. No arbitrary file URL, raw-export fallback, FX or invented metric definitions. Author/source/tenant/counts/newer/stock-flow protections apply.

Gorgias (owner-bound daily ticket aggregates) · Support & calls

30 complete native UTC daily tickets-created/ticketCount buckets, no dimensions or individual ticket IDs. Owner-explicit response column/encoding binding; not open-ticket stock, agents, conversations or response-time math.

Only native date/count aggregate rows accepted; exact two owner-bound fields, no ticket IDs/users/messages/nested objects. Column meaning and configured account are owner assertions, not independently API-verified; capture time is not provider freshness. Any stock reading, graph counts and authored/foreign/newer series preserved.

HubSpot (aggregate-only CRM stocks) · Customers & CRM

Credential-visible native CRM contact, company, deal or ticket totals. Stocks only: not unique humans, paying customers, daily acquisitions or revenue.

No contact/company/deal/ticket rows requested or received by the fixed query. Provider measurement timestamp absent: capture time does not prove freshness. Explicit zero retained; any series and authored/foreign/newer values preserved.

Zapier (selected-workflow governance) · Automation

Current Agentic Management policy of one exact next-gen workflow: enabled, saved heal/expand/harden modes and automatic-fix approval choice. Closed automation.governance technical aspect, not a synthetic metric, classic Zap inventory, task usage or run history.

Only one configured workflow UUID, optional manager automation UUID, booleans, closed modes and timestamp retained. No creator/person identity, title, intent, private variable, step/input/output, task or run data even transiently collected. Modes persist while disabled; empty modes do not mean never configured. Current selected next-gen workflow policy only, not classic usage or company-wide completeness.

Personio technical organization-unit structure · People & identity

Complete bounded department or team technical container enumeration, including ID-parent topology; optional current count in departments or teams. This is business organization structure, not headcount, payroll or employee membership. Company-unit labels/descriptions are received, validated and discarded locally.

Provider company-unit names, description, abbreviation and URI are bounded and discarded, not a server-side projection claim. Snapshot contains only IDs/parent IDs and structural count. Summary schema excludes employee leads; any people/nested unknown fields or expanded ancestry refused. No individual employee records. Source/capture/stock protections and authored counts-expression guard apply; collection is not an atomic provider transaction.

DocuSign available digital-signature provider capabilities · Office & workflows

Complete provisioned/available digital-signature provider technical-key inventory for a configured account, with optional current capability count in signatureProviders. NOT signature usage, completed signatures, sent envelopes, seats or billing quantity. Reserved option fields are never interpreted.

Only account-provisioned capability schema, no individual signers/documents/envelopes/users. Reserved provider option metadata/display values received, bounded and discarded; technical names only emitted. Any private/nested unknown records, paging or duplicate providers refused. Numeric billing units/periods remain unproven and unused. Source/capture/reading/series/counts-expression fences apply.

ClickUp (workspace seat stocks) · Office & workflows

One native used, total or available member/guest seat stock for a configured workspace. Seats are licences, not employees, active users, tasks or company customers. Unlimited guest capacity is not a finite number.

Six provider counters only, no members, users, tasks, names, emails or permissions. Retain selected native value and exact workspace/measure only; no sums, inferred headcount or daily history. Missing/private/ambiguous responses refuse; unlimited is unknown as a finite metric, never zero. Authored, graph-derived, foreign-source, newer and flow observations remain protected.

Yousign native add-on consumption and quota · Office & workflows

One current-subscription consumed or quota stock for a simple/advanced signature or seal add-on. Signature units are invitedSigners counted when sent, not completed signatures; seals use sealedDocuments. Quota is allowance, not usage. Provider dates preserved; reading only, never a daily series.

Only enum add-on names, provider subscription dates and safe integer quota/consumed counts; one selected aggregate emitted. Never signer/document/employee/contact/identity records, exports or provider writes. Unknown fields, paging, absent/ambiguous/inactive periods refused. Contributed/foreign/null/newer capture and reading, active series and authored counts expressions protected. Scope remains explicit owner attestation.

Typeform (selected workspace form count) · Office & workflows

Native current forms.count for one exact preapproved workspace/account, bound to an authored forms metric. Credential-visible technical container stock, not submissions, responses, questions, leads or company-wide coverage.

Only configured region/account/workspace technical IDs, integer native form count and timestamp are retained. Workspace labels/shared flags/technical links and other container IDs are validated then discarded. No member identities, respondent answers, form questions/options/defaults, response metadata or tokens. Current selected-workspace stock, not historical flow or guaranteed company completeness.

Airtable (approved base-container visibility) · Office & workflows

Confirmed visibility of an exact approved technical base-ID set, bound to an authored bases metric. On success the count equals the approved set size; missing/unreadable bases produce unknown/error. Not record counts, tables, field schemas, usage or company-wide inventory.

Only configured approved base IDs, confirmed integer count and timestamp are retained. Returned base names, permission levels and unapproved technical IDs are discarded. No rows, select choices, formulas, field defaults, collaborator/member identities or secrets. Successful count equals allowlist size; not whole-account/company inventory, historical flow or data quality.

Aircall (campaign aggregate stocks) · Support & calls

One selected campaign contact or active-call stock. Contacts are campaign entries, not unique people or company customers; never daily calls, outcome rows or summed buckets.

Only the selected integer is persisted; no contacts, calls, phone numbers, progress percentage or duration math. Provider supplies no observation timestamp; capture time is not verified freshness. Missing refuses, zero retained; series/authored/foreign/newer values preserved.

Ringover (plan licence stocks) · Support & calls

One selected plan licence stock, owned or used, from the provider-defined team plan counters. Not employees, customers, calls, activity flows or a sum across plans.

Only the selected owned/used count and plan ID persist; technical plan names are validated but not stored. No users, numbers, calls or recordings. No provider timestamp: capture time is not proven freshness. Missing plan is unknown, not zero; conflicting metrics preserved.

Supabase (experimental schema metadata) · Infrastructure

One count of technical schemas in an exact project's selected database, from the native metadata-context API. Credential-visible structure stock explicitly bound to an authored schemas metric; not database records, data quality, revenue or complete company semantics.

Only configured project ref/database technical name, integer schema count and timestamp are retained. Schema identifiers are metadata-only and discarded after unique counting. No rows, column examples, user/employee identities, credentials, keys, connection settings, SQL or grants. Explicit experimental consent is rechecked at ingest; current reading, not historical series or a guaranteed complete physical inventory.

Vercel (access-group project counts) · Infrastructure

One count of credential-visible project containers in an exact existing team access group, explicitly bound to an authored projects metric. Not all team/company projects, deployments, performance, revenue or complete backend inventory.

Only configured technical team/access-group IDs, integer project count and timestamp are retained. Returned technical project IDs/slugs/framework/deployment IDs and closed role/timestamps are validated then discarded. No creators, names of people, users, members, env values, tokens, row samples, deployment logs or grant changes. Current selected-group stock, not account-wide completeness, an atomic snapshot or invented history.

Lucca provider-side department count · People & identity

One credential-visible native department totalCount observed as current stock, unit departments. limit=0 negotiates zero maximum rows; no department managers, employees or names fetched. Not employee headcount.

Native zero-row aggregate, never locally counted employee/manager records. Fixed host/version/query, zero maximum page size independently documented; any returned item, expanded links/embedded fields, changed version, unknown/partial/error response refused. Current stock protects authored unit/counts, contributed/foreign/null/newer readings and series.

BambooHR compensation-group status counts · People & identity

One provider-native draft/historic/published compensation-level-group current stock, unit compensationGroups. Draft counts only drafts with a visited setup step when a published baseline exists; otherwise all draft groups. Not employee headcount, salaries or payroll totals.

Provider-side counts only, no employee, manager, names, pay-band values, job-title assignments, audiences, holiday pay or salaries fetched even transiently. Scope breadth is disclosed. Unknown fields/missing counts/errors/paging refused; no headcount or currency inference.

PayFit company-month payroll workflow state · People & identity

Company payroll workflow completed/not_completed state for the last completed UTC-selected calendar month, with the provider's nullable last executionEndDate. Useful company process fact; no numeric metric, completion percentage, invented history, headcount, salary amount or payment proof.

Company-month state and provider timestamp only. No employee, contract, salary, payslip, documents or payment records fetched. A status is not an invented 0/1 observation and completed is not proof employees were paid. Unknown fields/states/invalid future timestamps/errors/paging refused. Source-isolated contributed/foreign/null/newer capture protected.

Crisp (aggregate CRM profile stock) · Support & calls

Current CRM profile stock for one configured Crisp website. Not unique humans, paying customers, daily new profiles or a company-wide customer count.

Only total is read; no people/profile/message/visitor/admin objects. Provider supplies no observation timestamp: at is capture time, not proven provider freshness. Missing refuses, explicit zero retained; flow/authored/foreign/newer values preserved.

Intercom (legacy v2.3 global conversation stock) · Support & calls

One selected global App conversation-state stock using documented legacy API v2.3. Open/closed and assignment buckets overlap; never summed, daily flows, response-time statistics or employee metrics.

Only four global counts; no conversations/messages/customers/admin IDs. No provider observation timestamp: capture time is not freshness proof. Assignment/state buckets overlap. Missing refuses; numeric zero retained; flows/authored/foreign/newer values preserved.

Sendcloud (v3 carrier-lane aggregates) · Commerce & apps

Native transit-cohort parcel count or median hours/days for one carrier/lane over thirty completed UTC dates. Report reading, not all shipments, a daily flow or an averaged median.

Provider aggregates only; no shipments,customers,addresses or names. Only selected value,cohort size,technical carrier/lane and report period retained. Owner-attested account is not API identity proof. Missing unknown,explicit zero count retained; medians never summed/averaged or made daily; authored/foreign/newer/flow values protected.

Xero fixed Executive Summary aggregates · Money & accounting

One fixed English-layout Executive Summary aggregate for the last completed UTC-selected calendar month: cashReceived, cashSpent, closingBankBalance, income, expenses, profit or invoicesIssued. Observed report reading with explicit period, never a daily series or current balance. Cash received is not revenue; Income is the provider accounting label.

Fixed provider-side aggregate report only; no individual invoices, contacts, transactions, employees, settings or identity API. Organization label in the report is discarded and never treated as tenant/currency proof. Unknown labels, nested attributes, changed layout, mixed periods, partial/error responses and ambiguous decimals refused. Reading protects authored counts expressions, unit/currency, contributed/foreign/null/newer observations and daily series.

App Store Connect (app container total) · Commerce & apps

One provider-returned total of team-key-visible app containers, explicitly bound to an authored apps metric. Technical stock only, not downloads, subscriptions, sales, revenue or complete mobile analytics.

Only configured technical issuer UUID, integer app-container total and timestamp are retained. A maximum of one app's technical bundle ID/resource ID is projected by Apple and discarded after validation. No names, testers, users, reviews, downloads, sales/finance rows, report files, report subscriptions, private signing keys or permission changes. Current stock reading, no invented series.

PrestaShop (shop container counts) · Commerce & apps

One count of credential-visible shop containers in an explicit PrestaShop shop context, from complete server-projected technical IDs. Current technical structure only, not order/customer counts, revenue or active-shop status.

Only canonical configured storefront host/context ID, numeric shop-container count and timestamp are retained. Numeric shop IDs are technical container metadata, server-projected and discarded after counting; no shop names or customer, order, employee, product or sales rows are requested. Self-hosted DNS must be exclusively public and TLS-pinned. Current credential-visible stock, not guaranteed account-wide completeness or an atomic paging snapshot.

GoCardless (aggregate creditor balance stocks) · Money & accounting

One selected creditor balance stock in explicit major currency units at provider last_updated_at. Not revenue, payment counts, bank-account cash, daily movements or private financial records.

Only balance type, amount, currency, provider timestamp and creditor link. Explicit reviewed exponent2 table and rawminor proof; no FX or sums. Provider timestamp retained, one-hour selected freshness bound. Missing unknown, zero/negative retained; flows/authored/foreign/newer values preserved.

Shopify (exact daily order creation counts) · Commerce & apps

Exact indexed non-test order creation counts by UTC day, bound to an authored orders flow metric. Not paid sales, revenue, customer records, order-status stocks or shop-local dates.

Only structural shop identity/scope handles and date/count/precision. No raw orders/customers, mutations or grants. read_orders is broader permission than this query. Exact provider index can lag and deletions revise history; UTC-2 lag, explicit zero retained, missing unknown. Scalar/authored/foreign/newer values protected.

Asana project task-count aggregates · Office & workflows

One current provider-side project task or milestone count as a stock reading: total, completed or incomplete. Milestones are included in task totals; this is not daily completion throughput.

Provider-side aggregate only, no individual tasks, titles, assignees, comments, users or teams fetched. Unknown or ignored projection refused. Task-count fields have an additional provider rate/cost limit. Current stock reading protects authored, foreign, null-owned, newer and flow observations.

Monday board aggregate item count · Office & workflows

Provider-defined current items_count of one explicit board, as a stock reading. No item/subitem records, completion-rate inference or daily flow.

Read-only POST GraphQL query, never mutation. No items_page, titles, owners, subscribers, column values, updates or identities. Fixed selected numeric count and technical ID only. Errors, unexpected fields, changed version or ambiguous board results refused.

Trello projected list containers · Office & workflows

Technical list containers (ID, archived flag, position) from one explicit board. Optional totalLists/openLists current stock reading with unit lists; never card/task counts.

No card, name, description, member, comment, checklist, attachment or action APIs. Token stays in Authorization, never URL. Projected list containers only; no business relationship inferred and no all-company completeness claim.

Tally cumulative form analytics · Office & workflows

One cumulative period=all native count (visits, submissions, uniqueRespondents, totalViews, starts or completions) observed now. Not daily increments, timezone guesses, conversion rates or individual form responses.

Only fixed numeric form analytics; no form title/questions, response/answer values, respondent identity, source/location dimensions or API writes. Broad inherited key rights are disclosed. Count is cumulative stock, not a repeated daily flow; missing selected measure is unknown, never zero.

BigQuery (dataset structure counts) · Analytics & reporting

One fixed INFORMATION_SCHEMA table/view count for an exact project and dataset, explicitly bound to an authored metric; current technical structure, not company records or revenue.

Only configured technical project/dataset/location, closed table type and integer count. No individual table metadata, DDL, sample values, customer rows, arbitrary SQL, data exports or IAM changes. Counts reflect credential-visible structure and use a stock reading, not invented history.

Snowflake (schema structure counts) · Analytics & reporting

One fixed INFORMATION_SCHEMA table/view count for an exact database/schema/read role, explicitly bound to an authored metric; credential-visible technical structure, never company records.

Only configured technical account/database/schema/warehouse/role, closed selector and count. No TABLE_OWNER, names, comments, DDL, data records, arbitrary SQL or grants. INFORMATION_SCHEMA visibility follows the selected role, not guaranteed account-wide completeness; stock reading only.

Metabase Cloud (schema counts) · Analytics & reporting

One count of credential-visible database schema namespaces containing visible tables, explicitly bound to an authored schemas metric; technical metadata, not database rows or all physical schemas.

Only configured Cloud subdomain/database id and numeric schema count are retained. Technical schema-name metadata is read solely to count namespaces and not persisted; no connection details, passwords, users, row samples, database rows or query results. This is schema metadata coverage, not full BI/dashboard semantics.

Looker (LookML model counts) · Analytics & reporting

One count of credential-visible LookML models from sparse technical model metadata, explicitly bound to an authored models metric; internal/self-service models excluded, no analytics query execution.

Only configured technical host, closed models measure, integer count and timestamp retained. Sparse model names are read as technical metadata and discarded, never individuals or user labels. No model descriptions, SQL, connection data, users, query results or dashboards. Complete page walk is not an atomic provider snapshot or account-wide completeness claim.

WooCommerce (order-status aggregate stocks) · Commerce & apps

Current selected order-status count mapped to an explicitly authored orders stock reading. Not daily new orders, sales, revenue, customer records or company-wide completeness.

No raw order/customer endpoints or status names. Canonical public host, public DNS answers and pinned TLS lookup prevent private addresses/rebinding. Missing statuses remain unknown; explicit numeric zero is retained. Scalars never replace flow series.

Make daily organization usage · Automation

Twenty-eight completed organization-local daily operations or native centicredits. Not execution logs, monetary spend, workflow payloads or inferred revenue.

One GET organization usage, no scenario, execution, blueprint, bundle or user APIs. Organization timezone is owner-declared, not independently verified. Credits remain native centicredits, never currency. Missing dates prevent series refresh; dataTransfer is not mapped because its unit has not been established.

Teams channel containers · Office & workflows

Credential-visible channel containers with hashed technical IDs and standard/private/shared membership type. Optional current channel-count reading; no messages, members or whole-company completeness claim.

Never fetch channel display names, emails, descriptions, messages or members. One fixed sparse GET; technical IDs are hashed. Visibility depends on permissions/private-channel membership, not all-company proof. Broad OAuth permission is distinct from GET-only collector behavior.

Outlook calendar structure or inbox counters · Office & workflows

Calendar containers with hashed IDs/default/editability, or the well-known inbox's current total/unread item counters. Optional stock reading with unit calendars or items. Never events, email records, sent/received flow or customer counts.

No calendar owner/name/event, folder name, message header/body, recipient or mailbox traversal. Inbox counters may include non-email item types; they are not message flow. Container IDs hashed; paginated calendar lists refused rather than treated complete.

Google primary-calendar timezone · Office & workflows

Provider-reported IANA timezone of the authenticated primary calendar: a verifiable scheduling structure fact, not event counts, availability or business performance. No metric binding.

Provider-side sparse projection requests no ID, summary, description, location or owner. Primary alias avoids email-form calendar IDs. No events, free/busy, attendees or implicit metric; ignored projection is refused.

Google Play (daily crash percentages) · Commerce & apps

API-confirmed app-level daily crash percentages mapped to explicitly authored percentage readings. Stability context only: no installs, revenue, reviews, summed rates or exact user counts.

No individuals, dimensions, custom filters or rounded distinctUsers. Provider percentages retain their numeric scale; never summed into daily flows. Missing, stale, sampled, partial, uncertain or unsupported outputs are refused or unknown.

Odoo 19 Online (company counts) · Customers & CRM

One fixed company-scoped current employee, opportunity or sales-order count, explicitly bound to an authored metric; an observed stock, never a daily flow.

Only configured technical subdomain/company id, closed measure, scalar count and timestamp. No employees, names, payroll, opportunities or order rows are fetched. Visibility is credential-scoped, not guaranteed company-wide. Headcount is current active-record stock, not historical staffing.

Pennylane (non-auxiliary ledger totals) · Money & accounting

One authored amount metric from the previous complete UTC month's selected non-auxiliary ledger account: debits, credits or exact netDebit; not automatically revenue.

Non-auxiliary account codes and aggregate decimal debits/credits only; provider account labels are discarded. No invoice, transaction, customer, vendor or payroll export. Missing selected account means unknown, not zero. Explicit company/currency attestation remains visible in every metric reading.

Sage Active (accounting KPIs) · Money & accounting

One fixed accountingKpis monetary aggregate for a configured organization, explicitly bound to an authored amount metric; provider-defined period, not assumed monthly or daily revenue.

Technical organization id, closed KPI, monetary value, provider currency and timestamp only. No employee/payroll/customer/invoice records. Report period is explicitly not supplied by provider; no invented history. Two local credentials must belong to the same app/account, not mixed stores.

QuickBooks Online (document counts) · Money & accounting

One fixed COUNT(*) of invoices, bills, sales receipts or credit memos dated in the previous complete UTC month, explicitly bound to an authored document-count metric; not revenue or paid transaction volume.

Only technical realm/environment, closed document type, complete-month bounds, integer count and timestamp. The official count contract returns no accounting objects. Individual invoices/bills/sales receipts/credit memos are never fetched, even transiently. Broad OAuth capability remains an explicit limitation.

Meta Ads (account delivery aggregates) · Marketing

Daily account-level impressions and clicks bound to explicitly authored business flow metrics. Delivery counts only, not revenue, conversions, spend or ROI.

No individual records, audience/demographic breakdowns, campaign/ad names or arbitrary queries. Impressions below three and absent days remain unknown, not zero; this is not distinct-user anonymity. Refuse pagination, reported sampling/truncation and incomplete business series.

Google Ads (customer delivery aggregates) · Marketing

Daily account-level impressions and clicks bound to explicitly authored business flow metrics. Delivery counts only, not revenue, conversions, spend or ROI.

LinkedIn Ads (UTC account delivery aggregates) · Marketing

Daily account-level impressions and clicks bound to explicitly authored business flow metrics. Delivery counts only, not revenue, conversions, spend or ROI.

TikTok Ads (advertiser delivery aggregates) · Marketing

Daily account-level impressions and clicks bound to explicitly authored business flow metrics. Delivery counts only, not revenue, conversions, spend or ROI.

PostHog (daily pageview aggregates) · Analytics & reporting

UTC daily $pageview counts bound to one already-authored views metric; no arbitrary SQL or automatic business concepts.

Only ISO dates and integers. Event-count floor of three is not distinct-user anonymity. Missing/suppressed dates remain unknown; partial/sampled/truncated outputs are refused.

Amplitude (daily event aggregates) · Analytics & reporting

Daily any-event totals bound to one already-authored events metric; no event/user properties or breakdowns.

No segments, group-by, profiles or raw exports. ISO dates and integer totals only. Small/missing dates stay unknown; complete coverage is required for a business series.

Mixpanel (approved daily Insights aggregates) · Analytics & reporting

One approved daily $pageview total-count Insights report, bound to an already-authored views metric. Uses supported Insights, not maintenance-only Segmentation.

Owner-approved aggregates only. No exports, user profiles, account lookup or report creation. Wrong events/dimensions, nested breakdowns, non-daily dates and stale/partial/sampled results are refused.

Stripe balance aggregates · Money & accounting

Available or pending account balance as an observed point-in-time major-unit currency reading, not revenue, churn or a daily flow. Exact native minor amounts and documented exponents are preserved and verified. Existing Stripe metadata connector unchanged.

Only GET /v1/balance; no account, transaction, payment, invoice, subscription or customer record APIs. Signed raw minor amounts and explicit documented exponent are preserved; the server independently verifies major-unit conversion. Missing currency is unknown, not zero. Authored/foreign/newer readings and all flow series are protected. Credential access is not independent account identity proof.

Mollie closing balance report · Money & accounting

Closing available or pending balance from one completed Europe/Amsterdam report date as an observed point-in-time reading. A balance stock, not revenue or payments.

GET balance report only, fixed status-balances grouping and one completed provider date. Never call the ordinary balance endpoint, which includes bank and beneficiary details; never read transactions. Only closing amounts are projected into snapshots.

Brevo daily transactional aggregates · Marketing

Thirty completed daily SMTP aggregate counts for one fixed measure: requests, delivered, uniqueOpens, uniqueClicks, hardBounces, softBounces, blocked, spamReports or unsubscribed.

GET /v3/smtp/statistics/reports with completed dates only, no tag/sender/message filter, no event or recipient endpoints. Missing days are unknown and prevent business-series refresh. Provider-defined daily reporting timezone is retained in basis rather than misrepresented as UTC.

Klaviyo daily metric aggregates · Marketing

Thirty completed UTC event-time aggregate counts or unique-profile counts for one explicit provider metric. No campaign/profile dimensions or arbitrary filters; this is not send-time campaign UI reporting.

Read-only POST metric-aggregates query, fixed UTC/day time bounds and empty dimensions. No profile/event APIs or provider writes. Dimensional, paginated, malformed or incomplete aggregate reports cannot refresh a business series. Event-time reporting may differ from campaign send-time UI.

Mailchimp campaign cumulative aggregates · Marketing

Cumulative lifetime numeric report for one explicitly selected sent campaign as an observed reading. Not daily increments; opens/clicks may include bots or privacy-related prefetching.

GET one campaign report with a fixed server-side sparse field allowlist: id and numeric send/open/click/unsubscribe totals only. No subject, sender, audience names, recipient, contact or click-detail endpoints. Any ignored sparse projection is refused. Reading protects authored/foreign/newer observations and all flow series.

Zendesk (ticket counts) · Support & calls

One explicitly bound current ticket count for a fixed standard status; observed stock reading, never a daily flow.

Only configured subdomain, fixed status, numeric count and collection timestamp. No tickets, users, comments, names, emails, arbitrary search or exports. Current stock uses an observed metric reading, not a historical daily series. No live source access or permissions granted.

Salesforce (CRM counts) · Customers & CRM

One explicitly bound current opportunity or unconverted lead count from fixed COUNT(Id) SOQL; observed stock reading, never a conversion rate or daily flow.

Only configured technical host, fixed count selection, numeric value and timestamp. No CRM records, user identity calls, names, emails, stage labels or private fields. Host is the source-account fence; visibility reflects the token, not a full company guarantee.

Pipedrive (deal counts) · Customers & CRM

One explicitly bound current non-archived deal count by open, won or lost status and optional configured stage id; observed stock reading.

Only configured company subdomain, fixed status, optional stage id, total count and timestamp. Provider aggregate money summaries are discarded and never mislabeled as revenue. No deals, contacts, names, notes, emails or exports. Only non-archived credential-visible deals are counted.

Google Sheets (approved aggregates) · Analytics & reporting

One explicit approved daily aggregate range, bound to one existing authored metric with matching unit and currency.

Only owner-approved pre-aggregated ISO date/numeric cells. No worksheet download, formulas, labels, people or operational record exports. Blank numeric cells are unknown, never zero; incomplete ranges preserve existing series. No automatic business meaning or permission grants. Live access unverified.

Microsoft Excel (approved aggregates) · Analytics & reporting

One explicit approved daily aggregate range, bound to one existing authored metric with matching unit and currency.

Google Analytics 4 (daily aggregates) · Analytics & reporting

Daily GA4 sessions, engaged sessions and page/screen views for one explicit property. Only explicitly bound authored metrics receive complete observed series.

Date-only aggregate counts with totalUsers >= 3 filtered by Google before return. No names, emails, user ids, event payloads, URLs, arbitrary dimensions or record APIs. Missing/suppressed dates are unknown, never zero; incomplete coverage writes no business series. Dates retain the property timezone. Counts are rolling observations, not finalised accounting.

Microsoft 365 (SharePoint schemas) · Office & workflows

One verified nonpersonal SharePoint site and its credential-visible nonsystem list/library column schemas. No items, files or inferred business meaning.

Site/list/column ids, redacted labels, API column names, template and column type names, required/read-only flags. Never list items, files, content, mail, Teams, people, permissions, descriptions, default/choice/lookup values or formulas. Hidden/system resources excluded; unsupported types remain unknown. Missing visibility is not deletion.

GitHub · Code

Repositories, their CI workflows, Dockerfiles and package.json, and what each pipeline says it deploys.

Repository names and metadata, the TEXT of workflow files, Dockerfiles and package.json. No other source file, no secret values, no issue or PR content.

GitLab · Code

Projects of a GitLab group (gitlab.com or self-hosted), their CI pipelines and the scripts and Makefiles those run, Dockerfiles and package.json, and what each pipeline says it builds and deploys, read CI-first.

Project metadata; the TEXT of pipelines, the scripts and Makefiles they run and Dockerfiles (typed-in passwords redacted here) and package.json; commit authors; members' public names and addresses. Never a CI/CD variable, issue or merge request.

Bitbucket · Code

Repositories of a Bitbucket Cloud workspace, their pipelines (steps, deployments, the AWS pipes) and the scripts and Makefiles those run, Dockerfiles and package.json, and what each pipeline says it builds and deploys, read CI-first.

Repository metadata; the TEXT of bitbucket-pipelines.yml, the scripts and Makefiles it runs and Dockerfiles (typed-in passwords redacted here) and package.json; commit authors; members' display names. Never a variable, pull request or other source file.

AWS · Infrastructure

What is actually running: App Runner, ECS clusters and services, Lambda and the function URLs they answer on, ECR, S3, RDS, DynamoDB tables (key schema, indexes, billing, stream; never items), and the NAMES of SSM parameters and secrets.

Resource names, ARNs, images, sizes and tags; environment variable NAMES only. Never an environment value, an SSM value, a secret value or a DynamoDB item (tables are read for their shape and AWS's item-count estimate).

MongoDB · Databases

Databases, collections, views and indexes, with sampled field names — metadata only, never a document. Opt-in, how many records sit in each category of the fields you name (lead source, marketing segment, pipeline stage, the site a lead came from) and how many arrive per day, week or month, written as a metric's series; only values that read as category labels are kept, never an address, a phone number or free text.

Database and collection names, counts, sizes, indexes and sampled FIELD NAMES. Never a document, a value or the connection string, unless the source opts in to a people read: then the staff collection it names, projected to the fields it lists (an address is required; a password hash, salt, token or key is refused).

Cairn · Knowledge

What people and agents learned, and which projects are actually worked on: projects, recent tasks, knowledge entries and repository mappings.

Project names, task titles and statuses, knowledge entry text, and git remote URLs of mapped repositories.

Documentation checkout · Knowledge

Runbooks and inventories in a git repository of markdown — what the company SAYS about itself, and how stale each page is.

The full TEXT of every tracked markdown file, capped at 40 000 characters each, plus its commit history (authors, dates). Relative paths only, never this machine's path.

Notion · Knowledge

Pages and databases the integration can see — what the company says it is doing, and how long ago it said so.

The TEXT of every page shared with the integration (blocks slimmed to their words), titles, authors and edit dates. Nothing it was not shared.

Google Docs · Knowledge

Google Docs in Drive and shared drives — the ownership matrices and runbooks that never made it into a repository.

The TEXT of every Google Doc the principal can open (bodies slimmed to their words), titles, owners' names and emails, and shared drive names.

Buddy · Infrastructure

Buddy.Works pipelines: which pipeline builds and deploys which App Runner service, Lambda, ECS service, ECR image, S3 bucket or host, from which repo and branch, whether it is disabled, and when it last ran. Closes the "nothing deploys this" gaps left by pipelines not yet moved to GitHub Actions.

Pipeline and action names, targets and execution statuses (placeholder until the collector lands). Never a variable value.

PostgreSQL · Databases

Schemas, tables, views, columns, keys, indexes, view dependencies and planner row estimates. RDS databases attach to existing AWS entities. Explicit opt-ins add exact counts, privacy-masked categorical breakdowns and metric series for lifecycles, acquisition and journeys. Never individual rows.

Catalog names, types, row estimates and sizes; optional exact counts and safe categorical labels held by at least three records. More than fifty categories drops all labels. Personal fields are refused and hostname transforms discard paths and queries. Never individual rows, defaults, view definitions, passwords or connection URLs.

MySQL · Databases

Tables, views, columns, keys, indexes, view dependencies and storage-engine row estimates. RDS databases attach to existing AWS entities. On MySQL 8.0+, explicit opt-ins add exact counts, privacy-masked categorical breakdowns and metric series for lifecycles, acquisition and journeys. Never individual rows.

n8n · Automation

n8n workflows as the processes they are: how each starts (webhook, schedule, app trigger, sub-workflow, manual), which sub-workflows it calls and which error workflow catches it, the HTTP hosts, MongoDB collections, SQL tables, S3 buckets, Lambdas and apps (Slack, Google, Customer.io, OpenAI, Aircall …) its nodes touch, the credentials it holds by type and name, and how its recent runs ended. Name-only matches (a collection or table the node names without its database) go to the queue as proposals, never as edges.

Workflow names, tags, active/archived, trigger kinds and schedules, node names and types, the hostnames, paths, collection, table, bucket, function, channel and sheet names nodes name, credential types and names, and execution counts and last-run status/time. Never a node body, header, query, code, prompt, pinned or static data, credential value or execution data.

Shopify · Commerce & apps

A provider-verified Shopify shop, its product titles and statuses, variants and exact catalogue prices in shop currency. No customers, orders, sales or channel publication inference.

Shop id, canonical domain and currency; product ids, redacted titles and statuses; variant ids, product references, redacted titles and exact decimal prices. Never customers, orders, inventory values, metafields, descriptions, images, staff, webhook or payment data.

Confluence Cloud · Knowledge

Credential-visible current global spaces and page metadata in one verified Confluence Cloud site. No document bodies, personal spaces or inferred business meaning.

Cloud id, configured host, space/page ids, redacted space names and page titles, and exact page-to-space membership. Never bodies, personal spaces, authors, owners, users, comments, attachments, descriptions, permissions, versions or provider links. Visibility is credential-accessible, not a company-wide inventory; absence never proves deletion.

Okta · People & identity

Default user and group field schemas in one verified Okta organisation. Schemas only: no people, teams, directory instances, memberships, applications or assignments.

Organisation id, configured host, default schema kinds, field names/types, redacted labels, base/custom section and required flags (unknown stays null). Never profile values, people, group instances, memberships, assignments, applications, logs, contacts, defaults, enum values, patterns, descriptions, permissions or links. Nested array item definitions are not collected.

Salesforce · Customers & CRM

Credential-visible field schemas for Account, Contact, Lead, Opportunity and Case in one verified Salesforce organisation. No records, volumes, pipelines or inferred transitions.

Organisation id, configured host, core object names and redacted labels, field names/types, nullable flags and referenced object names. Never records, other users, identity profiles, emails, picklist/default values, formulas, layouts, free descriptions, record types, SOQL, search or exports. Visibility is credential-accessible, not company-wide.

Zendesk · Support & calls

Ticket field schemas, form field membership and declared status categories in one canonical Zendesk subdomain. No tickets, customers, volumes or observed transitions.

Canonical subdomain, field ids/types/redacted titles and active/required flags, form ids/redacted names/field membership and active flag, status ids/redacted labels/categories and active flag. Never tickets, comments, customers, users, organisations, options, conditions, rules, descriptions or account settings.

HubSpot · Customers & CRM

A provider-verified HubSpot portal, contact/company/deal property names and types, and declared deal pipeline and stage labels and order. No CRM records, observed transitions or conversion counts.

Portal id, redacted property labels, property names and types, pipeline/stage ids, redacted labels and display order. Never property option values, descriptions, formulas, arbitrary metadata, contacts, companies, deals, tickets, activities, owners, exports or search results.

Stripe · Money & accounting

An explicitly scoped Stripe account and key mode, its products and active or archived prices, currency, minor-unit price amount and billing recurrence. Published offers only, not revenue or subscribers.

Product ids and redacted names, active state and default price references; price ids, product references, currency, amount and recurrence. Never descriptions, metadata, URLs, customer or subscription records, invoices, payments, balances, cards or event payloads.

Customer.io · Marketing

The lifecycle-messaging layer of a Customer.io workspace: every campaign, broadcast (newsletters and API-triggered) and transactional message — how it starts (the event name or segment it waits for, a date attribute, an API call), the segments it filters on or is sent to, its steps as types and counts, where its webhook steps and the workspace's reporting webhooks call, and how many messages it sent, delivered, opened, clicked, converted, bounced and unsubscribed over a window. Segments become audiences (with their size when a running automation uses them) and event names concepts, so "contrat-signe → Emails avis + parrainage" is an edge. Who emits an event (an n8n workflow tracking it, code that moves a collection to a status of the same words) goes to the queue as a proposal, and so does the lifecycle an automation may drive (its trigger has the same words as a collection's state); never as an edge.

Campaign, broadcast, newsletter, transactional message and segment names, states, tags and timestamps; trigger event names, segment ids and the attribute and event NAMES conditions test; step types and counts; the hosts webhooks call; object type names; segment sizes; and summed message counts. Never a person, profile, attribute value, email address, message body, webhook path, header or secret, or a delivery.

Slack · Knowledge

The Slack workspace and its channels — name, topic, purpose, public or private, archived, member count — so the apps n8n and others post with land on it. Which product, feature, process, system, service or repository each channel is about (its name, topic or purpose names it: a proposal, never an edge), the members Trig already knows as people (matched by profile email, else by name), the team most of a channel's members are in as its proposed owner, and the bots installed and the channels they sit in.

Channel names, ids, topics and purposes (user mentions replaced by @someone, emails and anything shaped like a credential masked), member counts, bot names. A person leaves the machine only as an opaque ref and SHA-256 hashes of their email and name, which the server compares with the people the company layer holds; unmatched members stay counts. Never a message, a file, a DM, or a person's Slack id, name or email in clear.

Linear · Knowledge

Linear teams, projects and initiatives as tracker systems: how many issues each carries and in what state (counted, never copied), its cycles, milestones and labels, and which GitHub repositories its issues link to (Linear's GitHub integration and attachments) as declared tracks edges. Proposes the repository a project is only named after, the product or feature it matches in the company layer, the Cairn project imported from it, and its lead as owner when that person is already on the map.

Team, project, initiative, milestone and label names; issue COUNTS by state, priority, label and cycle; the org/repo of GitHub links on issues; a parent issue's title only when short and free of anything shaped like an email, a number, a link or a quotation; a project lead's display name (to match a person already on the map). Never an issue's description or comment, never an email.

Jira · Knowledge

Jira projects and epics as tracker systems: how many issues each carries and in what status category (counted, never copied), sprints counted, and which GitHub repositories the issues' remote links name as declared tracks edges. Proposes the repository a project or epic is only named after, the product or feature it matches in the company layer, and its lead as owner when that person is already on the map.

Project and epic names (an epic's summary only when short and free of anything shaped like an email, a number, a link or a quotation); issue COUNTS by status category, priority, label and sprint; the org/repo of GitHub remote links; a project lead's display name (to match a person already on the map). Never an issue's summary, description or comment, never an email.

DNS · Infrastructure

Which hostname points at what: every name of the company's domains (the configured ones, the hostnames the graph already knows under them, and — with a provider credential — every record of the zone) and the App Runner service, S3 bucket, load balancer, CloudFront distribution, other hostname or external platform (Vercel, Netlify, Heroku, GitHub Pages, Stripe, Customer.io…) that serves it. Flags dangling records — a CNAME or alias whose target no longer exists, a subdomain takeover risk — and records each zone's nameservers, mail provider, SPF policy and verification markers. Optional publicDiscovery adds bounded site/legal/jobs technology hints, in-domain certificate candidates and explicitly selected GitHub organisation repository metadata; public hints are not private deployment proof.

Hostnames, record types and targets, addresses, nameservers, MX hosts, the SPF policy and the NAMES of verification TXT markers. Never a TXT value otherwise, never a token. Opt-in discovery retains URLs, allowlisted technologies, certificate names and public organisation repo names/languages only; never HTML, legal/job text, contacts, certificate subjects, code or people.

Docker Compose, Swarm and Traefik · Infrastructure

What runs where, and on which hostname: each Docker host's Compose projects and Swarm stacks, their services and containers (running or stopped), the image each runs (built on the host, or pulled from which registry), the networks stacks share, the Traefik routers that send a hostname to each service (tied to the DNS connector's hostnames), and the repository a stack runs from when it is a GitHub runner's checkout. Compose files in local checkouts add what each repository declares and builds. Flags a routed hostname whose service has no running container, and one public DNS does not send to the host that routes it.

Service, container, image, network and volume NAMES, published ports, Traefik router rules and hostnames, and environment variable NAMES — split out on the server by the inspect template, so no value crosses the wire. Never an environment value, a label value other than routing and bookkeeping ones, a Traefik argument outside the provider flags, a bind mount's host path (bar the Traefik file-provider directory, named in the line that says it cannot be read), or a file's content beyond the compose file itself. Traefik file-provider files are read on this machine and cut to routers: no middleware, TLS option or credential in them is sent.

Google Cloud · Infrastructure

What is actually running in Google Cloud: Cloud Run services and their custom domains, Cloud Functions, GKE clusters, Artifact Registry images (and whether what runs can still be pulled), Cloud Storage buckets, Cloud SQL and Firestore, Pub/Sub topics and subscriptions, and the NAMES of Secret Manager secrets.

Resource names, regions, images, labels and statuses; environment variable NAMES only, and Secret Manager secret NAMES only. Never an environment value or a secret value; a push endpoint is kept without its query string.

Azure · Infrastructure

What is actually running in Azure: Container Apps and their environments, App Service apps and Function Apps with their custom domains, AKS clusters, Azure Container Registry images (and whether what runs can still be pulled), storage accounts, Azure SQL and Cosmos DB, Service Bus queues and topics, and the NAMES of Key Vault secrets.

Resource names, regions, resource groups, images, tags and statuses; Container App environment variable NAMES only, Key Vault secret NAMES only. App Service settings are never read (they are values); a Container App's plain environment values are dropped on the operator's machine.

Code (local checkouts) · Code

What the code says it does: which MongoDB collections each repository reads and writes (through the driver, an aggregation's $lookup, or a Mongoose model it imports), which of the company's services it calls (by the environment variable holding their address), which outside providers it uses (an SDK, a provider's environment variable or its API host), the states a model's status field may take and the states jobs set and filter on. Drawn from the repository, and from what it deploys when the file can be tied to one service or function. Every program file run on a schedule or off a queue (jobs/, workers/, a Lambda handler, or one a PM2 list, crontab, serverless.yml or cron CSV names) becomes a job, with when it runs and the Lambda that runs it; each state change is credited to the job file and line that makes it ("CONTRACT_SIGNED → CONTRACT_EFFECTIVE: jobs/healthInsurance/…:146, daily"), not to the repository.

Findings only: collection, environment variable and package NAMES, UPPER_CASE state values, a file's path relative to its repository, a line number, the branch and commit. Never a line of code, a value from the environment, or a checkout's absolute path.

Kubernetes · Infrastructure

What runs in each Kubernetes cluster: its namespaces, the Deployments, StatefulSets and DaemonSets in them and the images their containers run (joined to the ECR and Artifact Registry images the cloud connectors map), the Services that select each workload, the Ingresses that route a hostname to a Service (tied to the DNS connector's hostnames), and the NAMES of the ConfigMaps and Secrets each workload reads (env, envFrom, volumes) or an Ingress serves TLS from. A GKE context lands on the Google Cloud connector's cluster. Flags a workload reading a ConfigMap or Secret its namespace does not have, an Ingress path to a missing Service, and a Service that selects nothing.

Names, namespaces, labels, images, replica counts, ports, Ingress hosts and paths, environment variable NAMES and the ConfigMap and Secret NAMES (and a Secret's type) they read. Never an env value, a ConfigMap's or Secret's data (both are listed as name columns only, so the data is never fetched), an annotation (the last-applied manifest holds env values), or anything from the kubeconfig but the server, cluster, namespace and user names.

Sentry · Infrastructure

Which services are alive, and how loudly they fail. Every Sentry project as a system, with its platform, teams and client key labels; its newest releases and deploys; its error and transaction volumes over 14 days (by day, with what Sentry filtered or dropped over quota) and its unresolved issue count. A project monitors the repository its release commits name (declared) and the one service or function that repository deploys (derived); liveness (reporting, quiet, silent, never reported) and freshness (the newest release and deploy) are written, observed, on the project and on what it monitors, beside Cairn's task activity. A project only NAMED like a repository or a service (its slug, a client key label, a release's package name) is a proposal in the queue, never an edge.

Organisation, project, team and client key NAMES; release versions, dates and counts, the repository name and sha of a release's last commit; deploy environments and times; event COUNTS by day and outcome; unresolved issue COUNTS. Never an event, stack trace, issue title, message, breadcrumb, tag value, user, commit message or author, DSN or key.

Terraform (state and plans) · Infrastructure

The infrastructure the company declares: every resource in each Terraform state (and in a plan, what apply would create, change or destroy), with its address, type and provider, which stack declares it and which repository holds that stack, and what each resource depends on or references. A resource the AWS connector also lists (a Lambda, an ECS service or cluster, an App Runner service, an ECR repository, a bucket, an RDS or DocumentDB database, a DynamoDB table, an SSM parameter or Secrets Manager secret, an SQS queue or Kinesis stream) lands on the same entity as the live one: Terraform is the declared layer, AWS the observed one, and each resource says whether AWS has been seen running it. Route 53 and Cloudflare A, AAAA and CNAME records land on the DNS connector's hostnames.

Resource addresses, types, provider names and an allowlist of identifying attributes (id, ARN, name, bucket, function, service and cluster names, engine, repository URL, record type and hostname), the dependencies between resources, a plan's actions, the repository and path of each stack. Never an attribute Terraform marks sensitive or that looks like a credential, anything of a random_*, tls_* or access-key resource, an output, a variable, the backend configuration, or an absolute path on this machine.

RabbitMQ · Infrastructure

The asynchronous routes between services: a broker's vhosts, exchanges and queues (depth, consumers, dead-letter exchange), the bindings that route one into the other, and which service consumes each queue and — when the broker keeps detailed rates — publishes into each exchange. A client is named by the connection name it gives (or its login) and joined to the service of that name another connector found; several candidates are proposals, never guesses.

Vhost, exchange, queue and binding names, routing keys, the routing arguments (dead-letter exchange and key, TTL, length limits, queue type), message and consumer COUNTS, and each client's connection name, login, library and — only when nothing names it — its address. Never a message, a header, a payload, a password or the URL.

Redis · Databases

Which key namespaces a Redis server holds — prefixes such as session: or cache:quotes:, from a capped SCAN of key NAMES reduced on this machine, with their counts, estimates and key types — the BullMQ queues in it, the pub/sub channels in use, and the clients that connect under a service's name. Which service owns which namespace is offered as a proposal (the prefix names it, or it is the database's only named client).

Namespace PREFIXES only (a key's last part and any part that looks like an id, an email or a token are cut on this machine), counts, key types, database sizes, server version and memory policy, and client names, databases and libraries. Never a key, a value, a client's address, a password or the URL.

Find a sourceBusiness area

92 source families

SE 44 83Grounding and drift

Every element points at what implements it, and notices when that moves.

A transition, a process step or a funnel stage is grounded in the code, data or infrastructure behind it, with the file and the line. When a re-scan finds the code has moved away from what the business layer says, the element is flagged as drifted instead of quietly going wrong.

Grounded: Each element links down to a job, a collection, a workflow or a document, with file:line where the code shows one.
Drift: A state the business layer names that the code no longer sets, or a transition nothing covers, is flagged after every update.
Measured as grounding: Coverage is how much of the business is tied to its systems, not how many things were filed somewhere.

Acme, grounded

lifecycle transitions21/26
process steps17/19
journey stages9/11
automations9/10

The twelve questions8 grounded2 answered1 drifted1 unanswered

01Business modelgrounded
02Actorsgrounded
03Partnersgrounded
04Leads per siteanswered
05Sales processgrounded
06Core lifecyclegrounded
07Internal processesgrounded
08Contentunanswered
09Automationsgrounded
10Data flowsdrifted
11Key metricsgrounded
12Pain pointsanswered

What your agent works through, worst first. The same scorecard the CLI prints.

SE 45 82The system map

Under the business, the map of what runs.

The system layer stays one click away, under System in the app: a survey sheet at three scales, from the whole company down to one service and what it touches.

The company
Areas as territories, sized by what lives in them.
One area
Its products and features, with neighbours at the border.
One thing
What points at it, and what it points at.

SE 46 81Trig and Cairn

One question decides where a fact lives.

Cairn is where your agents keep their tasks, their notes and what they learned doing the work. See Cairn

Could a re-scan rediscover it?

Yes Trig

Derived and replaceable, and it must be replaced or it lies.

invoices lives in Postgres, has a unique index on (venue_id, number), and is read from three call sites.

No Cairn

Earned once by someone doing the work. Nothing regenerates it.

“We tried caching menus for an hour and prices went stale.”

Once Cairn is connected, Trig reads it on every update: what agents learned arrives as contributed facts.

SE 47 80For your agent

Claude Code, Codex, OpenClaw or Hermes runs Trig through one skill and one CLI, the setup included. There is no model inside Trig: your agent is the one that reads and writes.

$ trig lifecycle "Venue lifecycle"

the lifecycle above, as your agent reads it

SE 48 79The cloud

Some things one company cannot learn. That is what the cloud is for.

Two connectors find a registry image called billing-prod and a repository called billing. One thing or two? Self-hosted, the resolver has your company’s past decisions to go on. The cloud adds priors learned from what was confirmed and rejected across every tenant, so it can answer with a number: most companies where two names meet in this shape confirmed them as one.

Self-hosting is not a crippled tier: it is the whole product, and it always will be.
The connectors and the resolver stay whole. The priors are something your resolver may call or ignore.

What a decision record contains. All of it.

type_pair: two entity types
source_pair: which two connectors
evidence_kinds: which signals matched
evidence_count: how many
stem_distance: an integer
env_suffix_differs: a boolean
name_length_bucket: a bucket
subject_count: how many things
confidence: what we offered
outcome: confirmed or rejected

Numbers and enums, never a name or a string from your company. assertAnonymous() is the only writer and throws rather than warns, because a corpus is mined once and nothing can be cleaned out of it afterwards.

Two ways to run it

Self-hostedFair-code

FreeFor your own work, with no seat count.

The whole product: local connectors, the business layer, the CLI, the skill and the web app
Grounding, drift and provenance on every fact
You run the upgrades, the backups and the uptime

Quickstart, with the source release

CloudPrivate beta

Not for sale yetNo signup, no billing, no card on file.

Priors on entity resolution, learned across every tenant
A confidence your resolver may call or ignore
What you give back is numbers and enums

Coming soon

SE 49 78Source release, coming soon

The source is coming. It is not public yet.

Trig will be released as fair-code: source-available, and self-hostable end to end. Today it runs as a private beta and the repository is private with it. No date has been set, so this page does not give one.

Private beta

Trig Cloud is in private beta.

We are onboarding the first teams directly. Self-serve workspaces and plans are coming; today there is nothing to buy. If you already have an account, the door is below.

Subscribe, coming soonExisting customer sign in

Your agents understand how your company works.

Ask about the business, not the servers.

How does a venue go from signed to live?

Where do our leads come from?

Who owns billing?

What runs by itself?

Where does the funnel leak?

Connectors derive. Your agent writes. People settle only the rest.

Connectors run on your machine

Every fact says how it is known

Your agent writes the business layer

People see only what it could not settle

One company. Many sources.

Aircall (campaign aggregate stocks)

Airtable (approved base-container visibility)

Amplitude (daily event aggregates)

App Store Connect (app container total)

Asana project task-count aggregates

AWS

Azure

BambooHR compensation-group status counts

BigQuery (dataset structure counts)

Bitbucket

Brevo daily transactional aggregates

Buddy

Cairn

ClickUp (workspace seat stocks)

Code (local checkouts)

Confluence Cloud

Crisp (aggregate CRM profile stock)

Customer.io

Every element points at what implements it, and notices when that moves.

Under the business, the map of what runs.

The company

One area

One thing

One question decides where a fact lives.

Some things one company cannot learn. That is what the cloud is for.

Two ways to run it

Trig Cloud is in private beta.