Prolytics OS Agent Analysis Reference

Prolytics OS Agent Analysis Reference

Corpus type: Internal analysis reference. This file consolidates the current product documentation into one labeled MDX source for agents and reviewers. The individual documentation pages remain the user-facing source of truth.

Corpus manifest

This reference combines the following source documents:

1. content/docs/introduction.mdx: product definition, operating loop, evidence model, security, storage, privacy, and starting point.
2. content/docs/manual.mdx: Health, Watch, Engine, and investigation recipes.
3. content/docs/connectors/index.mdx: connector selection and multi-source behavior.
4. content/docs/connectors/posthog.mdx: PostHog setup, permissions, and readiness.
5. content/docs/connectors/stripe.mdx: Stripe setup, permission paths, and billing readiness.
6. content/docs/connectors/sentry.mdx: Sentry setup, permissions, and reliability readiness.
7. content/docs/capabilities.mdx: capability framing, source-specific capabilities, combinations, readiness, and limits.
8. src/lib/marketing/source-capabilities.ts: the canonical 29-entry marketing capability registry, reproduced in the capability inventory below.

Agent reading rules

• Treat deterministic calculations, source records, explicit requirements, and readiness states as authoritative.
• Treat generated language as a summary or explanation of supplied evidence, not as the source of a metric.
• Keep missing, stale, conflicting, unavailable, or insufficient evidence visible.
• Do not turn timing into causation.
• Do not assume records from different providers belong to the same user or account without sufficient identity coverage.
• Use the narrowest workflow that can answer the question: Fetch, Correlate, or Investigate.
• Use Watch to follow the business condition after an action; completing a task is not evidence of recovery.
• Prolytics uses read-only provider connections and does not alter provider records.

---

SOURCE 01: Introduction

What is Prolytics OS?

Revenue moves in Stripe. Product behaviour changes in PostHog. Reliability pressure appears in Sentry. Each system shows its part of the story, but someone still has to decide what matters and connect the evidence.

Prolytics OS gives that work one operating loop. Health shows what changed and what deserves attention. Engine investigates what the available evidence can explain. Watch keeps the original condition visible after the team acts, so the team can judge whether the outcome improved.

OS is not another fixed dashboard or a chatbot that explains one chart at a time. It keeps the metric, timeframe, evidence, uncertainty, investigation, and later outcome connected.

The investigation loop

Start with the business condition: Health

Open Health when you need to know what changed and where to look first. The main briefing connects the most important movement across the selected reporting window. Billing, Usage, and Reliability then show where pressure is developing and keep every headline attached to the metrics behind it.

Needs Attention keeps the review focused. Health Findings preserve important detected issues. Health Signals capture supported metrics that moved materially against an established baseline. If both describe the same movement, Health suppresses the duplicate.

Do not scan every metric looking for a story. Start with the movement most likely to change a decision, then open its evidence.

Establish what the evidence supports: Engine

Take a question into Engine when the cause is unclear, a hypothesis needs testing, or a number needs confirmation. Choose the narrowest mode that can answer it:

• Fetch retrieves a known metric or fact.
• Correlate tests whether specified signals moved together in a defined period.
• Investigate examines an unclear symptom and ranks the explanations the evidence supports.

Engine keeps its tool activity, sources, calculations, visualisations, limitations, and final answer inside the investigation. Missing evidence stays missing. Conflicting evidence stays visible. A plausible explanation is not presented as a proven cause.

Watch what happens next: Watch

Closing a ticket, deploying a fix, or changing a campaign does not prove that the business problem recovered. Watch keeps the original condition connected to later observations so the team can see whether it improved, stayed flat, or became worse.

Resolve a Watch when the evidence supports recovery. Stop it when continued monitoring is no longer useful but the evidence does not support that claim. Watch tracks the outcome, not the action itself.

Evidence before confidence

Prolytics calculates metrics before generated language is requested. The model can summarise, prioritise, and explain the supplied facts. It does not become the source of truth for the number.

History and coverage determine what OS can support. If a metric needs more history, Health shows Building. If a source has no usable records for the selected period, it shows No data. If a connection cannot be trusted, the affected evidence is marked unavailable instead of becoming zero.

