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 you 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 your 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. You can mark it 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 you need search, filters, or a longer review history. 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 you what deserves review. Signals tell you that a supported metric moved outside its expected range. Neither one 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 the detail views beneath each domain when the summary changes a decision. The 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 Building as an instruction, not an error

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 the readiness state 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 you continue from Health.

Choose Wait for evidence when the 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 you. 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 you take. You can still begin a Watch 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 the Watch detail when the condition moves. Compare the original and current values, inspect the 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 the 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 the 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 you that work was completed. Watch helps you see 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 you must complete 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.

Good Fetch questions include “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 you already have a possible explanation and want to test whether the specified signals moved together in the same period.

Good Correlate questions include “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 you know the symptom but several explanations remain possible. Engine tests supported explanations across the available evidence and ranks what it can establish.

Good Investigate questions include “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, the timeframe, and any useful place to begin. You do not need exact event names, property keys, or provider schemas. Use the language your team already uses and avoid adding a suspected cause only to make the prompt sound precise.

Read Staging before trusting the Answer

The Staging tab shows the investigation as it develops. Use it to see the 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 the 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 you should still check the initial question before running it. Add a missing timeframe or metric explicitly.

Use Fetch when you only need to confirm the number. Use Correlate when you have 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 the 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 the remaining uncertainty cannot be resolved with the 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 your business rather than copying a suspected cause into the prompt.

What is driving the MRR decline?

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

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 you have a specific customer outcome to compare:

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:

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:

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