Fact
store eventWhat Apple or Google reported.
Receipts are facts. Revenue and access are claims.
Stores tell you what they observed. Your product still needs to decide what the customer can use, what the business earned, and whether the answer is complete. CherrySub keeps those claims separate, traceable, and honest when one is late.
One signed ledger supports access, analytics, and operational health.
Interpretation
accessWhat your product decides it means.
Confidence
healthWhether the answer is complete and current.
One history, three answers.
The same normalized transaction can be read as customer access, business performance, or system health. The views differ; the source identity does not.
The model
A receipt becomes useful only after context.
CherrySub keeps the store fact, product interpretation, and operational confidence linked instead of flattening them into one status.
Store factsubscription renewed
+Product ruleproduct → pro
=Current answerpro · active
One signed ledger
Different interfaces, shared event identity.
Support, analytics, and engineering health can follow the same event without passing screenshots between tools.
evt_73f1Customer timelinepro activeevt_73f1Revenue overview+$9.99 MRRevt_73f1Delivery inspector200 · 84msHonest health
Connected is not receiving. Receiving is not verified.
Each boundary reports independently so the team knows whether to fix credentials, delivery, or product mapping.
App Store connectedKey and issuer acceptedyes
Apple events receivingLast message 1.2s agolive
Signatures verified0 rejected today100%
Play RTDN pullMissing subscriber roleblocked
The broken claim is named. Everything upstream and downstream keeps its own status.
Explainability
Wrong and late are different states.
A number may disagree because a rule is wrong, a store is delayed, or processing is still active.
revenue_overview · 18 Aug · partial value $184,120 freshness processing pending_events 7 expected_delta $69.93 reason store_processing_lag
Infrastructure earns trust by showing its boundaries.
CherrySub is designed around three commitments: state must be explainable, failure must be located, and history must remain portable.
Every answer keeps a reason
Access and revenue changes remain linked to the event and product rule that produced them.
One green tick is not enough
Connection, receipt, verification, mapping, and delivery report separately so ownership is obvious.
Your facts should leave cleanly
Stable event IDs, exports, and signed deliveries keep the ledger useful outside a single interface.
Watch one receipt become three defensible answers.
Run a sandbox purchase and inspect access, revenue, and health from the same event.