One connected source is enough to begin. Additional sources create more places to look and can strengthen a comparison. They do not give OS permission to treat unrelated records as the same customer or turn timing into causation.

More data is useful. More data does not make a weak claim true.

Architecture, security, and access

OS acts as a read-only orchestration layer over the systems where operational data already lives. Each connector requests only the permissions needed to retrieve and analyse supported evidence.

Prolytics cannot alter connected provider data, change subscriptions in a Stripe account, issue refunds, deploy code, or resolve incidents in connected tools. Actions that affect business systems remain under the customer's control.

Data storage and PII scrubbing

Prolytics does not create a second unrestricted warehouse containing everything in source systems. It stores the service records needed to operate OS. These include connection state, selected provider snapshots and source identifiers, derived metrics, Health Findings, Health Signals, Watches, prompts, evidence packs, AI outputs, and investigation history.

Rebuildable caches and snapshots are pruned under the applicable retention policy. Raw Stripe webhook payloads are redacted after 180 days. Canonical billing records needed for product operation, tax, legal, and audit purposes are retained.

Engine applies automated redaction to supported sensitive patterns before prompts and tool evidence enter model processing. These patterns include email addresses, phone numbers, IP addresses, and credentials. No automated scrubber can guarantee that every identifier will be detected, so OS also limits the sources, tools, and evidence available to each workflow.

We do not train on your data

Prolytics does not train on customer data. Customer data is used to operate the service, answer requests, preserve paid investigation history, support customers, and protect the platform.

Production prompts, evidence packs, and AI outputs are not added to model-training or evaluation datasets unless the customer explicitly authorises that use.

Prolytics improves the investigation system itself: how it selects tools, evaluates evidence, performs diagnostic analysis, and communicates uncertainty. It does not fine-tune models on raw event data or teach one customer's operating patterns to another.

Where to begin

Use Health when you need to know what changed. Use Engine when you need a number, want to test a hypothesis, or need to investigate an unclear symptom. Use Watch when the condition matters after the current review.

If new to OS, connect the source that holds the evidence for the first question. Then run the five-minute Health review in the Operator's Manual. Every source does not need to be connected before the system becomes useful.

---

SOURCE 02: Operator's Manual

Use OS as one operating loop

Prolytics works best when each part of the system has one job. Health decides what deserves attention. Engine establishes what the available evidence can explain. Watch follows the business condition after the team acts.

Do not begin every question with a deep investigation. Use the narrowest workflow that can change the next decision. Confirm the number when the number is enough. Investigate when the explanation changes what you do. Start a Watch when the outcome will still matter tomorrow.

Health Manual

Health gives a fast way to understand the current business condition without scanning every dashboard for a story. It brings Billing, Usage, and Reliability movement into one review, then separates evidence that needs attention from metrics that can wait.

Run a five-minute Health review

Begin at the top of the page and work down:

1. Choose the reporting window that matches the decision.
2. Read the main briefing to understand the strongest movement.
3. Scan Billing, Usage, and Reliability for where pressure is developing.
4. Work Needs Attention before opening every chart.
5. Review the evidence behind an item before deciding what it means.
6. Investigate when the cause changes the next action. Start a Watch when the condition matters beyond this review.

The goal is not to explain every movement. The goal is to find the movement most likely to change a decision and establish what the evidence supports.

Choose the window that matches the decision

Health supports 7D, 14D, 30D, MTD, and QTD reporting windows. A shorter window is useful for recent operational movement. A longer window is better when the decision depends on a broader pattern.

Changing the selector recomputes metrics, comparison periods, charts, tables, and briefings for that window. Health Findings, Health Signals, and Watches remain persistent. Changing the window does not erase unfinished review work or rewrite Watch history.

Always check the exact dates and comparison period before acting. 7D versus the preceding seven days answers a different question from month to date versus the equivalent prior period.

Use the briefings to decide where to look

The main Intelligent Summary connects the most important facts in the selected window. Billing, Usage, and Reliability each provide a focused briefing for their own evidence. Use these headlines to orient the review, then open the metrics behind the claim.

