Framework
Layered Continuous Monitoring
No single data source is sufficient for population health inference. Combine financial claims, wearables, face scan biomarkers, labs, questionnaires, and partner integrations into a unified data lake — each layer compensates for gaps in the others.
How it works
- 1Financial data (insurance claims): cleanest and most complete — every pharmacy purchase, doctor visit, and lab draw leaves a payment trail. Perfect information within its scope.
- 2Wearable data: rich biometrics (heart rate, glucose, oxygen) but limited by penetration — ~15% of the Brazilian population has a wearable. High-value for those who have it; can't be the primary layer.
- 3Face scan inference: 30-second video, 32 inferred clinical variables using MIT-developed blood vessel coloration analysis. Covers the wearable gap but produces probabilities, not measurements.
- 4Labs and questionnaires: episodic and self-reported, but meaningful when combined with continuous data. Validates or challenges inferences from other layers.
- 5The combination principle: each layer's coverage gap is filled by others. The data lake fusion makes predictions that no single source could produce. The 95M monthly inferences Axenya runs would be impossible with any single input stream.
Hear it on the podcast
AI Can Predict Disease Years EarlyListen to the episodeMore from this episode
Outcome-Aligned Revenue ModelAxenya's approach to incentive alignment: charge a performance fee on the measurable delta between a client's healthcare cost growth and the market baseline. No outcome, no fee — making the vendor's financial interest structurally identical to the client's health interest.AI Copilot ArchitectureEvery AI output surfaces with a transparent reasoning chain and supporting citations before reaching a human decision-maker. If the model can't explain why, the inference doesn't get surfaced. Human judgment is preserved at the decision layer.
Get the next framework first
One email a week with the frameworks, tools, and founder stories from the podcast. Free.
More frameworks for Building the Product
Crowdsourced Insight SignalWhen users independently mark moments they find most valuable, the aggregate frequency of those marks per content unit becomes a quality discovery layer superior to algorithmic recommendation or editorial curation.Build Backwards from Business RequirementsWoz's core development philosophy: architecture decisions, security guardrails, and compliance requirements are defined at the start from a CTO lens — not added iteratively after prototyping proves the concept.The Virtuous Expertise LadderIn peer expertise marketplaces, today's beginner becomes tomorrow's best helper. The person who just solved a problem is more empathetic, more contextually accurate, and more effective at explaining the fix than a senior expert who solved it years ago. This creates a self-sustaining supply side: as a community matures, freshly-graduated members flow back into the marketplace as helpers. Design for this natural progression — it's both your supply mechanism and your community glue.The Flow-First Product PrincipleDesign your product around protecting momentum, not just delivering features. The most valuable intervention in a creative work session isn't the best feature — it's the one that keeps someone from abandoning their project entirely. On Demand Human is built on this principle: 15 minutes of expert help at the right moment is worth more than any feature upgrade, because it preserves the flow state that makes all other work possible.The 70/30 Software StackSeventy percent of every new software application is commodity: authentication, user management, CRUD operations, data pipelines, notifications. It was never innovative. Every dev shop had internal boilerplates for it. The competitive advantage in software has always come from the 30% that's unique. In 2026, this matters more: any decent CRM can be built in a day. Automate the 70%; focus all human effort and genuine IP development on the 30%.Requirements-First DevelopmentThe CTO's core job is not writing code — it's translating business objectives into technical requirements, then ensuring the code solves the right problem. Start there. Generating code before generating requirements produces something technically functional that solves the wrong problem. The 70% wall is the symptom; deferred requirements are the cause. Requirements elicitation — guided prompting to extract what you actually need — is what separates MVPs from prototypes.