The model does not calculate metrics. Health computes a bounded fact set first, and generated language must stay grounded in those facts. If generation is unavailable or the response fails validation, Health keeps a deterministic briefing in place.

A useful headline tells you where to look. It does not turn an incomplete explanation into a fact.

Work Needs Attention before scanning everything

Needs Attention is a decision queue, not a list of every metric that moved. Unread work appears first, with newer items prioritised inside the same read state. Opening an item marks it read. It can be marked unread again when it still needs review.

Open an item to inspect its source, timeframe, impact, trend, evidence, limitations, and recommended next step. Use the Full Health Feed when search, filters, or a longer review history are needed. Read state controls attention. It does not mean the underlying condition recovered.

Know the difference between Findings and Signals

Health Findings are meaningful detected issues promoted for review. They preserve the source, timing, impact, evidence, review state, and lifecycle context needed to decide what happens next.

Health Signals show when a supported metric moves materially against its established baseline. Signals persist across refreshes until the metric recovers or the Signal is otherwise handled. If a Health Finding already covers the same movement, Health suppresses the duplicate Signal.

Findings tell the team what deserves review. Signals tell the team that a supported metric moved outside its expected range. Neither proves that a particular event caused the movement or that the same users or accounts were affected.

Read each Health domain as a business question

• Billing Health answers where revenue pressure is coming from. Use it to inspect recurring revenue movement, retention when enough monthly history exists, failed payments, refunds, and subscription changes from Stripe.
• Usage Health answers whether people are reaching and repeating value. Use it to review activation, active-user depth, daily activity, top pages, and product paths from PostHog.
• Reliability Health answers whether technical pressure may be affecting customers. Use it to inspect error pressure, affected users when available, transaction latency, and issue movement from Sentry.

Open detail views beneath each domain when the summary changes a decision. Charts and tables provide the comparison behind the headline. Each source remains useful on its own. Connecting more sources adds context, but it does not make an unsupported cross-source conclusion trustworthy.

Treat readiness states as instructions

Building means Health can read the source but does not yet have enough verified history or prerequisites to calculate the metric safely. Do not troubleshoot a metric that is still earning the right to make a comparison.

• Connect means the required source is not connected.
• Building means history or another prerequisite is incomplete.
• No data means the source is reachable but the selected window has no usable records.
• Unavailable means the source or calculation cannot be trusted right now.
• Ready means the metric has enough verified evidence to display.

Some metrics need more history than others. DAU/MAU needs at least 30 days of product activity. NRR needs completed monthly subscription history. Window comparisons need a complete preceding period. Health Signals need enough comparable windows to establish a baseline.

Health shows readiness instead of filling a gap with NaN, zero, or invented data.

Decide whether to investigate, wait, or watch

Use Engine when a movement matters but the cause is unclear, a hypothesis needs testing, or the next action depends on the explanation. Keep the metric, timeframe, source, and comparison explicit when continuing from Health.

Choose Wait for evidence when missing history or coverage is the only responsible next step. Start a Watch when the condition matters beyond the current review and later movement should remain connected to the original evidence.

The best next step is often smaller than a full investigation. Do not spend three credits proving a number that Fetch can establish for a quarter credit.

Understand what the evidence can prove

Level 1 is source-level or timing evidence without verified identity linkage. It can show that a metric moved against its baseline or that supported movements occurred around the same period. It cannot confirm that the same users or accounts were involved.

Level 2 is available for specific claims when identity coverage supports linked analysis. This may include product-to-revenue attribution, account health, or reliability impact on known customers. Availability is claim-specific. One supported Level 2 claim does not make every cross-source conclusion valid.

Start with the source needed for the question in front of the team. Improve semantic mappings and identity coverage only when the desired claim depends on them. More data does not make a weak claim true.

Watch Manual

Shipping a fix closes the task. It does not prove that checkout recovered, churn slowed, or customers returned. Watch keeps the original condition connected to later observations so the team can judge the outcome.

Start a Watch when the condition will matter later

Start from a Health Finding, Health Signal, or supported metric observation when continued monitoring could change a later decision. This is useful after the team acts, while a condition is still developing, or when a meaningful threshold crossing requires attention.

Use Engine first when the cause changes what action to take. A Watch can still begin before the cause is settled when losing the original condition would make later recovery harder to judge.

Compare the original condition with current evidence

Watch preserves the original value, later observations, threshold information when available, event history, current direction, and supporting evidence. The original condition stays fixed while current evidence updates.

Open Watch detail when the condition moves. Compare original and current values, inspect observation history, and check whether the movement crossed a meaningful threshold. Small changes do not create a Moved event simply because the number is different.

Use the inbox state correctly

• Moved means a meaningful threshold crossing created a new inbox event.
• New means the Watch was recently added and has not been reviewed.
• Seen means it has been read and has no newer event.
• Resolved means a user recorded that the evidence supports recovery.

Read state manages attention. It does not describe the business condition. A Seen Watch can still be deteriorating, and a closed task can still have an unresolved Watch.

Resolve only when the condition recovered

Choose Resolve when available evidence supports recovery. Choose Stop when continued monitoring is no longer useful but the evidence does not support a recovery claim. Both actions end active monitoring and preserve captured history.

If the condition returns, review the new Finding or Signal and begin a new Watch when continued monitoring matters. Do not rewrite the previous Watch to make the new movement fit an old recovery claim.

Watch can show that a metric improved, deteriorated, or crossed a threshold after monitoring began. It cannot prove that a release, campaign, or intervention caused the result.

A task tracker can tell the team that work was completed. Watch helps show what happened to the business condition afterward.

Engine Manual

Engine is where Prolytics moves from movement to explanation. Use it for a specific number, a hypothesis that needs testing, or a symptom with several plausible causes.

Engine does not manufacture certainty. It returns the strongest conclusion the available evidence can support and keeps the limits of that conclusion visible.

Choose the narrowest useful mode

The three modes are not stages that must be completed in order. Choose the least expensive mode capable of answering the question.

Fetch

Use Fetch when the number itself is the answer. It retrieves a specific metric or fact from the relevant source without expanding the request into a broader investigation.

Prompt pattern: Show me [metric] for [timeframe], compared with [baseline if needed].

Examples: “What is active MRR right now?” and “How many users completed checkout in the last seven days?” Fetch costs 0.25 credits.

Correlate

Use Correlate when there is already a possible explanation and the team wants to test whether specified signals moved together in the same period.

Prompt pattern: Did [signal A] move with [signal B] during [timeframe]?

Examples: “Did the checkout error spike move with the drop in completed payments?” and “Did activation decline while onboarding latency increased?” Correlation can strengthen or weaken a hypothesis. It cannot prove that one signal caused the other. Correlate costs 1 credit.

Investigate

Use Investigate when the symptom is known but several explanations remain possible. Engine tests supported explanations across available evidence and ranks what it can establish.

Prompt pattern: [Symptom] changed during [timeframe]. What evidence best explains it?

Examples: “What is driving the decline in MRR this month?” and “What best explains the increase in churn among recently activated accounts?” Investigate does not guarantee one root cause. It separates supported explanations from unresolved ones. Investigate costs 3 credits.

Ask a question Engine can investigate

Strong questions establish the metric or symptom, timeframe, and any useful place to begin. Exact event names, property keys, or provider schemas are not required. Use the language the team already uses and avoid adding a suspected cause only to make the prompt sound precise.

Weak prompt: “Why is revenue down?” It has no defined metric, period, or comparison.

Strong prompt: “MRR declined over the last 30 days. Break down new revenue, expansion, contraction, churn, and failed-payment movement, then identify the largest contributor.” It defines the outcome and period without telling Engine what conclusion to reach.

Read Staging before trusting the Answer

The Staging tab shows the investigation as it develops. Use it to see reasoning stages, tools, sources, and evidence Engine accessed. The Answer tab contains the conclusion and any supported metric cards, charts, or evidence tables.

Check that Engine used the intended source and timeframe. Inspect missing or conflicting evidence before accepting the conclusion. Empty or unsupported visualisations are omitted rather than presented as proof.

Follow-up questions remain inside the same investigation, and earlier turns stay available in history. Use a follow-up to narrow an unresolved point, compare another period, or challenge an assumption. Stop the run when evidence is already sufficient for the next decision.

Continue from Health without losing the question

Start with the metric, timeframe, comparison, and evidence already visible in Health. A Health Finding can provide useful context, but the initial question should still be checked before running it. Add a missing timeframe or metric explicitly.

Use Fetch when only the number needs confirmation. Use Correlate when there is a specific relationship to test. Use Investigate when the symptom is clear but several explanations remain plausible.

Challenge the answer

Before acting, ask:

• Did Engine use the correct timeframe and comparison?
• Did it access the source that holds the required evidence?
• Is the claim based on linked users or accounts, or only timing?
• What evidence was unavailable or inconsistent?
• Is the answer describing correlation or claiming causation?
• Would remaining uncertainty change the decision?

The investigation remains in history with its evidence and conversation attached. When sources disagree, Engine does not force them into one confident explanation. Missing evidence is not permission to guess.

Know when to stop

The goal is not to eliminate every possible explanation. Stop when the evidence is strong enough to choose the next action, or when remaining uncertainty cannot be resolved with connected evidence.

Once the team acts, the question changes. Engine establishes the strongest explanation the evidence supports. Watch follows what happened to the business condition afterward.

Investigation recipes

These recipes show how the operating loop works on questions that usually span more than one dashboard. Adapt the metric and period to the business rather than copying a suspected cause into the prompt.

What is driving the MRR decline?

Use Fetch first if only MRR and its comparison need confirmation. Use Investigate when the composition changes the next action:

MRR declined this month. Break down new revenue, expansion, contraction, churn, and failed-payment movement, then identify the largest supported contributor.

Inspect currency, period boundaries, and missing subscription history before accepting the result. Watch the largest contributor when later movement will determine whether the response worked.

Did a reliability incident affect customers?

Begin with the error or latency movement in Reliability Health. Use Correlate when there is a specific customer outcome to compare:

Did checkout error pressure move with completed checkout decline during the incident window?

Timing can support the hypothesis without proving impact on the same customers. Look for identity coverage before making a user-level or account-level claim.

Why did checkout conversion fall?

Start in Health and confirm the reporting window, conversion movement, and any Reliability or Billing pressure in the same period. If the cause is unclear, use Investigate:

Checkout completion declined over the last 14 days. Compare product abandonment, checkout errors, and payment failures, then rank the explanations the evidence supports.

Check whether Engine has identity-linked evidence or only aligned timing. After the team acts, start a Watch from the checkout condition and judge recovery against the original value.

Are users reaching value and returning?

Review activation, daily activity, and usage depth in Usage Health. If a metric is Building, wait for the required history instead of treating the gap as a decline. When activation has moved and several paths may explain it, use Investigate:

Activation declined over the last 30 days. Identify where users stopped progressing and which supported product paths changed most.

Confirm that the activation event represents the outcome the team considers meaningful. A clean query cannot rescue an incorrect product definition.

---

SOURCE 03: Connectors overview

Start with the evidence needed

Every source does not need to be connected before Prolytics becomes useful. Begin with the system that holds the evidence for the first question, then add another source when the investigation crosses between them.

• Connect PostHog to understand activation, engagement, product paths, and where users stop progressing.
• Connect Stripe to understand recurring revenue, subscriptions, failed payments, expansion, contraction, and churn.
• Connect Sentry to understand errors, issue pressure, affected users when available, and application performance.

Each source powers its own Health domain and can support Engine questions on its own. More sources create a wider evidence set. They do not turn timing into causation or make unrelated users the same person.

Connect for the question in front of you

If checkout conversion fell, start with PostHog. Add Sentry when reliability may be involved and Stripe when payment completion matters. If MRR changed, begin with Stripe and add product or reliability evidence only when the explanation depends on what happened earlier.

Keep setup proportional to the decision. Connect enough evidence to answer the question well, not every source simply because it exists.

Understand what multiple sources add

Multiple sources let OS compare supported movement across product behaviour, reliability, and billing. This can help answer whether checkout abandonment moved with application errors, whether failed payments contributed to revenue pressure, or whether activation changed before contraction increased.

Aligned movement can strengthen or weaken a hypothesis. It does not prove that one event caused another. User-level or account-level claims also require enough identity coverage to link records safely.

More sources provide more evidence. They do not make an unsupported conclusion trustworthy.

Connected does not mean every metric is ready

A connection may be healthy while a specific metric still needs history, a confirmed event definition, or stronger identity coverage. Health shows how that limitation affects the metric instead of hiding it behind zero.

If credentials expire, permissions change, or a provider cannot be reached, Connections marks the affected source as requiring attention. Other connected sources remain available. Reconnect or update permissions, then allow affected metrics to refresh before using them in a decision.

Read-only by design

OS uses read-only access to connected providers. It cannot change product events, modify subscriptions in Stripe, issue refunds, delete provider records, or resolve incidents inside those systems.

---

SOURCE 04: PostHog connector

Purpose

PostHog gives Health and Engine the product evidence needed to understand whether users reach value, return, deepen usage, and continue through important journeys. Connect it when the question begins with activation, engagement, adoption, or conversion.

Questions PostHog helps answer

• Where do users stop during onboarding, activation, or checkout?
• Are signups becoming active users, or only increasing traffic?
• Which pages, events, and paths changed during the selected period?
• Did product movement align with reliability or billing pressure?

PostHog can answer product questions on its own. Cross-source claims become possible only when the required records can be linked safely.

Setup

1. In PostHog, open Settings > General and copy the Project ID.
2. Copy the project host, usually https://us.posthog.com or https://eu.posthog.com.
3. Open Settings > Personal API Keys and create a key for the selected project.
4. Grant the required read access listed below.
5. Enter the host, Project ID, and personal API key in Prolytics Connections.

Prolytics currently supports one PostHog project per workspace.

Required access

• Project read validates that the selected project exists and is accessible.
• Event definitions read discovers event names used by the product.
• Property definitions read discovers metadata available on events and people.
• Query run retrieves events and aggregate metrics required by Health and Engine.
• Persons read supports identity coverage and user-level questions when the data allows them.

Cohort and path-query access is optional in the current release. Granting it can improve supported cohort and journey analysis, but a missing optional permission does not block the core connection.

After connection

OS inspects available event and property definitions, then begins preparing product metrics the data can support. The team may be asked to confirm which events represent activation or another important outcome. OS does not assume these definitions because the same event name can mean something different in every product.

Some metrics become useful immediately. Others need a confirmed definition or enough history to establish a comparison. If a trusted event later disappears or changes meaning, the affected metric is marked untrusted rather than presented as a real decline.

---

SOURCE 05: Stripe connector

Purpose

Stripe gives Health and Engine the billing evidence needed to explain how recurring revenue moved and which subscription or payment changes contributed. Connect it when the question begins with MRR, retention, churn, expansion, contraction, or failed payments.

Questions Stripe helps answer

• What is driving MRR movement?
• Are failed payments creating revenue pressure?
• Which subscriptions, plans, or customer groups contributed most to growth or loss?
• Did product or reliability movement appear before the billing outcome?

Stripe metrics remain useful without another source. Product-to-revenue and reliability-to-revenue claims require enough identity coverage to connect the records safely.

Setup

1. In Stripe, open Developers > API keys.
2. Select Create restricted key.
3. Choose Providing this key to a third-party application.
4. Grant Read access to the resources listed below.
5. Enter the restricted key in Prolytics Connections.

Do not provide a Stripe Secret Key. Prolytics does not require write access to the connected Stripe account.

Required access: Path A, Quick Start

The recommended path is broad read-only access to account data so Engine can access data required for supported revenue analysis. Write access is never required.

• Core allows Engine to analyse failed transactions and declined charges, and map Stripe billing entities back to product users or accounts.
• Billing allows Engine to calculate MRR, ARR, and churn from active subscriptions and the pricing catalog.

Required access: Path B, Strict Compliance

If an organisation requires absolute least-privilege scoping, leave parent categories as None and manually enable Read access for these endpoints:

Core resources

• Charges and Refunds: Required at connection time and used to query payment history and run charge searches.
• Customers: Required at connection time for validation checks and used to look up customer records during investigations.

Billing resources

• Subscriptions: Used to calculate MRR and ARR by reading active subscriptions.
• Invoices: Used to pull invoice history for a customer when investigating billing questions.
• Prices: Used during discovery to build the pricing catalog, including product names, price IDs, and billing intervals.
• Products: Required alongside Prices to expand price objects to include the parent product name; without it, pricing tiers have no names.

After connection

OS begins preparing revenue, subscription, and payment metrics supported by Stripe data. Calculations use the account's supported default currency. Amounts from other currencies are not silently combined into the same total, and zero-decimal currencies are handled using their correct units.

Stripe metrics can work independently. Connecting billing outcomes to PostHog behaviour or Sentry impact also depends on whether the same customer or account can be identified across those sources.

Missing identity coverage limits only cross-source comparisons. Stripe revenue, subscription, and payment analysis remain available.

---

SOURCE 06: Sentry connector

Purpose

Sentry gives Health and Engine the reliability evidence needed to understand whether errors, issue pressure, or transaction latency may be affecting customer behaviour. Connect it when the question begins with an incident, error spike, or slow transaction.

Questions Sentry helps answer

• Which issues or transactions created the most pressure?
• Did reliability movement align with a product or billing decline?
• How many users were affected when usable user context exists?

Sentry can support general reliability analysis without identity data. User-level and account-level impact claims require usable identifiers on the relevant events.

Setup

1. In Sentry, open Settings > Developer Settings.
2. Copy the Organization Slug and Project Slug.
3. Create an internal integration or personal token with read-only access.
4. Grant organisation, project, issue, and event read access.
5. Enter the slugs and token in Prolytics Connections.

Why this access is needed

• Organization read validates the workspace slug and lets OS reach the selected project.
• Project read confirms the exact project and its available data.
• Issue and event read supports error pressure, affected-user analysis, and failure timelines.

OS validates these capabilities before saving the connection. If a required permission is missing, Connections identifies the affected access instead of accepting a source that cannot support its claims.

After connection

OS begins preparing errors, issues, affected-user evidence, and transaction latency available in the selected project. Latency comparisons require transaction data. Affected-user analysis requires user context on relevant events.

Missing user context limits identity-dependent conclusions. General reliability movement remains available, and Health keeps the limitation visible.

---

SOURCE 07: Capability guide and source-selection model

Start with the question, not every connector

Start with the system that owns the evidence for the first decision. Add another source when the question crosses from product behaviour into reliability or billing.

One source can establish a useful fact. More sources can strengthen an investigation. They do not turn timing into causation or make unrelated records belong to the same customer.

Source-specific capability summary

PostHog

Connect PostHog when the question begins with activation, engagement, retention, conversion, or a product journey. OS uses event and property definitions to prepare product evidence that Health and Engine can support.

PostHog event names are not universal business definitions. Confirm the events that represent activation and value. If a definition is missing or changes, the affected metric stays in setup or becomes unavailable instead of presenting a misleading decline.

User-level and account-level conclusions depend on identity coverage. General product movement can still be useful without it.

Stripe

Connect Stripe when the question begins with MRR, subscriptions, retention, churn, expansion, contraction, refunds, or failed payments. OS keeps currency, billing interval, and reporting-window boundaries attached to calculations.

Current MRR can become useful quickly. NRR, cohort retention, and efficiency measures need completed historical periods. Until a comparison is earned, Health shows Building rather than inventing a value from incomplete records.

Stripe remains the source of truth for billing evidence. Prolytics reads the connected account but cannot alter subscriptions, issue refunds, or change customer records.

Sentry

Connect Sentry when the question begins with an incident, release, error spike, affected users, or a slow transaction. OS uses issues, events, releases, environments, and performance evidence to show what changed and how widely pressure reached.

Sentry can support a general reliability conclusion without user identity. Claims about the same users or accounts require usable identifiers on the events involved. If coverage is missing, OS keeps the conclusion at the reliability or timing level.

What another source adds

Use Correlate when there is already a relationship to test. Use Investigate when several explanations remain plausible. Engine ranks what connected evidence supports and keeps conflicting or missing evidence visible.

How OS turns source data into a decision

1. Health calculates supported metrics for the selected reporting window and keeps Billing, Usage, and Reliability evidence in one review.
2. Intelligent briefings summarise a bounded fact set. The model explains calculated evidence; it does not create the metric.
3. Health Findings preserve meaningful detected issues that deserve review.
4. Health Signals record supported metrics that moved materially against an established baseline. A duplicate Signal is suppressed when a Finding already covers the same movement.
5. Engine fetches facts, tests specified relationships, or investigates several supported explanations.
6. Watch keeps the original condition connected to later observations so the team can judge whether it recovered.

Readiness states

Missing evidence never becomes zero. Sparse history never becomes NaN. If OS cannot support a requested conclusion, it should say what is missing and stop there.

Where Prolytics stops

Prolytics uses read-only connections. It cannot change provider records, deploy code, alter a subscription, issue a refund, or resolve an incident.

It does not assume records from different sources belong to the same person or account. Identity-dependent claims require enough coverage to link them safely. Correlation remains correlation unless the evidence supports a stronger conclusion.

---

SOURCE 08: Canonical 29-capability inventory

The following inventory reproduces the 29 entries in marketingSourceCapabilities. Each row is a discrete capability record with a stable ID, required source set, expected outcome, product surfaces, and readiness requirement.

Capability interpretation rules

• A capability is available only when every required source and the row's stated evidence requirement are satisfied.
• A source combination expands the evidence available to a claim; it does not automatically increase certainty.
• A single-source capability can remain useful without identity linkage when it does not make a user-level or account-level claim.
• User-level and account-level claims require safe identity linkage across the relevant sources.
• Timing alignment is not causation.
• If a capability cannot be supported, the correct state is a visible limitation such as Connect, Building, No data, or Unavailable, not zero or a fabricated result.

---

SOURCE 09: Cross-document operating contract

Source ownership

Product workflow

1. Connect the source that owns the evidence for the first decision.
2. Establish the reporting window and comparison period.
3. Use Health to identify meaningful movement and review the evidence.
4. Use Fetch when a number is sufficient.
5. Use Correlate when a defined relationship needs testing.
6. Use Investigate when several explanations remain plausible.
7. Keep limitations, missing evidence, and identity coverage visible.
8. Start a Watch when the business condition matters after the current action.
9. Resolve only when evidence supports recovery; otherwise stop monitoring without claiming recovery.

Safety and truthfulness constraints

• Do not treat an AI explanation as a metric source.
• Do not hide missing or conflicting evidence.
• Do not infer customer identity across providers from timestamps alone.
• Do not claim a release, campaign, incident, or intervention caused a movement without evidence that supports causation.
• Do not modify provider records, subscriptions, refunds, incidents, or deployments through read-only connections.
• Do not treat a completed task as proof that a business condition recovered.
• Do not present a metric as ready before its history, definition, coverage, and source requirements are met.

Commercial and data boundaries

The documentation describes a read-only diagnostic layer. Prolytics reads connected systems, computes supported metrics, preserves findings and investigations, explains evidence, and follows outcomes. It does not replace PostHog, Stripe, or Sentry, and it does not alter their records.

Customer data is used to operate the service, answer requests, preserve paid history, support customers, and protect the platform. Customer data is not used to train models unless explicitly authorised.

---

Agent extraction checklist

When analysing a new product question, extract these fields before proposing an answer:

1. Business symptom or decision: What changed or what decision must be made?
2. Domain: Usage, Billing, Reliability, or a cross-source question.
3. Required source: PostHog, Stripe, Sentry, or a defined combination.
4. Timeframe and comparison: Exact reporting window and baseline.
5. Candidate capability: Match the question to one of the 29 stable capability IDs where possible.
6. Readiness requirements: History, event definitions, permission, performance data, currency, or identity coverage.
7. Engine mode: Fetch, Correlate, or Investigate.
8. Evidence strength: Source-level, timing-level, or identity-linked evidence.
9. Limitation: Missing, stale, conflicting, unavailable, or insufficient evidence.
10. Follow-through: Whether a Watch should preserve the condition after the team acts.

This order keeps the agent grounded in the product's evidence model and prevents unsupported conclusions from being presented as facts.