Oriented Platforms Data-intensive intelligence layers and ML in production for real operations. We build the system that takes your data from raw sources to operational decisions. For operations that already exist. Site: https://orientedplatforms.com --- # About Oriented Platforms is a software services business focused on data-intensive intelligence layers and ML in production for real operations. Working with serious teams worldwide on systems where the data, the operation, and the stakes are already real. We work with operations that already exist — hedge funds, prediction markets, real-estate underwriting, social-media intelligence, field operations, premium consumer apps with real data complexity. Industries are evidence; the through-line is the problem type, not the domain. --- # Suites — productized services ## AI Implementation Suite URL: https://orientedplatforms.com/suites/ai-implementation Date: 2026-06-11 Summary: Eleven productized services for businesses with real operations — from a 2-4 week audit through multi-quarter transformation engagement to per-function operational AI. Engineering shop, not agency. For: COOs · CFOs · CIOs · Owner-operators · Heads of operations Flagship: ai-transformation-engagement , { name: "Document & knowledge intelligence", description: "Horizontal LLM-and-extraction products for the document corpus most established businesses accumulate — ingestion and routing, internal knowledge access, contract and compliance review.", products: [ "document-intelligence-engine", "internal-knowledge-assistant", "contract-compliance-review-engine", ], }, { name: "Workflow & operations automation", description: "One product per business function — process orchestration, customer support, sales and marketing ops, finance ops, HR ops, field operations. AI for every function that runs your business.", products: [ "process-automation-agents", "customer-support-ai", "sales-marketing-operations-ai", "finance-operations-ai", "hr-operations-ai", "field-operations-automation", ], }, ], buyerPersonas: [ "COOs", "CFOs", "CIOs", "Owner-operators", "Heads of operations", ], embeddedCaseStudies: [], competitorContext: ["Tenex"], showcaseVideo: "https://d2ltjf6cq2ppzr.cloudfront.net/videos/be0f72f8587e401e827c37a3cd37a5ad.MP4", }; AI implementation done by an engineering shop. For businesses with real operations — solo trades to mid-market enterprises. The suite is structured to meet buyers where they are. Some buyers want an audit before committing; the Implementation Audit is fixed-fee, 2-4 weeks, packaged. Some buyers want the strategic partnership shape that competes directly with the AI-transformation consultancies; the Transformation Engagement is multi-quarter, principal-led, integrated. Most buyers eventually want one or more of the operational products — document intelligence, customer support AI, finance ops AI, the rest. The positioning principle: real operations, not company size. An HVAC company with 30 trucks and real customer data is a serious operating business. A mid-market manufacturer with 200 employees is a serious operating business. A $200M software company is also a serious operating business. The suite scales across that range; the products inside it pick the function and pick the depth. Works with the powerful models offered by Anthropic, OpenAI, or other providers. The integration discipline matters more than the model choice; models change every quarter and the framework around them shouldn't. Horizontal overlap is real. Document Intelligence here is the horizontal version of FO's K-1 Extraction and PE's Diligence Red-Flag Engine. Finance Operations AI here is the horizontal version of FO's Invoice & Bill-Pay. Where the buyer has a vertical-specialized version available, we cross-link to it. ### Strategy & engagement How the relationship starts. A fixed-fee audit for businesses that want clarity before committing; a multi-quarter strategic partnership for businesses ready to commit to a transformation. - AI Implementation Audit — A productized 2-4 week audit — operations mapped, candidate AI use cases identified, each scored on effort and impact, packaged as a roadmap document with prioritized action plan. (https://orientedplatforms.com/suites/ai-implementation/ai-implementation-audit) - AI Transformation Engagement — A multi-quarter engagement covering strategy, implementation, integration, and team training. Principal-led (Bogdan in the discovery and architecture phases, ongoing oversight throughout). Outcome: AI deployed in production across the use cases identified during strategy. (https://orientedplatforms.com/suites/ai-implementation/ai-transformation-engagement) ### Document & knowledge intelligence Horizontal LLM-and-extraction products for the document corpus most established businesses accumulate — ingestion and routing, internal knowledge access, contract and compliance review. - Document Intelligence Engine — A document-AI pipeline that ingests the business's document corpus, classifies by type, extracts the relevant fields, routes to downstream systems with confidence-graded review queue. (https://orientedplatforms.com/suites/ai-implementation/document-intelligence-engine) - Internal Knowledge Assistant — An LLM-powered Q&A assistant on the business's internal document corpus — team-facing chat interface, permission-aware, with answer-with-citation so users can verify before acting. (https://orientedplatforms.com/suites/ai-implementation/internal-knowledge-assistant) - Contract & Compliance Review Engine — An AI review layer for the contract and compliance document corpus — extracts canonical clauses, flags off-standard terms against the business's precedent, checks policy compliance against regulatory and internal standards, surfaces anomalies for legal review. (https://orientedplatforms.com/suites/ai-implementation/contract-compliance-review-engine) ### Workflow & operations automation One product per business function — process orchestration, customer support, sales and marketing ops, finance ops, HR ops, field operations. AI for every function that runs your business. - Process Automation Agents — A multi-step agent orchestration layer — workflows expressed as agent-coordinated processes, integrated with the business's existing systems, with human-in-loop checkpoints where the workflow needs them. (https://orientedplatforms.com/suites/ai-implementation/process-automation-agents) - Customer Support AI — An AI layer over the existing ticket stack — routes tickets by category and urgency, drafts initial responses for routine queries, flags edge cases for escalation, surfaces context from prior interactions and product documentation. (https://orientedplatforms.com/suites/ai-implementation/customer-support-ai) - Sales & Marketing Operations AI — An AI layer across the RevOps stack — predictive lead scoring, CRM data hygiene, outbound drafting and sequence-optimization, attribution analysis. Sits on top of the existing CRM and marketing automation. (https://orientedplatforms.com/suites/ai-implementation/sales-marketing-operations-ai) - Finance Operations AI — An AI layer over the finance-ops workflows — invoice ingestion and posting, expense categorization, AP/AR reconciliation, payment matching, fraud-pattern detection. Integrates with the business's accounting system (NetSuite, QuickBooks, Sage, Xero, custom). (https://orientedplatforms.com/suites/ai-implementation/finance-operations-ai) - HR Operations AI — An AI layer over the People-Ops workflows — resume screening with bias-audit, interview scheduling, draft generation for employee communications, onboarding workflow automation. Integrates with the existing ATS and HRIS. (https://orientedplatforms.com/suites/ai-implementation/hr-operations-ai) - Field Operations Automation — An AI layer for the field-service operating stack — scheduling and dispatch optimization, automated customer communications, quote-generation drafting, follow-up automation. Integrates with the standard field-service software (ServiceTitan, Jobber, Housecall Pro) or with the business's existing custom stack. (https://orientedplatforms.com/suites/ai-implementation/field-operations-automation) --- ## Family Office Suite URL: https://orientedplatforms.com/suites/family-office Date: 2026-06-11 Summary: Eight productized services for family-office ops modernization — document ingestion, multi-entity consolidation, liquidity forecasting, family reporting. CFO and Controller-facing, not principal-facing. For: CFOs · Controllers · Operations directors · FO General Counsels Flagship: k-1-extraction-engine , { name: "Consolidation", description: "The cross-entity data layer. Trust, partnership, and personal holdings normalized into a single view, queryable in natural language.", products: [ "multi-entity-consolidation-platform", "conversational-portfolio-assistant", ], }, { name: "Forecasting + reporting", description: "The output layer. Liquidity forecasts, cash-flow projections, family reports drafted in the FO's preferred tone.", products: [ "liquidity-cash-forecasting-engine", "family-report-drafter", ], }, ], buyerPersonas: [ "CFOs", "Controllers", "Operations directors", "FO General Counsels", ], embeddedCaseStudies: [], competitorContext: ["Addepar", "AtlasFive", "Eton Solutions"], }; This suite is positioned for *FO ops modernization*, not investment intelligence. Family offices typically don't need OP to pick managers or screen funds — that's what their external advisors and CIOs do. What they need is the layer underneath: the document pipeline, the multi-entity consolidation, the reporting that the CFO and controller currently assemble by hand every quarter. The principal-facing layer is one click up — the Conversational Portfolio Assistant sits on top of the consolidation platform, so a principal asking "what's our current cash position?" gets an answer without anyone running a query. But the buyers are the finance and ops team. Across the three tiers, the bar is what FO operations always demand — audit trails on every transformation, privacy partitions between family members where the structure requires them, and reporting outputs that pass external auditor review. ### Ingestion The document pipeline. K-1s, statements, capital calls, invoices, legal documents — extracted, classified, validated, and posted to the ledger of record. - K-1 Extraction & Validation Engine — A document-AI pipeline that ingests the K-1 corpus as it arrives, extracts all 200+ fields with confidence scores, maps to the FO's chart of accounts, flags inconsistencies against partnership returns, and posts to AtlasFive (or your fund-accounting system) with audit trail. (https://orientedplatforms.com/suites/family-office/k-1-extraction-engine) - Statement & Capital-Call Ingestion Engine — A document-AI pipeline that ingests the year-round financial document corpus — statements, capital-call notices, distribution notices, trade confirms — extracts the relevant fields, classifies the transaction, and posts to the ledger of record with confidence-graded review queue. (https://orientedplatforms.com/suites/family-office/statement-capital-call-ingestion-engine) - Invoice & Bill-Pay Engine — An AP pipeline that ingests invoices from email and vendor portals, classifies the vendor, predicts the GL code, suggests payment-batch timing, detects duplicates and anomalies, and posts to the ledger of record with audit trail. (https://orientedplatforms.com/suites/family-office/invoice-bill-pay-engine) - Legal & Compliance Document Summarizer — An LLM-and-extraction layer over the FO's legal document corpus — summarizes incoming documents, extracts and tracks key clauses, surfaces anomalies against precedent, generates working drafts for routine review. (https://orientedplatforms.com/suites/family-office/legal-compliance-document-summarizer) ### Consolidation The cross-entity data layer. Trust, partnership, and personal holdings normalized into a single view, queryable in natural language. - Multi-Entity Consolidation Platform — A consolidation platform that ETLs from each entity's source-of-record system, normalizes to a unified chart of accounts, handles FX and intercompany eliminations, surfaces per-family-member and per-asset-type views, and enforces privacy partitions where the structure requires them. (https://orientedplatforms.com/suites/family-office/multi-entity-consolidation-platform) - Conversational Portfolio Assistant — An LLM-powered natural-language interface on top of the Multi-Entity Consolidation Platform — accepts questions in plain English, queries the underlying data, returns answers with the supporting numbers and audit links. (https://orientedplatforms.com/suites/family-office/conversational-portfolio-assistant) ### Forecasting + reporting The output layer. Liquidity forecasts, cash-flow projections, family reports drafted in the FO's preferred tone. - Liquidity & Cash Forecasting Engine — A liquidity forecasting model trained on the family's inflow and outflow patterns plus macro signals (Fed rates, sector benchmarks for investment distributions) — surfaces predicted shortfalls and excesses 60 days ahead with the driving factors documented. (https://orientedplatforms.com/suites/family-office/liquidity-cash-forecasting-engine) - Family Report Drafter — An LLM-powered drafting layer that produces quarterly family reports, capital-call notices, tax-footnote narrative, and ad-hoc communications — trained on the FO's historical document structure and preferred tone, with the CFO finalizing. (https://orientedplatforms.com/suites/family-office/family-report-drafter) --- ## Hedge Fund Suite URL: https://orientedplatforms.com/suites/hedge-fund Date: 2026-06-11 Summary: Six productized services for hedge funds whose research bench already exists — five ways to source informational edge, one macro risk overlay. For: Quant PMs · CIOs · Research bench leads Flagship: alternative-data-signal-engine , { name: "Portfolio & risk", description: "Macro regime classification feeding a position-sizing and hedging overlay. CIO- and CRO-facing.", products: ["macro-risk-overlay"], }, ], buyerPersonas: ["Quant PMs", "CIOs", "Research bench leads"], embeddedCaseStudies: ["hedge-fund-quant-alt-data-layer"], competitorContext: ["Bayesline / ALEX"], }; This suite is built for funds whose research bench *already exists*. The work is the layer between unconventional data sources and tradeable signal — pipelines that ingest, models that score, infrastructure that survives the production day. Custom builds where the edge demands custom; ready-made data products where the dataset is shared. The two tiers compose. Alpha sources informational edge; the risk overlay sizes the positions that informational edge generates. Most funds enter on one alpha-layer product first, then layer risk on top once the signal is live and the attribution is honest. Across both tiers, the bar is the same: idempotent ingestion, walk-forward backtests where the data justifies them, point-in-time correctness for everything that touches historical depth, attribution end-to-end. None of these are differentiators — they're the ante. ### Alpha layer Five ways to source informational edge — one custom-built pipeline, two ready-made data products, two specialty intelligence layers. - Alternative Data Signal Engine — A production pipeline that ingests one or more unconventional datasets, normalizes against a fund-internal schema, and serves processed factor scores, back-tested signals, and event-time alerts to the research stack. (https://orientedplatforms.com/suites/hedge-fund/alternative-data-signal-engine) - Cross-Lingual News & Filings Intelligence — Intraday sentiment scores and event extractions for tickers, sectors, and macro themes, sourced from non-English news, regulatory filings, and social — covering the languages where your existing stack goes dark. (https://orientedplatforms.com/suites/hedge-fund/cross-lingual-news-filings-intelligence) - Trade-Credit & Supply-Chain Score — A monthly score and supporting attribution data on every covered public company — vendor payment cadence, trade-credit balance trajectory, supplier-concentration risk, supply-chain network deltas. Delivered via API and SFTP. (https://orientedplatforms.com/suites/hedge-fund/trade-credit-supply-chain-score) - Consumer Spending & Foot-Traffic Dashboard — Weekly dashboards combining anonymized card spend (US consumer) and foot-traffic (mapped to ticker via store-location databases) — earnings-window trend detection for the names and themes consumer funds trade. (https://orientedplatforms.com/suites/hedge-fund/consumer-spending-foot-traffic-dashboard) - Prediction-Market Alpha Layer — A clean feed of prediction-market probabilities mapped to your existing macro and event-driven framework — Fed move probabilities, geopolitical risk markers, election-implied probabilities, joined to the equity sector exposures and macro positions they should influence. (https://orientedplatforms.com/suites/hedge-fund/prediction-market-alpha-layer) ### Portfolio & risk Macro regime classification feeding a position-sizing and hedging overlay. CIO- and CRO-facing. - Macro Risk Overlay — A regime classifier trained on rates, vol, credit-spread, and macro-data series — paired with a recommended position-sizing and hedging overlay that the portfolio construction team consumes alongside the existing risk framework. (https://orientedplatforms.com/suites/hedge-fund/macro-risk-overlay) --- ## iOS App Development Suite URL: https://orientedplatforms.com/suites/ios-app-development Date: 2026-06-11 Summary: Full iOS app builds — native SwiftUI, App Store Optimization, monetization, retention. For founders shipping their first app and established businesses adding an iOS surface. For: iOS founders · Established businesses adding an iOS surface · Existing app operators Flagship: ios-app-build , { name: "Specialized engagements", description: "Targeted iOS work for apps that already exist — ASO, monetization, performance, accessibility.", products: [ "ios-app-store-optimization", "ios-monetization-integration", ], }, ], buyerPersonas: [ "iOS founders", "Established businesses adding an iOS surface", "Existing app operators", ], embeddedCaseStudies: [], competitorContext: [], }; This suite is built for two distinct buyers under one roof. Founders shipping their first iOS app want a productized engagement that takes them from concept to App Store without a year-long custom build. Established businesses with an existing web operation want to add an iOS surface that meets the Apple Human Interface Guidelines and ships polished. Native SwiftUI is the backbone — no React Native, no hybrid. Apple's design language and platform APIs win where the UX matters. The build is opinionated about what's worth doing: RevenueCat for monetization plumbing, CloudKit for sync, SwiftData for persistence, and conversion-optimized flows that the App Store review process actually approves. Across both tiers, the bar is the same: shipped to the App Store, defensible against review, retentive after the first session. ### Full builds Productized iOS app engagements — concept to App Store in a fixed window. - iOS App Build — A complete iOS app from concept to App Store — native SwiftUI, monetization wired (RevenueCat / Apple Pay / In-App Purchase), CloudKit sync, retention triggers, App Store submission and first review handled. (https://orientedplatforms.com/suites/ios-app-development/ios-app-build) ### Specialized engagements Targeted iOS work for apps that already exist — ASO, monetization, performance, accessibility. - iOS App Store Optimization — Refreshed App Store listing — keyword strategy, copy, screenshot and video assets — plus a measurement framework for ongoing iteration. (https://orientedplatforms.com/suites/ios-app-development/ios-app-store-optimization) - iOS Monetization Integration — Production-grade monetization integration — RevenueCat backbone, paywall flows tested against the App Store Review Guidelines, receipt validation, restore-purchase handling, subscription lifecycle events wired into your analytics. (https://orientedplatforms.com/suites/ios-app-development/ios-monetization-integration) --- ## Operations Algorithms Suite URL: https://orientedplatforms.com/suites/operations-algorithms Date: 2026-06-11 Summary: Ten productized services for established businesses with real operational data — customer intelligence, commercial optimization, classical operations research. Math-anchored, ML-aware, decision-output. For: Heads of growth · COOs · Commercial leads · Operations directors · CFOs Flagship: customer-clustering-ltv-engine , { name: "Commercial optimization", description: "Demand, inventory, pricing. The revenue half — what to stock, what to charge, when to promote.", products: [ "demand-forecasting-inventory-engine", "dynamic-pricing-promotion-engine", ], }, { name: "Operations research", description: "Classical OR applied to real operating problems — routing, scheduling, production planning, cost optimization. Deterministic, explainable, auditable.", products: [ "logistics-routing-optimizer", "workforce-scheduling-engine", "production-resource-planner", "enterprise-saas-spend-optimization", ], }, ], buyerPersonas: [ "Heads of growth", "COOs", "Commercial leads", "Operations directors", "CFOs", ], embeddedCaseStudies: [], competitorContext: [], }; This is the broadest suite in the catalogue — ten products across three tiers, applied to established businesses with real operational data. The thesis: most operating problems have well-understood mathematical structure, and the path from data to better decisions runs through that structure faster than through pure ML. Customer intelligence is the ML half — clustering, churn, recommendation. Commercial optimization is the ML/forecasting half — demand, pricing. Operations research is the classical half — linear programming, transport problems, scheduling. We're deliberately attached to the classical algorithms in the third tier; they're explainable, auditable, and often outperform ML for well-defined optimization problems. Across all three tiers, the bar is the same: deployable models, not academic outputs. Decision-output, not dashboard. ### Customer intelligence Clustering, churn, personalization, benchmarks. The customer-data half — what the business knows about who buys, how often, and what's next. - Customer Clustering & LTV Engine — An unsupervised clustering layer over the client's own customer-and-transaction data — surfaces behavioral segments using RFM and broader signal sets, attaches a lifetime-value forecast per segment, feeds marketing and retention decisions. (https://orientedplatforms.com/suites/operations-algorithms/customer-clustering-ltv-engine) - Churn Prediction & Retention Engine — A classification layer per customer — churn probability with confidence bands, risk-driver attribution (why the model thinks this customer is at risk), and retention-action recommendations tied to the predicted risk drivers. (https://orientedplatforms.com/suites/operations-algorithms/churn-prediction-retention-engine) - Real-Time Personalization API — An API that returns the next-best-product, next-best-content, or next-best-offer per user — fed by the client's own behavior data, augmented (with consent) by Subscription Economy Benchmarks contextual signal where the use case warrants. (https://orientedplatforms.com/suites/operations-algorithms/real-time-personalization-api) - Subscription Economy Benchmarks API — An API and dashboard with anonymized aggregate subscription benchmarks across categories — sourced from SubMagician's consumer base, presented as aggregate cohort metrics with explicit privacy boundaries and use restrictions. (https://orientedplatforms.com/suites/operations-algorithms/subscription-economy-benchmarks-api) ### Commercial optimization Demand, inventory, pricing. The revenue half — what to stock, what to charge, when to promote. - Demand Forecasting & Inventory Engine — A forecasting layer at SKU grain — combines time-series baselines with external signal (macro indicators, social-and-search signal, weather, consumer-behavior priors) — feeds inventory and replenishment decisions with documented uncertainty. (https://orientedplatforms.com/suites/operations-algorithms/demand-forecasting-inventory-engine) - Dynamic Pricing & Promotion Engine — An elasticity-and-promotion model — per-segment price elasticity (or discount-elasticity for negotiated B2B), promotion-cannibalization modeling, recommended timing and depth that maximizes net revenue. (https://orientedplatforms.com/suites/operations-algorithms/dynamic-pricing-promotion-engine) ### Operations research Classical OR applied to real operating problems — routing, scheduling, production planning, cost optimization. Deterministic, explainable, auditable. - Logistics & Routing Optimizer — A routing-and-distribution optimization engine — solves vehicle routing problem (VRP) variants for the business's fleet and constraints, produces daily route assignments with documented cost reduction vs. the prior method. (https://orientedplatforms.com/suites/operations-algorithms/logistics-routing-optimizer) - Workforce Scheduling Engine — A workforce-scheduling optimizer that produces shift assignments against the business's constraints (skills, availability, labor law, demand forecasts) — runs weekly or daily depending on the cadence, with manager-side UI for review and override. (https://orientedplatforms.com/suites/operations-algorithms/workforce-scheduling-engine) - Production & Resource Planner — A linear-programming model for the business's production-planning problem — what to make, how much, in what mix, allocated to which demand. Run weekly or per planning cycle, with documented improvement vs. the prior method. (https://orientedplatforms.com/suites/operations-algorithms/production-resource-planner) - Enterprise SaaS Spend Optimization — An audit-plus-optimization engagement that maps the company's SaaS stack against actual usage, identifies redundant vendors and over-provisioned licenses, models the consolidation scenarios, recommends the contract renegotiations that would maximize savings. (https://orientedplatforms.com/suites/operations-algorithms/enterprise-saas-spend-optimization) --- ## Private Equity Suite URL: https://orientedplatforms.com/suites/private-equity Date: 2026-06-11 Summary: Nine productized services across the PE deal cycle — pre-deal diligence, hold-period intelligence, exit and LP reporting. The flagship is technical diligence the way an engineering shop does it. For: Operating partners · Deal teams · GP principals · Finance / IR leads Flagship: technical-dd-engine , { name: "Hold", description: "Portfolio intelligence and value creation. Operating partners see across the book, forecast each portco, and act on the pricing and margin levers that move the next print.", products: [ "portfolio-intelligence-platform", "portfolio-forecasting-engine", "post-acquisition-integration-tracker", "pricing-margin-optimizer", ], }, { name: "Exit + LP", description: "Exit-prep automation and LP-facing reporting. The unglamorous half of the cycle, automated.", products: ["exit-prep-automation", "lp-reporting-engine"], }, ], buyerPersonas: [ "Operating partners", "Deal teams", "GP principals", "Finance / IR leads", ], embeddedCaseStudies: [], competitorContext: ["Xapien", "PitchBook", "SmartRoom"], }; The PE deal cycle is the most legible structural narrative in capital allocation — source, diligence, close, hold, exit, report. Most PE-services firms cover one phase well and the others adequately. We build across the cycle because the data infrastructure each phase needs reuses what the prior phase produced. The flagship is the one most firms can't credibly offer: technical due diligence on the code itself, the way an engineering shop would do it. Other DD shops can read financial statements; few can read a codebase and tell you what shipping that codebase on day 30 of ownership actually looks like. Across the three tiers, the bar is what production work always demands — point-in-time correctness, idempotent ingestion, observability at every boundary. None of these are differentiators; they're the ante. ### Pre-deal Sourcing and diligence. Where speed and signal-quality compound — the deal team finds more targets and de-risks each one faster. - Deal-Sourcing Engine — A scoring pipeline that ingests structured (PitchBook-class) and unstructured (news, hiring, patents, alt-data) sources, applies your fund's thesis-specific filters, and ranks candidate targets — feeding your CRM with the top tier weekly. (https://orientedplatforms.com/suites/private-equity/deal-sourcing-engine) - Technical Due Diligence Engine — A code- and architecture-level diligence report — red/yellow/green risk heatmap across modules, dependency analysis, test-coverage and CI/CD posture, security vulnerability surface, and the operating-partner-readable summary of what the next twelve months of platform work will cost. (https://orientedplatforms.com/suites/private-equity/technical-dd-engine) - Diligence Red-Flag Engine — An AI-extraction-and-review layer that ingests the data room, surfaces the anomalies and the off-market clauses, benchmarks against comparable transactions, and screens beneficial ownership against sanctions and PEP lists — delivered as a risk heatmap the deal team works against. (https://orientedplatforms.com/suites/private-equity/diligence-red-flag-engine) ### Hold Portfolio intelligence and value creation. Operating partners see across the book, forecast each portco, and act on the pricing and margin levers that move the next print. - Portfolio Intelligence Platform — A unified portfolio platform: ETL pipelines from each portco system (Excel, QuickBooks, NetSuite, Sage, Stripe) plus third-party data (Preqin, Bloomberg), normalized to a single schema, exposed through cross-portco dashboards with covenant tracking and liquidity alerts. (https://orientedplatforms.com/suites/private-equity/portfolio-intelligence-platform) - Portfolio Forecasting Engine — Predictive forecasting models per portco — quarterly cash-flow and EBITDA projections trained on the portco's internal financials and sector-comparable data, with structured scenario planning (cost-cut sensitivity, price-elasticity scenarios, demand-shock testing) that feeds straight into the fund's valuation model. (https://orientedplatforms.com/suites/private-equity/portfolio-forecasting-engine) - Post-Acquisition Integration Tracker — An NLP and ML layer that reads the recurring integration artifacts — board decks, weekly status reports, ops dashboards, strategy memos — extracts integration-milestone status, predicts timeline slippage, and surfaces missed synergies before board prep makes them visible. (https://orientedplatforms.com/suites/private-equity/post-acquisition-integration-tracker) - Pricing & Margin Optimizer — An ML layer on the portco's product, customer, and channel data — estimates price-elasticity per segment, identifies the margin levers worth pulling, simulates the impact of pricing and packaging changes before they ship. (https://orientedplatforms.com/suites/private-equity/pricing-margin-optimizer) ### Exit + LP Exit-prep automation and LP-facing reporting. The unglamorous half of the cycle, automated. - Exit-Prep Automation — An exit-prep package — automated data room construction from the portco's existing systems, investor-deck assembly with portco metrics auto-populated, comparable-transaction analysis against current-market multiples, buyer-pool intelligence for the strategic and financial pools. (https://orientedplatforms.com/suites/private-equity/exit-prep-automation) - LP Reporting Engine — An automated reporting pipeline — calculates IRR / MOIC / DPI / TVPI per vehicle, generates per-LP report PDFs in each LP's preferred format, populates LP portals via API where available, produces ILPA-template-compliant ESG reports, and exports K-1 / 1099 XML for the year-end tax cycle. (https://orientedplatforms.com/suites/private-equity/lp-reporting-engine) --- ## Real Estate Suite URL: https://orientedplatforms.com/suites/real-estate Date: 2026-06-11 Summary: Six productized services for the asset lifecycle — two for investment teams (valuation, site selection), four for operators (rental pricing, tenant intelligence, building health, lease abstraction). For: RE investment teams · REIT operations · Property managers · Developers Flagship: property-valuation-engine , { name: "For RE operators", description: "Property managers, multifamily operators, facility teams, REIT operations — the hold-side products. Pricing, tenant intelligence, building health, lease abstraction.", products: [ "dynamic-rental-pricing-engine", "tenant-intelligence-engine", "building-health-maintenance-engine", "lease-abstraction-engine", ], }, ], buyerPersonas: [ "RE investment teams", "REIT operations", "Property managers", "Developers", ], embeddedCaseStudies: [], competitorContext: ["HouseCanary", "Reonomy", "OpenAVMKit", "AppFolio"], }; Real estate is two distinct buyer profiles under one suite. The investment team buys valuation and site-selection intelligence; the operating team buys pricing, tenant, building, and lease-document automation. We separated them on the page because the pages should speak to the buyer. The flagship is on the investment side — Property Valuation Engine. The technical reference point for the AVM half of the suite is OpenAVMKit (Lars Doucet's open-source mass-appraisal toolkit) — we draw from the same modeling stack (LightGBM, XGBoost ensembles, GWR for spatial correction) and apply it to investor-side, not assessor-side, workflows. We deliberately don't play in the property-tax-assessor market — that's a government-sales lane with IAAO-compliance overhead and a different go-to-market shape. ValueBase serves that lane well; we serve the investor and operator sides. ### For RE investment teams Investors, developers, REIT acquisitions, RE-focused PE — the deal-side products. Valuation, site selection, comparable analysis at portfolio scale. - Property Valuation Engine — An automated valuation model that ingests comparable sales, rents, macro-data, and property features — produces instant valuations with documented uncertainty, plus sensitivity scenarios (cap-rate moves, rent growth assumptions, expense trajectory) the deal team uses for underwriting. (https://orientedplatforms.com/suites/real-estate/property-valuation-engine) - Site Selection Intelligence — A geospatial-and-economic data platform that fuses zoning, transit, demographic, employment, and permit-activity data — produces investment-scoring heatmaps at parcel and neighborhood granularity, configured to the fund's investment thesis. (https://orientedplatforms.com/suites/real-estate/site-selection-intelligence) ### For RE operators Property managers, multifamily operators, facility teams, REIT operations — the hold-side products. Pricing, tenant intelligence, building health, lease abstraction. - Dynamic Rental Pricing Engine — A pricing model trained on the property's leasing history, competitor positioning, and macro signals — produces weekly pricing recommendations at the unit level, with the underlying demand forecast and the competitor-comp context surfaced. (https://orientedplatforms.com/suites/real-estate/dynamic-rental-pricing-engine) - Tenant Intelligence Engine — A classification layer over tenant data — predicts churn probability on existing tenants, scores incoming leads, recommends retention actions tied to predicted risk drivers. (https://orientedplatforms.com/suites/real-estate/tenant-intelligence-engine) - Building Health & Maintenance Engine — An IoT-and-ML platform that ingests sensor telemetry from critical equipment, fuses with work-order history and weather data, produces a Building Health Score per asset and a recommended preventive-maintenance schedule. (https://orientedplatforms.com/suites/real-estate/building-health-maintenance-engine) - Lease Abstraction Engine — A document-AI pipeline that extracts the canonical commercial-lease terms (commencement, term, base rent, escalation structure, option periods, expense pass-through structure, exclusions, default triggers, transfer restrictions) into a structured database — with confidence scoring, review queue, and audit trail back to source. (https://orientedplatforms.com/suites/real-estate/lease-abstraction-engine) --- ## Shopify Ops Intelligence Suite URL: https://orientedplatforms.com/suites/shopify-ops-intelligence Date: 2026-06-11 Summary: Eight productized services for Shopify operators — five Shopify-tuned deployments of the Operations Algorithms canonicals, three Shopify-native products. From mom-and-pop to multi-store portfolios. For: Shopify store owners · DTC founders · Shopify-Plus operators · DTC brand holdcos · Shopify agencies Flagship: multi-store-portfolio-intelligence , { name: "Shopify-native operations", description: "Products that only make sense in the Shopify context — workflow automation, multi-store portfolio intelligence, audit-shaped consulting.", products: [ "shopify-operations-workflow-automation", "multi-store-portfolio-intelligence", "shopify-operations-audit", ], }, ], buyerPersonas: [ "Shopify store owners", "DTC founders", "Shopify-Plus operators", "DTC brand holdcos", "Shopify agencies", ], embeddedCaseStudies: [], competitorContext: ["Klaviyo Predictive", "Triple Whale", "Lifetimely"], }; This suite serves Shopify operators across four buyer tiers — mom-and-pop store, single founder growing data-driven, established brand (possibly multi-store), and portfolio-level multi-brand operators. The packaging on each product handles the buyer range; the products themselves are the same. The first tier is honestly described as *Shopify deployments of products that already exist in the Operations Algorithms Suite* — same modeling backbones, with Shopify-specific data integration and storefront-aware deployment. The cross-links go to the canonical pages; the work isn't duplicated. Tier 2 is Shopify-native — multi-store portfolio intelligence in particular has no equivalent elsewhere. The positioning principle (kept literally from the locked decisions): operations work, not dashboards. Output is action — auto-routing, auto-pricing, auto-personalization, auto-replenishment — not prettier charts. ### Storefront & customer intelligence Shopify-tuned deployments of the canonical Operations Algorithms products — same models, Shopify-specific data integration, storefront-aware deployment. - Demand Forecasting for Shopify — A Shopify-tuned deployment of the canonical Demand Forecasting & Inventory Engine — wired to Shopify's Orders API, Inventory API, and per-channel data, integrated with the operator's replenishment workflow. (https://orientedplatforms.com/suites/shopify-ops-intelligence/demand-forecasting-shopify) - Dynamic Pricing for Shopify — A Shopify-tuned deployment of the canonical Dynamic Pricing & Promotion Engine — wired to Shopify Discounts, Shopify Functions for custom pricing logic, and the storefront experimentation infrastructure. (https://orientedplatforms.com/suites/shopify-ops-intelligence/dynamic-pricing-shopify) - Customer Clustering for Shopify — A Shopify-tuned deployment of the canonical Customer Clustering & LTV Engine — uses Shopify Customer and Orders data plus metafields, syncs results to Klaviyo and Shopify Audiences for activation. (https://orientedplatforms.com/suites/shopify-ops-intelligence/customer-clustering-shopify) - Real-Time Personalization for Shopify — A Shopify-tuned deployment of the canonical Real-Time Personalization API — surfaces recommendations through Shopify theme app extensions, native storefront sections, or headless storefront API integration. (https://orientedplatforms.com/suites/shopify-ops-intelligence/personalization-shopify) - Repeat-Purchase & Churn for Shopify — A Shopify-tuned deployment of the canonical Churn Prediction & Retention Engine — handles both transactional repeat-purchase prediction and subscription-aware churn (Recharge / Bold / Shopify Subscriptions integration), wires reactivation triggers into Klaviyo flows. (https://orientedplatforms.com/suites/shopify-ops-intelligence/repeat-purchase-churn-shopify) ### Shopify-native operations Products that only make sense in the Shopify context — workflow automation, multi-store portfolio intelligence, audit-shaped consulting. - Shopify Operations Workflow Automation — An integrated operations-workflow layer — Shopify Flow for the standard triggers, custom orchestration where Flow's limits run out, and the cross-workflow coordination that the point-app stack misses. (https://orientedplatforms.com/suites/shopify-ops-intelligence/shopify-operations-workflow-automation) - Multi-Store Portfolio Intelligence — A portfolio platform — ETL across multiple Shopify stores into a unified analytical layer, cross-store and cross-brand dashboards, shared signal extraction (which products cross-perform, which customer patterns repeat across brands), portfolio-level operating alerts. (https://orientedplatforms.com/suites/shopify-ops-intelligence/multi-store-portfolio-intelligence) - Shopify Operations Audit — A 2-4 week audit of the store's operations stack — current app inventory and gap analysis, workflow-optimization opportunities, data-infrastructure assessment, prioritized recommendations with effort-and-impact scoring. Packaged as an action plan the operator's team executes (or that we execute via the other Shopify Suite products). (https://orientedplatforms.com/suites/shopify-ops-intelligence/shopify-operations-audit) --- ## Venture Capital Suite URL: https://orientedplatforms.com/suites/venture-capital Date: 2026-06-11 Summary: Seven productized services for VC funds — sector mapping, people-level deal signal, evaluation, portfolio pulse, and LP communications. Lean and honestly scoped against the smaller buyer pool. For: Partners · Principals · Associates · IR / fundraise teams Flagship: founder-network-intelligence , { name: "Portfolio + LP", description: "Cross-portco visibility, disciplined follow-on decisions, fund communications.", products: [ "portfolio-pulse-dashboard", "follow-on-decision-engine", "fund-communications-engine", ], }, ], buyerPersonas: ["Partners", "Principals", "Associates", "IR / fundraise teams"], embeddedCaseStudies: [], competitorContext: [ "PitchBook", "Affinity", "Harmonic", "Visible.vc", "Standard Metrics", ], }; VC has the most-overlap-with-PE of any suite we build — sourcing, monitoring, LP comms all rhyme. We kept the lineup *tight* and honest: four pre-deal products, three portfolio-and-LP products, no padding. The flagship is the one that's genuinely scarce in the market — people-level founder tracking before the company exists. The buyer pool is smaller than HF or PE — ~2,000 active VC funds globally — and the commodity products (deal sourcing, portfolio monitoring) are crowded. The two products that earn their place are the founder-network layer (no good off-the-shelf equivalent) and the operational discipline products that pair with it. Across both tiers, the bar is what production work demands. None of it is the differentiator; it's the ante. ### Deal pipeline Mapping the space, finding the founders before the companies exist, ranking the companies that do exist, evaluating the deal in front of you. - Sector Mapping Engine — An auto-updating sector mapping platform — landscape diagrams with company-activity signals (funding, hiring, product launches, supplier-customer mention graphs) refreshing daily, navigable from sector down to individual company. (https://orientedplatforms.com/suites/venture-capital/sector-mapping-engine) - Founder Network Intelligence — A people-level tracking layer — monitors departures from a curated 'talent watchlist' of notable companies, surfaces clusters and individuals to the partners with context (role, tenure, who they worked with), refreshes daily. (https://orientedplatforms.com/suites/venture-capital/founder-network-intelligence) - Deal-Sourcing & Signal Platform — A scoring pipeline that complements PitchBook and Affinity — ingests startup-database structured data plus unstructured signals (technical hiring, GitHub activity, product launches, supplier-relationship graph), applies your fund's thesis-specific scoring, and feeds your CRM weekly. (https://orientedplatforms.com/suites/venture-capital/deal-sourcing-signal-platform) - Startup Evaluation Engine — A packaged evaluation report per deal — automated financial-model review and cap-table analysis, founder-background research with structured outputs, market-size triangulation, comparable-company benchmarking. Delivered as a partner-readable document for the investment committee. (https://orientedplatforms.com/suites/venture-capital/startup-evaluation-engine) ### Portfolio + LP Cross-portco visibility, disciplined follow-on decisions, fund communications. - Portfolio Pulse Dashboard — A portfolio dashboard built on direct integrations into the systems your portcos already use — Stripe for revenue, Mercury for cash, AWS/GCP billing for technical-spend, GitHub for engineering velocity. Read-only, opt-in per portco, refreshed daily. (https://orientedplatforms.com/suites/venture-capital/portfolio-pulse-dashboard) - Follow-on Decision Engine — A decision-support layer that takes the fund's reserves, the portco's current performance and trajectory, and the round terms — outputs a structured recommendation against the fund's discipline rules with documented assumptions. (https://orientedplatforms.com/suites/venture-capital/follow-on-decision-engine) - Fund Communications Engine — An LLM-and-templating layer covering the fund's recurring and one-off communications — investor updates, LP letters, fundraise materials (data room, pitch deck) — drafted from portfolio data with the fund's voice and finalized by the IR team. (https://orientedplatforms.com/suites/venture-capital/fund-communications-engine) --- # Products — full descriptions ## AI Implementation Audit URL: https://orientedplatforms.com/suites/ai-implementation/ai-implementation-audit Suite: ai-implementation Tier: Strategy & engagement Engagement: 2–4 week sprint · packaged roadmap Buyer: COOs · Owner-operators · Heads of operations · CIOs Problem: Every operator knows AI matters. Most can't articulate where it fits in their specific business, which use cases would actually pay back, and what the implementation path looks like. The result is either no action or scattered point-app experiments with no through-line. Deliverable: A productized 2-4 week audit — operations mapped, candidate AI use cases identified, each scored on effort and impact, packaged as a roadmap document with prioritized action plan. Related: ai-transformation-engagement , { q: "What do you actually look at during the audit?", a: "Current operations and where the friction is. Data infrastructure and what's tracked. Software stack and where the AI-shaped gaps are. Team capabilities and where new tools would have leverage. Customer-facing surfaces. Internal workflows. Per-engagement, the focus depth varies by business size and industry.", }, { q: "Does this work for blue-collar businesses (HVAC, electricians, solar, etc.)?", a: "Yes — these are exactly the kinds of established operating businesses the audit was built for. The audit focuses on the operations that are actually there: scheduling, dispatch, customer comms, quote generation, invoicing, follow-up. The same checklist applied differently than for a software company.", }, { q: "What does the deliverable document look like?", a: "5–15 pages depending on business complexity. Partner-readable. Use-case list prioritized by effort and impact. Implementation-path notes per use case. Working session to walk through with the operator's team.", }, { q: "Pricing?", a: "Fixed-fee per audit, scoped to business size and complexity. Discovery call covers scope.", }, ], }; ## What this is The entry point to AI implementation. Three components: - **Discovery.** Interviews with the operating leadership. Operations mapping. Data and software inventory. Customer-and-workflow surface inventory. - **Analysis.** Candidate AI use cases identified, scored on effort and impact. Implementation-path notes per use case. Prioritization recommendation. - **Roadmap document.** Partner-readable summary, prioritized action plan, working session. The audit checklist itself is the product. It compounds across engagements — each new audit refines the checklist; every operator benefits from the prior audits being incorporated into the methodology. ## What you get - The audit document. - The prioritized use-case list with scoring. - Working session with your team. - Optional: hand-off to the other AI Implementation products if you want execution support. FAQ: - Q: Is this a sales-funnel for the Transformation Engagement? A: The audit is fixed-fee and standalone. Roughly half the audit clients execute the recommendations internally or with another vendor; half come back to us for some piece. Either path is fine — the audit's value isn't conditional on what comes next. - Q: What do you actually look at during the audit? A: Current operations and where the friction is. Data infrastructure and what's tracked. Software stack and where the AI-shaped gaps are. Team capabilities and where new tools would have leverage. Customer-facing surfaces. Internal workflows. Per-engagement, the focus depth varies by business size and industry. - Q: Does this work for blue-collar businesses (HVAC, electricians, solar, etc.)? A: Yes — these are exactly the kinds of established operating businesses the audit was built for. The audit focuses on the operations that are actually there: scheduling, dispatch, customer comms, quote generation, invoicing, follow-up. The same checklist applied differently than for a software company. - Q: What does the deliverable document look like? A: 5–15 pages depending on business complexity. Partner-readable. Use-case list prioritized by effort and impact. Implementation-path notes per use case. Working session to walk through with the operator's team. - Q: Pricing? A: Fixed-fee per audit, scoped to business size and complexity. Discovery call covers scope. --- ## AI Transformation Engagement URL: https://orientedplatforms.com/suites/ai-implementation/ai-transformation-engagement Suite: ai-implementation Tier: Strategy & engagement Engagement: 6–18 month engagement · principal-led Buyer: CEOs · COOs · CIOs · GP principals · Board sponsors Problem: Businesses committing to real AI transformation need a partner that can carry the strategy AND the implementation across multiple quarters. The market is bifurcated: strategy consultancies that don't build, and engineering firms that don't strategize. The transformation needs both. Deliverable: A multi-quarter engagement covering strategy, implementation, integration, and team training. Principal-led (Bogdan in the discovery and architecture phases, ongoing oversight throughout). Outcome: AI deployed in production across the use cases identified during strategy. Related: ai-implementation-audit, document-intelligence-engine, process-automation-agents , { q: "How is this different from the per-project AI agency model?", a: "Agencies typically build per-project — scoped engagement, fixed deliverable, hand-off. The Transformation Engagement is multi-quarter strategy-plus-build — the same team that scopes the program executes the program, with continuity across the use cases. Different commercial shape and different depth.", }, { q: "What does 'principal-led' actually mean in practice?", a: "Bogdan is in the discovery and architecture conversations directly. Implementation work is collaborative between Bogdan and the team. Project management and account oversight stay with Bogdan throughout. The engagement doesn't degrade to junior-staff execution after the strategy phase.", }, { q: "What's the typical engagement structure?", a: "Quarter 1: strategy and architecture, paired with a fast-shipping pilot on the highest-leverage use case. Quarters 2-4: build-out across additional use cases identified in strategy. Optional Quarters 5+: ongoing operation and expansion. Each quarter is committable in advance or extendable.", }, { q: "Pricing?", a: "Scoped to business size and engagement depth. Discovery call covers scope. No retainer; per-quarter commitments with optional extension.", }, ], }; ## What this is The flagship engagement. A genuinely strategic partnership for businesses that are ready to commit to a real AI transformation — and want the strategy and the build under one roof. Four phases, with overlap rather than hard handoffs: - **Strategy.** Where AI fits in the business. Which use cases pay back fastest. Which use cases are foundational for the others. The roadmap. - **Architecture and pilot.** The technical foundation. The first use case shipped to production within the first quarter as a proof-of-shape. - **Build-out.** Additional use cases through subsequent quarters. Each builds on the foundation rather than starting over. - **Operation and team.** The transition from build-engagement to ongoing operation. Team training. Documentation that survives the engagement ending. ## How it's built Per-engagement. The architecture decisions are made against the business's specific data, software stack, and operating context. The bar across the engagement: production-grade. Idempotent processing, observability, capacity under burst, deployable rollbacks — the engineering bar we hold across the catalogue. ## What you get - The strategy roadmap. - The architectural foundation. - AI deployed in production across the use cases identified. - Team training and documentation that lasts. - Principal-level oversight throughout the engagement, not just at the start. FAQ: - Q: How is this different from Tenex or other AI-transformation firms? A: Tenex is excellent at the strategy-and-program-management half — change management, executive education, ROI frameworks. Our differentiation is depth on the build side. Tenex's clients describe their model as 'we set strategy, we coordinate execution.' Our model is 'we set strategy AND we build the system.' If the engagement requires real engineering, this fits. If it's primarily org-design and change management, Tenex is a better choice. - Q: How is this different from the per-project AI agency model? A: Agencies typically build per-project — scoped engagement, fixed deliverable, hand-off. The Transformation Engagement is multi-quarter strategy-plus-build — the same team that scopes the program executes the program, with continuity across the use cases. Different commercial shape and different depth. - Q: What does 'principal-led' actually mean in practice? A: Bogdan is in the discovery and architecture conversations directly. Implementation work is collaborative between Bogdan and the team. Project management and account oversight stay with Bogdan throughout. The engagement doesn't degrade to junior-staff execution after the strategy phase. - Q: What's the typical engagement structure? A: Quarter 1: strategy and architecture, paired with a fast-shipping pilot on the highest-leverage use case. Quarters 2-4: build-out across additional use cases identified in strategy. Optional Quarters 5+: ongoing operation and expansion. Each quarter is committable in advance or extendable. - Q: Pricing? A: Scoped to business size and engagement depth. Discovery call covers scope. No retainer; per-quarter commitments with optional extension. --- ## Alternative Data Signal Engine URL: https://orientedplatforms.com/suites/hedge-fund/alternative-data-signal-engine Suite: hedge-fund Tier: Alpha layer Engagement: 8–14 week build · ongoing data ops Buyer: Quant PMs · CIOs · Research bench leads Problem: The data you want lives outside the canonical feeds, and the pipeline that ingests it cleanly — point-in-time, backfilled, idempotent — doesn't yet exist. Deliverable: A production pipeline that ingests one or more unconventional datasets, normalizes against a fund-internal schema, and serves processed factor scores, back-tested signals, and event-time alerts to the research stack. Related: trade-credit-supply-chain-score, consumer-spending-foot-traffic-dashboard, cross-lingual-news-filings-intelligence , { q: "What datasets have you actually integrated?", a: "Credit-card transaction panels (consumer and trade-credit), satellite imagery (vegetation indices, parking-lot counts), shipping manifests, foot-traffic, a handful of vertical-specific feeds we won't name. The integration shape is the same regardless — schema validation, idempotency, replay, backfill — so a dataset we haven't shipped doesn't change the engagement materially.", }, { q: "Do you produce the signals or just the pipeline?", a: "Both. The default deliverable is the pipeline plus a baseline signal generator that walks forward against your backtest infra. Funds with a research bench take the pipeline and replace the signal layer with their own. Funds without one keep ours.", }, { q: "What's the relationship to the Trade-Credit Score and Foot-Traffic Dashboard products?", a: "Those are ready-made data products — subscribe, get the score. This engine is the custom build for funds that want a unique dataset integrated end-to-end. The two patterns coexist on purpose: pre-built where the dataset is shared, custom where the edge requires it isn't.", }, { q: "Pricing?", a: "Scoped against the dataset, the historical depth required, and the destination. The discovery call covers both. No retainer.", }, ], }; ## What this is A custom pipeline for funds that have identified a specific alt-data signal hypothesis and need the production-grade plumbing to test, deploy, and operate against it. The engagement covers four bands: - **Ingestion.** Schema validation at the boundary, idempotent writes, replay from any checkpoint, backfill of the historical depth your backtest infra needs. - **Normalization.** Point-in-time alignment (no look-ahead), survivorship correction, vendor-format → fund-internal schema mapping. Universe resolution against your master security file. - **Modeling.** Feature engineering and the factor scoring layer, walk-forward backtested against your existing research infra. Baseline signal generator that your bench can take, replace, or extend. - **Attribution.** The data joins that let post-hoc analysis distinguish signal from market beta, sector beta, and the four or five factors the signal was supposed to be orthogonal to. ## How it's built Default stack: Python (Polars / Pandas for hot paths, DuckDB for ad-hoc), Postgres or your fund's existing warehouse for canonical storage, Prefect or Airflow for orchestration. ML modeling in scikit-learn / LightGBM, with a slim PyTorch layer when neural feature extraction is on-thesis (it usually isn't for tabular alt-data). The stack adapts — the bar doesn't. ## What you get - A production pipeline. Wired to your orchestrator. Idempotent. - Backfilled history to the depth required for walk-forward. - A baseline signal generator with documented hyperparameters and tracked performance. - Attribution data joins. - Runbooks for the ops your team will own after handoff. FAQ: - Q: We already have a data engineering team. What's different about this engagement? A: If your team has the bandwidth and the alt-data plumbing reps, this isn't the right fit. We come in when there's a specific dataset and a specific signal hypothesis but no clean path from one to the other — and the team you'd normally lean on is busy keeping the core feeds healthy. We deliver the path, then hand the operation back. - Q: What datasets have you actually integrated? A: Credit-card transaction panels (consumer and trade-credit), satellite imagery (vegetation indices, parking-lot counts), shipping manifests, foot-traffic, a handful of vertical-specific feeds we won't name. The integration shape is the same regardless — schema validation, idempotency, replay, backfill — so a dataset we haven't shipped doesn't change the engagement materially. - Q: Do you produce the signals or just the pipeline? A: Both. The default deliverable is the pipeline plus a baseline signal generator that walks forward against your backtest infra. Funds with a research bench take the pipeline and replace the signal layer with their own. Funds without one keep ours. - Q: What's the relationship to the Trade-Credit Score and Foot-Traffic Dashboard products? A: Those are ready-made data products — subscribe, get the score. This engine is the custom build for funds that want a unique dataset integrated end-to-end. The two patterns coexist on purpose: pre-built where the dataset is shared, custom where the edge requires it isn't. - Q: Pricing? A: Scoped against the dataset, the historical depth required, and the destination. The discovery call covers both. No retainer. --- ## Building Health & Maintenance Engine URL: https://orientedplatforms.com/suites/real-estate/building-health-maintenance-engine Suite: real-estate Tier: For RE operators Engagement: 12–20 week build · ongoing IoT and data ops Buyer: Facility teams · Property managers · REIT engineering · Large operators Problem: HVAC, elevator, and boiler failures are expensive to fix on emergency timelines and cheap to prevent on planned timelines. The data exists — sensor telemetry, work-order history, weather — but the team that pulls it together to predict failures hasn't been built. Deliverable: An IoT-and-ML platform that ingests sensor telemetry from critical equipment, fuses with work-order history and weather data, produces a Building Health Score per asset and a recommended preventive-maintenance schedule. Related: tenant-intelligence-engine , { q: "What's the prediction window?", a: "Failure-prediction reliably lands in the 14–60 day window for the major equipment classes. Shorter than 14 days is hard (failure-onset signal is often too late); longer than 60 days has noise from too many intervening variables. The engagement sets expectations on this explicitly.", }, { q: "How does the Building Health Score work?", a: "Composite per-asset score across equipment-health dimensions — HVAC efficiency, water and energy consumption anomalies, predictive-maintenance alerts open, work-order backlog. Comparable across assets in the portfolio. The score is descriptive, not prescriptive — it surfaces the assets needing attention.", }, { q: "What's the typical ROI?", a: "Preventive vs. emergency maintenance costs are typically 3-5× different per equipment-class incident; energy-efficiency improvements from anomaly detection are typically 5-15% on conditioned-square-foot energy spend. The ROI math is per-portfolio; the engagement scopes a baseline measurement and a measurement-after-deployment plan.", }, { q: "Pricing?", a: "Implementation-heavy — scoped against sensor deployment scope and portfolio breadth. Discovery call covers both.", }, ], }; ## What this is A predictive-maintenance and building-operations platform for portfolios that take operating costs seriously. Three layers: - **Sensor and data ingestion.** IoT telemetry where available (BACnet, Modbus, Niagara stacks), work-order history from the operator's CMMS, weather feeds for seasonal correlation, energy and water consumption from utility-billing or sub-metering. - **Predictive modeling.** Per-equipment-class failure prediction (HVAC, elevators, boilers, pumps), anomaly detection on consumption telemetry, planned-maintenance scheduling optimization. - **Operator surface.** Building Health Score per asset, prioritized work-order suggestions, comparable rankings across the portfolio for the facility-team dispatcher. ## How it's built Time-series anomaly detection (statistical baselines plus LSTM-class models where the data volume justifies), per-equipment-class failure prediction models trained on the operator's historical failure-and-maintenance data. CMMS integration (UpKeep, Brightly, MaintainX) where the operator uses one. Sensor-deployment piece coordinated with the operator's facilities team. ## What you get - Sensor-and-data-source integration plan. - Per-equipment-class predictive models. - Building Health Score across the portfolio. - Operator dashboard with prioritized maintenance suggestions. - Quarterly model refresh as the operator's failure history accumulates. FAQ: - Q: Most of our buildings don't have IoT sensors. How does that work? A: Two paths. Where sensors exist (newer commercial buildings, recently-retrofitted assets), we integrate directly. Where they don't, the engagement includes a sensor-deployment plan — typically a small set of high-value sensors per asset (HVAC system, elevator motor, boiler) rather than blanketing the building. We're upfront about the deploy-and-data-collect window before predictions are useful. - Q: What's the prediction window? A: Failure-prediction reliably lands in the 14–60 day window for the major equipment classes. Shorter than 14 days is hard (failure-onset signal is often too late); longer than 60 days has noise from too many intervening variables. The engagement sets expectations on this explicitly. - Q: How does the Building Health Score work? A: Composite per-asset score across equipment-health dimensions — HVAC efficiency, water and energy consumption anomalies, predictive-maintenance alerts open, work-order backlog. Comparable across assets in the portfolio. The score is descriptive, not prescriptive — it surfaces the assets needing attention. - Q: What's the typical ROI? A: Preventive vs. emergency maintenance costs are typically 3-5× different per equipment-class incident; energy-efficiency improvements from anomaly detection are typically 5-15% on conditioned-square-foot energy spend. The ROI math is per-portfolio; the engagement scopes a baseline measurement and a measurement-after-deployment plan. - Q: Pricing? A: Implementation-heavy — scoped against sensor deployment scope and portfolio breadth. Discovery call covers both. --- ## Churn Prediction & Retention Engine URL: https://orientedplatforms.com/suites/operations-algorithms/churn-prediction-retention-engine Suite: operations-algorithms Tier: Customer intelligence Engagement: 6–10 week build · ongoing operation Buyer: Heads of growth · Customer success leads · CMOs Problem: Churn is the slow-moving alpha — most businesses know their aggregate churn rate but don't predict which customers will churn next quarter or what the underlying risk driver is. Deliverable: A classification layer per customer — churn probability with confidence bands, risk-driver attribution (why the model thinks this customer is at risk), and retention-action recommendations tied to the predicted risk drivers. Related: customer-clustering-ltv-engine, real-time-personalization-api , { q: "How does the risk-driver attribution work?", a: "SHAP-value-based attribution per prediction — which features drove the model's risk assessment. The customer success or marketing team sees not just 'high risk' but 'high risk because: usage declined 30% over 60 days, support tickets unresolved, account-owner changed.' Actionable, not just descriptive.", }, { q: "What about the retention-action recommendation layer?", a: "Per-risk-driver, the engine attaches the retention actions that have worked historically — for the 'usage declined' driver, that might be a usage-revival outreach; for the 'support tickets unresolved' driver, an executive escalation; for the 'account-owner changed' driver, a re-onboarding cycle. The retention library is per-business; we build it during the engagement.", }, { q: "How is this different from the Tenant Intelligence Engine in the RE Suite?", a: "Same shape, different domain. The RE version is built for residential/commercial tenant data; this is built for general customer data. Both use the same modeling backbone; the difference is feature engineering and the retention-action library. We list both because the buyers are different (property operator vs. CMO).", }, { q: "Pricing?", a: "Scoped to data complexity and the integration depth. Discovery call covers both.", }, ], }; ## What this is A churn-prediction-plus-action layer over the customer base. Three components: - **Churn prediction.** Per-customer probability of churn in the relevant future window (30 / 60 / 90 days depending on the business). Confidence bands. - **Risk-driver attribution.** SHAP-value-based per-prediction. The customer success team sees the why, not just the what. - **Retention-action library.** Per-driver action recommendations grounded in the business's historical retention success. ## How it's built LightGBM with monotonic constraints for interpretability, SHAP for attribution, retention-library curated during the engagement with the customer success team. Integration into the business's CRM and support stack for surface. ## What you get - The churn-prediction model. - The risk-driver attribution layer. - The retention-action library. - CRM and support-stack integration. - Quarterly model refresh. FAQ: - Q: Doesn't every SaaS now have built-in churn prediction? A: Built-in churn prediction often works for the SaaS's intended use case (annual SaaS subscriptions with usage-driven signals). For businesses with more complex buying patterns — multi-product subscriptions, B2B with renewal-decision committees, transactional retail with intermittent purchase — the built-ins underperform. Custom models capture the structure the built-ins miss. - Q: How does the risk-driver attribution work? A: SHAP-value-based attribution per prediction — which features drove the model's risk assessment. The customer success or marketing team sees not just 'high risk' but 'high risk because: usage declined 30% over 60 days, support tickets unresolved, account-owner changed.' Actionable, not just descriptive. - Q: What about the retention-action recommendation layer? A: Per-risk-driver, the engine attaches the retention actions that have worked historically — for the 'usage declined' driver, that might be a usage-revival outreach; for the 'support tickets unresolved' driver, an executive escalation; for the 'account-owner changed' driver, a re-onboarding cycle. The retention library is per-business; we build it during the engagement. - Q: How is this different from the Tenant Intelligence Engine in the RE Suite? A: Same shape, different domain. The RE version is built for residential/commercial tenant data; this is built for general customer data. Both use the same modeling backbone; the difference is feature engineering and the retention-action library. We list both because the buyers are different (property operator vs. CMO). - Q: Pricing? A: Scoped to data complexity and the integration depth. Discovery call covers both. --- ## Consumer Spending & Foot-Traffic Dashboard URL: https://orientedplatforms.com/suites/hedge-fund/consumer-spending-foot-traffic-dashboard Suite: hedge-fund Tier: Alpha layer Engagement: Subscription · weekly dashboard refresh · CSV + dashboard delivery Buyer: Consumer L/S funds · Lower-AUM consumer specialists Problem: Consumer earnings are a four-times-a-year event, but the spending and traffic data underneath move weekly. The earnings surprise was visible in card-spend three weeks earlier — your team just didn't have the dashboard to see it. Deliverable: Weekly dashboards combining anonymized card spend (US consumer) and foot-traffic (mapped to ticker via store-location databases) — earnings-window trend detection for the names and themes consumer funds trade. Related: alternative-data-signal-engine, trade-credit-supply-chain-score , { q: "Which universe?", a: "US consumer-facing public companies — roughly 400 names where card-spend and foot-traffic both have signal. Restaurants, retail, services, leisure, certain consumer-products SKUs sold through traceable channels. Coverage decisions are documented per name.", }, { q: "What's the dashboard look like?", a: "Per-name view: weekly card-spend YoY, weekly foot-traffic YoY, an earnings-window flag when either series diverges materially from consensus revenue expectation. Theme views aggregate the per-name signals by category (QSR, off-price retail, etc.). CSV export for everything.", }, { q: "We're a $200M AUM fund — is the data licensed for our size?", a: "Yes. The upstream panel and traffic licenses pass through with no AUM cap. Pricing on our side scales with seat count and refresh cadence, not AUM.", }, { q: "Pricing?", a: "Tiered by seat count and refresh cadence. Discovery call covers both.", }, ], }; ## What this is A ready-made dashboard for consumer-focused L/S equity funds that want spending and traffic signal without staffing the panel-cleanup team. Two data planes, one dashboard: - **Card-spend signal.** Anonymized credit-card transaction panel, mapped to ticker via a maintained merchant-to-name resolution table. Weekly YoY with seasonal adjustment. - **Foot-traffic signal.** Anonymized device-level location data, mapped to store locations via a maintained store-locator database. Weekly YoY normalized for store-count changes. A name flags when either series diverges materially from the consensus revenue trajectory in the eight-week window leading to the next earnings date — the period where alt-data signal is most actionable against the next print. ## How it's built Universe resolution is the work: every quarter we re-run the merchant-string-to-ticker matching, every quarter the store-locator database gets a fresh sync against the master security file. Brand consolidations, divestitures, and the long tail of misattributed transactions are tracked manually with the resolution layer. The signal generation on top of clean data is the easy half. ## What you get - Per-name weekly view: card-spend YoY, foot-traffic YoY, earnings-window divergence flag. - Theme aggregates by category. - CSV exports. - Documented coverage decisions per name (what's in, what's excluded, why). - A monthly methodology note when the resolution layer or signal model shifts. FAQ: - Q: We can buy card-spend from the panel directly. Why this? A: Because the panel data is raw and the ticker mapping is the work. We do the universe resolution (matching merchant-name strings to ticker, handling brand consolidation, dealing with the long tail of misattributed transactions), the seasonal-adjustment, and the earnings-window framing. What you get is the dashboard, not the panel — most consumer specialist funds we talk to don't want to staff the panel-cleanup team. - Q: Which universe? A: US consumer-facing public companies — roughly 400 names where card-spend and foot-traffic both have signal. Restaurants, retail, services, leisure, certain consumer-products SKUs sold through traceable channels. Coverage decisions are documented per name. - Q: What's the dashboard look like? A: Per-name view: weekly card-spend YoY, weekly foot-traffic YoY, an earnings-window flag when either series diverges materially from consensus revenue expectation. Theme views aggregate the per-name signals by category (QSR, off-price retail, etc.). CSV export for everything. - Q: We're a $200M AUM fund — is the data licensed for our size? A: Yes. The upstream panel and traffic licenses pass through with no AUM cap. Pricing on our side scales with seat count and refresh cadence, not AUM. - Q: Pricing? A: Tiered by seat count and refresh cadence. Discovery call covers both. --- ## Contract & Compliance Review Engine URL: https://orientedplatforms.com/suites/ai-implementation/contract-compliance-review-engine Suite: ai-implementation Tier: Document & knowledge intelligence Engagement: 6–10 week build · ongoing operation Buyer: General Counsel · Compliance leads · Procurement teams · Operations Problem: Contracts arrive at the rate of business growth, regulatory environment shifts, internal policies update — and the legal-and-compliance team reads every document by hand to catch what's off-standard or non-compliant. The pace makes thorough review the exception rather than the rule. Deliverable: An AI review layer for the contract and compliance document corpus — extracts canonical clauses, flags off-standard terms against the business's precedent, checks policy compliance against regulatory and internal standards, surfaces anomalies for legal review. Related: document-intelligence-engine, legal-compliance-document-summarizer , { q: "What's the policy-compliance layer?", a: "Per-business: the legal and compliance team configures the rule set — regulatory standards the business operates under (HIPAA for healthcare-adjacent, SOC 2 for SaaS, PCI for payment-processing-adjacent), internal policies (vendor-engagement requirements, data-handling standards, conflict-of-interest rules). Documents get checked against the rule set; non-compliant or ambiguous-compliant documents get flagged.", }, { q: "Can it draft response letters?", a: "For the routine cases (renewal letters, standard non-disclosure responses, scheduled notifications), yes — drafts in the business's voice, the legal team finalizes. For the judgment-required cases (negotiation, novel-issue response), the engine surfaces the issue for human handling rather than drafting.", }, { q: "What about contract negotiation support?", a: "Off-standard-term flagging surfaces the negotiation points. The engine doesn't negotiate; it tells the legal team where the negotiation will be. Some clients pair this with the AI Transformation Engagement to deploy negotiation-support tools downstream.", }, { q: "Pricing?", a: "Scoped to document volume and the breadth of compliance regimes. Discovery call covers both.", }, ], }; ## What this is A review-acceleration layer for legal and compliance teams. Three layers: - **Clause extraction.** Canonical clauses (term, termination, indemnity, change-of-control, MFN, exclusivity, transfer restrictions, etc.) extracted with confidence scoring. - **Off-standard flagging.** Clauses benchmarked against the business's contract precedent. Anomalies flagged with confidence. - **Policy compliance.** Per-business rule set applied against incoming documents. Compliance gaps surfaced for legal review. ## How it's built LayoutLM-class extraction for the structured fields, BERT-class clause models fine-tuned on the legal corpus, embedding-based precedent matching against the business's historical contracts. Rule-engine for the policy-compliance layer. ## What you get - The clause-extraction pipeline. - The off-standard flagging system with precedent comparison. - The policy-compliance rule engine, configured to the business's regulatory environment. - Review queue UI for the legal team. - Quarterly rule-set review and precedent-base refresh. FAQ: - Q: How is this different from the FO Legal & Compliance Summarizer? A: Same modeling backbone, different scoping. The FO version is built specifically for the family-office document corpus (trust documents, family-specific contracts, FO-jurisdiction regulatory). This is the general-business version — broader contract types, general regulatory checking, no FO-specific specializations. - Q: What's the policy-compliance layer? A: Per-business: the legal and compliance team configures the rule set — regulatory standards the business operates under (HIPAA for healthcare-adjacent, SOC 2 for SaaS, PCI for payment-processing-adjacent), internal policies (vendor-engagement requirements, data-handling standards, conflict-of-interest rules). Documents get checked against the rule set; non-compliant or ambiguous-compliant documents get flagged. - Q: Can it draft response letters? A: For the routine cases (renewal letters, standard non-disclosure responses, scheduled notifications), yes — drafts in the business's voice, the legal team finalizes. For the judgment-required cases (negotiation, novel-issue response), the engine surfaces the issue for human handling rather than drafting. - Q: What about contract negotiation support? A: Off-standard-term flagging surfaces the negotiation points. The engine doesn't negotiate; it tells the legal team where the negotiation will be. Some clients pair this with the AI Transformation Engagement to deploy negotiation-support tools downstream. - Q: Pricing? A: Scoped to document volume and the breadth of compliance regimes. Discovery call covers both. --- ## Conversational Portfolio Assistant URL: https://orientedplatforms.com/suites/family-office/conversational-portfolio-assistant Suite: family-office Tier: Consolidation Engagement: 4–8 week build · ongoing model maintenance Buyer: Principals · CFOs · Operations staff Problem: The consolidation platform has the data, but accessing it still requires knowing how to use the dashboards, or asking the CFO. Principals don't want a dashboard; they want to ask a question and get an answer. Deliverable: An LLM-powered natural-language interface on top of the Multi-Entity Consolidation Platform — accepts questions in plain English, queries the underlying data, returns answers with the supporting numbers and audit links. Related: multi-entity-consolidation-platform, liquidity-cash-forecasting-engine, family-report-drafter , { q: "What if the LLM gets the answer wrong?", a: "Every answer comes with the underlying query and the data sources cited. The principal can audit the path from question to answer. Where the question is ambiguous, the assistant asks for clarification rather than guessing. And we measure accuracy on a held-out question set per FO — model drift is detected before users notice.", }, { q: "Which LLM do you use?", a: "Commercial-API models (Claude-class, GPT-class) where the FO permits, fine-tuned on the FO's question-and-answer patterns. Where the FO requires on-prem inference, we deploy a Llama-class model with the same fine-tuning approach. Either path is documented per engagement.", }, { q: "What questions can it actually answer?", a: "Anything answerable from the consolidation platform's data — cash positions, capital-call schedules, distribution histories, allocation by asset class, exposure to specific managers or sectors, year-over-year comparisons. Where the question requires forecasting or scenario analysis, the assistant routes to the Liquidity & Cash Forecasting Engine.", }, { q: "Pricing?", a: "Scoped against question volume and the on-prem-vs-cloud decision. Discovery call covers both.", }, ], }; ## What this is The principal-facing layer of the suite. Three components: - **Natural-language query.** Question → SQL → answer, with the LLM as the translation layer. Per-FO fine-tuning on the question patterns that actually come up. - **Permission-aware execution.** All queries run in the asker's permission context; the LLM doesn't see data the user can't see. - **Auditable answers.** Every answer includes the supporting numbers and links to the source transactions. Trust is built through transparency, not through marketing. ## How it's built LLM layer (Claude-class commercial API, or Llama-class on-prem fine-tune) with a query-construction layer that translates natural language to SQL against the canonical schema. Permission enforcement at the database layer (RLS), not the LLM layer — security guarantees don't depend on model behavior. Calibration tracked against a per-FO question set. ## What you get - The assistant deployed to your FO — Slack, Teams, or web UI per preference. - Per-FO fine-tuning on your team's question patterns. - Auditable query path from question to answer. - Calibration tracking and drift detection. - Ongoing fine-tuning as new question patterns emerge. FAQ: - Q: How does it handle the privacy partitions? A: Every query runs in the user's permission context. A principal asking 'what's our cash position?' sees their own family's view; the same query from the CFO sees the consolidated picture. The LLM doesn't bypass the access controls — it queries against the row-level-security-filtered data layer. - Q: What if the LLM gets the answer wrong? A: Every answer comes with the underlying query and the data sources cited. The principal can audit the path from question to answer. Where the question is ambiguous, the assistant asks for clarification rather than guessing. And we measure accuracy on a held-out question set per FO — model drift is detected before users notice. - Q: Which LLM do you use? A: Commercial-API models (Claude-class, GPT-class) where the FO permits, fine-tuned on the FO's question-and-answer patterns. Where the FO requires on-prem inference, we deploy a Llama-class model with the same fine-tuning approach. Either path is documented per engagement. - Q: What questions can it actually answer? A: Anything answerable from the consolidation platform's data — cash positions, capital-call schedules, distribution histories, allocation by asset class, exposure to specific managers or sectors, year-over-year comparisons. Where the question requires forecasting or scenario analysis, the assistant routes to the Liquidity & Cash Forecasting Engine. - Q: Pricing? A: Scoped against question volume and the on-prem-vs-cloud decision. Discovery call covers both. --- ## Cross-Lingual News & Filings Intelligence URL: https://orientedplatforms.com/suites/hedge-fund/cross-lingual-news-filings-intelligence Suite: hedge-fund Tier: Alpha layer Engagement: 6–10 week build · monthly model retraining Buyer: Macro PMs · Event-driven PMs · Multi-strat research leads Problem: RavenPack, Bloomberg, AlphaSense — every fund has English-language news sentiment. The edge is the Chinese filings, the Brazilian regulator notices, the Japanese local press picked up three days before the wire. Deliverable: Intraday sentiment scores and event extractions for tickers, sectors, and macro themes, sourced from non-English news, regulatory filings, and social — covering the languages where your existing stack goes dark. Related: alternative-data-signal-engine, prediction-market-alpha-layer , { q: "Which languages are supported?", a: "Chinese (Simplified + Traditional), Japanese, Korean, Portuguese, Spanish, Russian, German, French — depth varies. The engagement starts by picking the two or three you actually trade in and going deep, rather than spreading thin. The named-entity recognition layer is the bottleneck for each new language, not the translation.", }, { q: "What's the source list?", a: "Per-language curated. The first engagement defines it against the universe you trade. For Chinese: top business press (Caixin, 21st Century Business Herald), regulatory filings (CSRC, HKEX), Weibo and Zhihu signal where useful. Per-language equivalents elsewhere. The curation matters more than the breadth.", }, { q: "How do you handle translation drift between source and signal?", a: "We don't translate then score. We score in the source language with a language-specific model, then surface the relevant snippet (translated) alongside the score so the analyst can audit. Translation as evidence, not as input.", }, { q: "Pricing?", a: "Scoped against language depth and source-list size. Discovery call covers both.", }, ], }; ## What this is A sentiment and event-extraction layer for the languages your English-language stack can't read. Three layers: - **Source ingestion.** Per-language sources — business press, regulatory filings (CSRC, KRX, HKEX, etc.), select social — wired into a normalized pipeline with deduplication and source-level reliability scoring. - **Per-language NER + scoring.** Language-specific named-entity recognition for the names that matter to your universe — tickers, executives, regulators, brands. Sentiment and event classification with models fine-tuned per language, not translated-then-scored. - **Delivery.** Intraday scores and event-time alerts via API. Snippets surfaced alongside scores so an analyst can audit the source. ## How it's built For each supported language: an NER model fine-tuned on financial-domain text, an event-classification head, a sentiment head, and a source-reliability scoring layer. Backbone: a multilingual transformer per language (XLM-RoBERTa-class for most, language-specific where the data justifies). Inference served behind a thin FastAPI layer. Backtest infra runs against an internal labeled set — extended each engagement against the fund's universe. ## What you get - The source list curated for your universe. - A scoring API — intraday sentiment, event classification, entity-level scores. - Snippets surfaced alongside scores (translated for the analyst, scored in source). - Backtest infra tied to your existing research stack. - A monthly model-retraining schedule and the labeled-data process behind it. FAQ: - Q: We have RavenPack. Why would we add this? A: RavenPack is English-first. The serious edge sits where everyone else is dark — Chinese consumer brands picked up on Weibo, Brazilian commodity exporters covered in Portuguese press, Korean conglomerate filings in Korean. The product is built to cover those gaps, not duplicate the English coverage you already pay for. - Q: Which languages are supported? A: Chinese (Simplified + Traditional), Japanese, Korean, Portuguese, Spanish, Russian, German, French — depth varies. The engagement starts by picking the two or three you actually trade in and going deep, rather than spreading thin. The named-entity recognition layer is the bottleneck for each new language, not the translation. - Q: What's the source list? A: Per-language curated. The first engagement defines it against the universe you trade. For Chinese: top business press (Caixin, 21st Century Business Herald), regulatory filings (CSRC, HKEX), Weibo and Zhihu signal where useful. Per-language equivalents elsewhere. The curation matters more than the breadth. - Q: How do you handle translation drift between source and signal? A: We don't translate then score. We score in the source language with a language-specific model, then surface the relevant snippet (translated) alongside the score so the analyst can audit. Translation as evidence, not as input. - Q: Pricing? A: Scoped against language depth and source-list size. Discovery call covers both. --- ## Customer Clustering & LTV Engine URL: https://orientedplatforms.com/suites/operations-algorithms/customer-clustering-ltv-engine Suite: operations-algorithms Tier: Customer intelligence Engagement: 8–12 week build · quarterly model refresh Buyer: Heads of growth · CMOs · Commercial leads Problem: Customer segmentation at most established businesses is either coarse (demographics) or absent. The business knows what it sold to whom, but the segment-level structure of the base — how customers cluster on behavior, what each cluster's lifetime value looks like — is unmodeled. Deliverable: An unsupervised clustering layer over the client's own customer-and-transaction data — surfaces behavioral segments using RFM and broader signal sets, attaches a lifetime-value forecast per segment, feeds marketing and retention decisions. Related: churn-prediction-retention-engine, real-time-personalization-api, subscription-economy-benchmarks-api , { q: "What signals does the clustering use?", a: "RFM as the baseline (recency, frequency, monetary). Plus behavioral signals — product-category affinity, channel preference, support-ticket pattern, response-to-prior-campaign signal, tenure trajectory. Per-engagement, the signal set is calibrated to what the client's data actually contains.", }, { q: "Doesn't K-means just produce 'high-value, medium, low' segments?", a: "K-means produces what you ask of it. The work is the feature engineering and the cluster-count selection — finding the segment structure that's actually decision-relevant, rather than the structure that's mathematically clean. Hierarchical methods (HDBSCAN) often work better than K-means for the real-world case where some clusters are dense and others are sparse.", }, { q: "How does the LTV forecast tie in?", a: "Per-segment lifetime-value model (BG/NBD-class for non-contractual relationships, hazard-model-based for contractual). The forecast attaches to each segment, so the marketing team sees not just 'these customers cluster together' but 'this cluster is worth $X per acquisition on a five-year horizon.'", }, { q: "Pricing?", a: "Scoped to data complexity and the deployment depth (one-time vs. integrated into the client's CRM). Discovery call covers both.", }, ], }; ## What this is Customer segmentation and lifetime-value modeling built on the client's own data, not third-party panels. Three layers: - **Feature engineering.** RFM baseline plus behavioral signals (product-category affinity, channel patterns, support interactions, campaign response). Per-engagement calibrated to the data available. - **Clustering.** HDBSCAN or hierarchical method as the default; K-means where the data structure justifies it. Cluster-count selection by silhouette + interpretation quality, not by elbow alone. - **Lifetime-value forecasting.** Per-segment LTV model — BG/NBD-class for non-contractual, hazard-model-based for contractual subscription. Documented uncertainty bands. ## How it's built Python (Polars / Pandas) for the feature engineering, scikit-learn for the clustering layer, lifetimes library plus custom hazard models for the LTV layer. Output deliverable: segment definitions, per-segment LTV forecasts, integration into the client's CRM (Hubspot, Salesforce, Klaviyo, custom). ## What you get - The segmentation model with per-segment definitions. - The LTV forecast per segment. - The CRM integration for downstream marketing use. - Documentation of the segmentation methodology — defensible to the CMO's reviewer. - Quarterly model refresh as the customer base evolves. FAQ: - Q: Why custom rather than a SaaS like Klaviyo's predictive segments? A: SaaS predictive segments are excellent for the customers that fit the SaaS's assumed data shape (e-commerce purchase-driven, mostly transactional). For businesses with richer or different data — B2B with multi-stakeholder buying processes, subscription with cohort complexity, marketplace with two-sided dynamics — a custom clustering layer captures structure SaaS misses. The deliverable is the model, not a SaaS subscription. - Q: What signals does the clustering use? A: RFM as the baseline (recency, frequency, monetary). Plus behavioral signals — product-category affinity, channel preference, support-ticket pattern, response-to-prior-campaign signal, tenure trajectory. Per-engagement, the signal set is calibrated to what the client's data actually contains. - Q: Doesn't K-means just produce 'high-value, medium, low' segments? A: K-means produces what you ask of it. The work is the feature engineering and the cluster-count selection — finding the segment structure that's actually decision-relevant, rather than the structure that's mathematically clean. Hierarchical methods (HDBSCAN) often work better than K-means for the real-world case where some clusters are dense and others are sparse. - Q: How does the LTV forecast tie in? A: Per-segment lifetime-value model (BG/NBD-class for non-contractual relationships, hazard-model-based for contractual). The forecast attaches to each segment, so the marketing team sees not just 'these customers cluster together' but 'this cluster is worth $X per acquisition on a five-year horizon.' - Q: Pricing? A: Scoped to data complexity and the deployment depth (one-time vs. integrated into the client's CRM). Discovery call covers both. --- ## Customer Clustering for Shopify URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/customer-clustering-shopify Suite: shopify-ops-intelligence Tier: Storefront & customer intelligence Engagement: 4–8 week deployment · self-serve to custom packaging Buyer: DTC operators · Shopify-Plus brands · DTC commercial leads Problem: Shopify operators run Klaviyo on default segments and Shopify Audiences on simple filters — missing the segment structure that's actually decision-relevant for marketing budget allocation and retention strategy. Deliverable: A Shopify-tuned deployment of the canonical Customer Clustering & LTV Engine — uses Shopify Customer and Orders data plus metafields, syncs results to Klaviyo and Shopify Audiences for activation. Related: customer-clustering-ltv-engine, personalization-shopify, repeat-purchase-churn-shopify , { q: "How does it integrate with Shopify Audiences?", a: "Cluster assignments sync to Shopify Audiences as custom segments; from there they're usable in Shopify Marketing campaigns and channel targeting. Sync runs daily with new-customer triggering.", }, { q: "What about Klaviyo activation?", a: "Cluster assignments sync to Klaviyo profile fields. From there the marketing team builds segment-targeted flows in Klaviyo's standard UI. The clustering layer doesn't replace Klaviyo's flow infrastructure — it informs it.", }, { q: "How is this different from Lifetimely or Reveal?", a: "Those products focus on cohort retention analytics — good descriptive tools for what's already happened. The Customer Clustering Engine produces segments for forward-looking marketing decisions. Different output, same source data.", }, { q: "Pricing?", a: "Tiered per buyer profile. Discovery call covers the right tier.", }, ], }; ## What this is The canonical Customer Clustering & LTV Engine, tuned for Shopify-native deployment. See the [canonical product page in the Operations Algorithms Suite](/suites/operations-algorithms/customer-clustering-ltv-engine) for the modeling backbone, clustering methodology, and LTV-forecasting detail. The Shopify-tuned tuning consists of: - Direct integration with Shopify Customer and Orders APIs for the feature engineering. - Shopify metafield support for custom-attribute clustering inputs. - Sync to Shopify Audiences for native marketing-campaign activation. - Sync to Klaviyo profile fields for flow-based marketing activation. ## What you get - The clustering model trained on your store's customer data. - Per-cluster LTV forecasts. - Daily sync to Shopify Audiences and Klaviyo. - Operator dashboard showing segment composition and LTV per segment. - Quarterly model refresh. FAQ: - Q: Doesn't Klaviyo already do predictive segmentation? A: Klaviyo's predictive segments work well for the customer-side prediction (next purchase date, predicted CLV). The clustering layer is different — unsupervised segment structure on the full feature space, not predicted-purchase classification. The two are complementary; many engagements end up running both with the clusters informing Klaviyo flows. - Q: How does it integrate with Shopify Audiences? A: Cluster assignments sync to Shopify Audiences as custom segments; from there they're usable in Shopify Marketing campaigns and channel targeting. Sync runs daily with new-customer triggering. - Q: What about Klaviyo activation? A: Cluster assignments sync to Klaviyo profile fields. From there the marketing team builds segment-targeted flows in Klaviyo's standard UI. The clustering layer doesn't replace Klaviyo's flow infrastructure — it informs it. - Q: How is this different from Lifetimely or Reveal? A: Those products focus on cohort retention analytics — good descriptive tools for what's already happened. The Customer Clustering Engine produces segments for forward-looking marketing decisions. Different output, same source data. - Q: Pricing? A: Tiered per buyer profile. Discovery call covers the right tier. --- ## Customer Support AI URL: https://orientedplatforms.com/suites/ai-implementation/customer-support-ai Suite: ai-implementation Tier: Workflow & operations automation Engagement: 6–10 week build · ongoing operation Buyer: VP Support · CX leads · Heads of customer experience Problem: Customer support volume scales with business growth — but support headcount can't scale proportionally without margin damage. The team's time goes to routing tickets, drafting responses to repeat questions, and escalating the edge cases that should have escalated faster. Deliverable: An AI layer over the existing ticket stack — routes tickets by category and urgency, drafts initial responses for routine queries, flags edge cases for escalation, surfaces context from prior interactions and product documentation. Related: internal-knowledge-assistant, sales-marketing-operations-ai , { q: "How does it integrate with our existing ticket system?", a: "Zendesk, Intercom, Front, Salesforce Service, custom — standard integrations for the common platforms, custom connector for the rest. The AI layer sits on top of the ticketing system rather than replacing it.", }, { q: "What about hallucination — answering customer questions wrong?", a: "Routine-question drafts are grounded in product documentation and prior support history; the agent reviews before sending. For questions where the documented answer is uncertain, the engine surfaces uncertainty rather than confident-wrong responses. Per engagement we measure draft-accuracy on a held-out set.", }, { q: "How does the escalation logic work?", a: "Per-business: the engagement defines what 'escalation' means (severity thresholds, customer-VIP rules, complaint-pattern detection, regulatory-trigger detection). The AI layer routes accordingly; the support team owns the escalation handoff.", }, { q: "Pricing?", a: "Scoped to ticket volume and integration depth. Discovery call covers both.", }, ], }; ## What this is A support-team augmentation engagement. Three layers: - **Ticket triage and routing.** Classification by category, urgency, complaint pattern. Routing to the appropriate queue or agent. - **Draft-response generation.** Routine questions get a draft response surfaced to the support agent. Agent reviews and sends; the AI doesn't auto-send. - **Context surfacing.** Prior interaction history, product documentation relevant to the ticket, customer-account context — surfaced alongside the ticket for the agent. ## How it's built LLM layer for classification and draft generation. Embedding-based retrieval over the support knowledge base for the context layer. Integration with the existing ticket platform via API. Per-engagement fine-tuning on the business's support history and product documentation. ## What you get - The routing and triage layer integrated with your ticket platform. - The draft-generation system with agent-review workflow. - The context-surfacing layer. - Quarterly accuracy review on draft-versus-sent comparison. - Documentation for the support team handing off the system. FAQ: - Q: Will customers know they're talking to AI? A: Configurable. Some businesses prefer explicit disclosure ('this draft was prepared by AI for review by your support agent'); others prefer transparent augmentation where the support agent is always the one signing the response. The engagement scopes the customer-facing posture during discovery. - Q: How does it integrate with our existing ticket system? A: Zendesk, Intercom, Front, Salesforce Service, custom — standard integrations for the common platforms, custom connector for the rest. The AI layer sits on top of the ticketing system rather than replacing it. - Q: What about hallucination — answering customer questions wrong? A: Routine-question drafts are grounded in product documentation and prior support history; the agent reviews before sending. For questions where the documented answer is uncertain, the engine surfaces uncertainty rather than confident-wrong responses. Per engagement we measure draft-accuracy on a held-out set. - Q: How does the escalation logic work? A: Per-business: the engagement defines what 'escalation' means (severity thresholds, customer-VIP rules, complaint-pattern detection, regulatory-trigger detection). The AI layer routes accordingly; the support team owns the escalation handoff. - Q: Pricing? A: Scoped to ticket volume and integration depth. Discovery call covers both. --- ## Deal-Sourcing Engine URL: https://orientedplatforms.com/suites/private-equity/deal-sourcing-engine Suite: private-equity Tier: Pre-deal Engagement: 6–10 week build · ongoing data ops Buyer: Deal teams · Sourcing analysts · GP principals Problem: PitchBook gives you the universe. The work is filtering the universe down to the 30 companies that match the thesis, ranked by signal strength, refreshed weekly so nothing gets missed while the team is in close mode on the current deal. Deliverable: A scoring pipeline that ingests structured (PitchBook-class) and unstructured (news, hiring, patents, alt-data) sources, applies your fund's thesis-specific filters, and ranks candidate targets — feeding your CRM with the top tier weekly. Related: technical-dd-engine, diligence-red-flag-engine , { q: "How do you encode our thesis?", a: "First engagement: discovery interviews with the partners and the deal team, structured against the fund's mandate. The thesis becomes a scoring rubric (sector, size, growth, margin profile, defensibility, ownership) and a set of disqualifiers. The rubric is auditable and versioned — when the thesis evolves, the rubric evolves with it.", }, { q: "What alt-data sources do you integrate?", a: "Hiring activity (LinkedIn / job-board signals), patent filings (USPTO + WIPO), product-launch tracking, supplier-and-customer mention graphs from public news, employee-review-site trajectory, executive-departure signals. Per-engagement, the source list is scoped to what actually moves the rubric for your fund's sector.", }, { q: "We've seen vendors promise '3× pipeline' — is that real?", a: "The honest answer is it depends on what your baseline is. Funds with strong existing sourcing networks see incremental lift; funds whose sourcing was reactive see a step-change. We don't promise a multiplier — we'd rather scope to a concrete outcome (e.g., top-50 surfaced weekly, partner-time on triage cut by N hours) and measure against that.", }, { q: "Pricing?", a: "Scoped against source coverage and CRM-integration depth. Discovery call covers both.", }, ], }; ## What this is A scoring pipeline that takes the world of private companies and surfaces the ones that match the fund's thesis. Three layers: - **Universe ingestion.** Structured sources (PitchBook-class) plus unstructured (news, patents, hiring, alt-data), normalized into a single candidate-company graph with daily delta tracking. - **Thesis scoring.** A rubric encoding the fund's thesis — sector, size, growth, margin profile, defensibility, ownership status — applied to each candidate. Auditable. Versioned. When the thesis evolves, so does the rubric. - **CRM hand-off.** Weekly top-tier delivery into Affinity, DealCloud, or whatever your team uses. Disqualifiers fire transparently so nothing surprises the partner when they see the list. ## How it's built Polars / DuckDB for the data layer, FastAPI for serve-side, your CRM's API for delivery. Where the universe data is public-API-accessible, we wire direct integrations; where it requires scrape-and-normalize work, we own that pipeline with documented rate-limiting and license handling. ## What you get - The rubric, versioned and auditable. - The weekly top-tier delivery into your CRM. - Disqualifier tracking — knowing what was filtered out and why. - Source-level reliability scoring so the partner reading the list knows what to trust. - Runbook for the data ops your team owns post-handoff. FAQ: - Q: We already use PitchBook + Affinity. What's different? A: Those are excellent universe and CRM tools. The work is the ranking layer on top — your fund's thesis encoded as scoring rules, ingestion of the unstructured signals PitchBook misses (hiring deltas, patent filings, supplier-relationship changes), and the weekly refresh that gets the top tier in front of the deal team without manual triage. - Q: How do you encode our thesis? A: First engagement: discovery interviews with the partners and the deal team, structured against the fund's mandate. The thesis becomes a scoring rubric (sector, size, growth, margin profile, defensibility, ownership) and a set of disqualifiers. The rubric is auditable and versioned — when the thesis evolves, the rubric evolves with it. - Q: What alt-data sources do you integrate? A: Hiring activity (LinkedIn / job-board signals), patent filings (USPTO + WIPO), product-launch tracking, supplier-and-customer mention graphs from public news, employee-review-site trajectory, executive-departure signals. Per-engagement, the source list is scoped to what actually moves the rubric for your fund's sector. - Q: We've seen vendors promise '3× pipeline' — is that real? A: The honest answer is it depends on what your baseline is. Funds with strong existing sourcing networks see incremental lift; funds whose sourcing was reactive see a step-change. We don't promise a multiplier — we'd rather scope to a concrete outcome (e.g., top-50 surfaced weekly, partner-time on triage cut by N hours) and measure against that. - Q: Pricing? A: Scoped against source coverage and CRM-integration depth. Discovery call covers both. --- ## Deal-Sourcing & Signal Platform URL: https://orientedplatforms.com/suites/venture-capital/deal-sourcing-signal-platform Suite: venture-capital Tier: Deal pipeline Engagement: 6–10 week build · weekly CRM refresh Buyer: Partners · Associates · Sourcing teams Problem: PitchBook and Affinity are excellent at the universe and the CRM. The work is the ranking layer in between — your fund's thesis encoded as scoring rules, the alt-signals PitchBook misses (hiring deltas, GitHub commit velocity, product-launch tracking), and the weekly refresh. Deliverable: A scoring pipeline that complements PitchBook and Affinity — ingests startup-database structured data plus unstructured signals (technical hiring, GitHub activity, product launches, supplier-relationship graph), applies your fund's thesis-specific scoring, and feeds your CRM weekly. Related: founder-network-intelligence, sector-mapping-engine, startup-evaluation-engine , { q: "What signal vectors do you weight?", a: "Technical hiring acceleration (eng team growth as a leading indicator), GitHub commit velocity on public repos, product-launch and feature-ship tracking, customer and partnership-mention graph, employee-review-trajectory. Per-engagement, the vectors are weighted to the fund's thesis.", }, { q: "Distinction from the Founder Network Intelligence product?", a: "Different unit of observation. Founder Network is people-level — tracks individuals across companies and surfaces them before the new company exists. Deal-Sourcing & Signal is company-level — surfaces and ranks companies that exist. Use the founder layer for the earliest-stage thesis, the company layer for series-A-and-up.", }, { q: "How does it integrate with our CRM?", a: "Affinity is the canonical case (we've shipped this most often). DealCloud, Attio, and Salesforce-based CRMs are supported. The weekly top-tier delivery posts into a configurable CRM stage with the underlying signal data attached so the partner can drill in.", }, { q: "Pricing?", a: "Scoped against signal-vector coverage and CRM-integration depth. Discovery call covers both.", }, ], }; ## What this is A scoring layer on top of the universe data your fund already pays for. Three layers: - **Multi-source ingestion.** Structured data (PitchBook, Crunchbase, sector-specific databases), unstructured signal layers (hiring, GitHub, product launches, partnership graph). Normalized into a unified company graph with daily delta tracking. - **Thesis scoring.** Per-vector weighting tuned to the fund's thesis. Sector-specific configurations where the fund's mandate spans distinct sectors. - **CRM hand-off.** Weekly top-tier delivery with signal context. The partner sees the score AND the reasons. ## How it's built Same data infrastructure as Sector Mapping Engine and Founder Network Intelligence — they're three products on a shared signal layer with different unit-of-observation. CRM integration via Affinity / DealCloud / Attio APIs. ## What you get - Per-vector signal coverage with documented data sources. - Per-thesis scoring weights, versioned. - Weekly top-tier delivery into your CRM with signal context. - Per-company drill-down to the underlying signal trajectory. - Quarterly weight-review with the partners. FAQ: - Q: Why this instead of just PitchBook's discovery tools? A: PitchBook discovery is filter-based on structured data they already have. The signal vectors that matter early — technical hiring patterns, GitHub commit velocity on a public repo, supplier-customer relationship graph shifts — those aren't in PitchBook's structured fields. This product is the scoring layer for those vectors. - Q: What signal vectors do you weight? A: Technical hiring acceleration (eng team growth as a leading indicator), GitHub commit velocity on public repos, product-launch and feature-ship tracking, customer and partnership-mention graph, employee-review-trajectory. Per-engagement, the vectors are weighted to the fund's thesis. - Q: Distinction from the Founder Network Intelligence product? A: Different unit of observation. Founder Network is people-level — tracks individuals across companies and surfaces them before the new company exists. Deal-Sourcing & Signal is company-level — surfaces and ranks companies that exist. Use the founder layer for the earliest-stage thesis, the company layer for series-A-and-up. - Q: How does it integrate with our CRM? A: Affinity is the canonical case (we've shipped this most often). DealCloud, Attio, and Salesforce-based CRMs are supported. The weekly top-tier delivery posts into a configurable CRM stage with the underlying signal data attached so the partner can drill in. - Q: Pricing? A: Scoped against signal-vector coverage and CRM-integration depth. Discovery call covers both. --- ## Demand Forecasting & Inventory Engine URL: https://orientedplatforms.com/suites/operations-algorithms/demand-forecasting-inventory-engine Suite: operations-algorithms Tier: Commercial optimization Engagement: 10–16 week build · ongoing forecast cadence Buyer: Supply chain leads · Inventory directors · Commercial leads Problem: Inventory decisions at most established businesses are made on rolling-average demand baselines that miss the early signal — demand spikes show up in the historical data after the stockout, demand lulls show up after the markdown. Deliverable: A forecasting layer at SKU grain — combines time-series baselines with external signal (macro indicators, social-and-search signal, weather, consumer-behavior priors) — feeds inventory and replenishment decisions with documented uncertainty. Related: dynamic-pricing-promotion-engine , { q: "What signals does the model use beyond historical sales?", a: "Per-engagement, the signal set is calibrated. Common adds: regional employment as a consumer-demand proxy, weather (for season-sensitive categories), search-trend data, paid-marketing-spend pacing, competitor pricing where the business tracks it. Where the business operates in a category with public consumer-spending data, that's a strong signal.", }, { q: "How are long-tail and intermittent-demand SKUs handled?", a: "Intermittent-demand modeling (Croston's class methods plus Bayesian baselines with strong priors). The forecast acknowledges uncertainty rather than producing a confident point estimate where the data doesn't support one.", }, { q: "What's the inventory-decision layer?", a: "Forecasts feed a configurable inventory policy — order-up-to, periodic-review, or whatever matches the business's purchasing constraints. The policy is configured during the engagement; the forecast plugs into it. We're explicit that we don't replace the supply-chain team's judgment — we equip it.", }, { q: "Pricing?", a: "Scoped to SKU count, channel complexity, and integration depth. Discovery call covers all three.", }, ], }; ## What this is A demand-and-inventory layer for businesses where inventory decisions matter to the P&L. Three components: - **Forecasting models.** Per-SKU, per-channel, per-region. Ensemble of statistical baselines, gradient-boosted models, and Bayesian models depending on data depth. - **Signal integration.** External signal layered onto historical sales — macro, weather, search, paid-marketing pacing. - **Inventory-decision layer.** Forecasts feed a configurable policy that produces replenishment recommendations. The supply-chain team finalizes. ## How it's built Statsmodels for the baseline time-series, Prophet for the trend-seasonality decomposition, LightGBM for the signal-augmented layer, PyMC for the Bayesian piece on sparse-history SKUs. Integration into the ERP (NetSuite, SAP, Oracle) for replenishment output. ## What you get - The forecasting model with documented uncertainty per SKU class. - The inventory-decision policy, configured. - ERP integration for the replenishment hand-off. - Quarterly model refresh. - Documentation defensible to the supply-chain audit. FAQ: - Q: Why custom instead of o9, Blue Yonder, or the rest of the supply-chain SaaS landscape? A: Those are excellent at enterprise scale where the SaaS's data model maps cleanly to the business. For mid-market businesses and for enterprises whose data shape doesn't fit (long-tail SKUs with sparse history, channel-specific demand patterns, recently-launched products), custom forecasting captures structure SaaS misses. - Q: What signals does the model use beyond historical sales? A: Per-engagement, the signal set is calibrated. Common adds: regional employment as a consumer-demand proxy, weather (for season-sensitive categories), search-trend data, paid-marketing-spend pacing, competitor pricing where the business tracks it. Where the business operates in a category with public consumer-spending data, that's a strong signal. - Q: How are long-tail and intermittent-demand SKUs handled? A: Intermittent-demand modeling (Croston's class methods plus Bayesian baselines with strong priors). The forecast acknowledges uncertainty rather than producing a confident point estimate where the data doesn't support one. - Q: What's the inventory-decision layer? A: Forecasts feed a configurable inventory policy — order-up-to, periodic-review, or whatever matches the business's purchasing constraints. The policy is configured during the engagement; the forecast plugs into it. We're explicit that we don't replace the supply-chain team's judgment — we equip it. - Q: Pricing? A: Scoped to SKU count, channel complexity, and integration depth. Discovery call covers all three. --- ## Demand Forecasting for Shopify URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/demand-forecasting-shopify Suite: shopify-ops-intelligence Tier: Storefront & customer intelligence Engagement: 6–12 week deployment · self-serve to custom packaging Buyer: DTC operators · Shopify-Plus brands · Multi-store DTC holdcos Problem: Shopify operators stockout on the hits and over-order on the slow movers — because the inventory app shows historical sales, not next-quarter demand. The forecasting infrastructure that would solve this is well-understood but rarely deployed at the operator level. Deliverable: A Shopify-tuned deployment of the canonical Demand Forecasting & Inventory Engine — wired to Shopify's Orders API, Inventory API, and per-channel data, integrated with the operator's replenishment workflow. Related: demand-forecasting-inventory-engine, dynamic-pricing-shopify, shopify-operations-workflow-automation , { q: "What packaging tier fits our store?", a: "Self-serve SaaS for mom-and-pop and single-founder stores; custom deployment for established brands with 5–50 SKU categories; multi-tenant for brand holdcos and DTC portfolios. The model is the same — the packaging differs.", }, { q: "How does it handle Shopify-specific data?", a: "Shopify metafields, draft orders, abandoned-checkout signal, Shopify Sales-Channels per-channel breakdown — all fed into the forecasting model. Where the operator uses Shopify Flow, the engine integrates with Flow triggers for replenishment workflows.", }, { q: "Is this different from Klaviyo Predictive forecasting?", a: "Klaviyo's predictive layer focuses on customer-side prediction (next purchase date, predicted spending). This product focuses on inventory-side prediction (SKU-level demand). Complementary — different operating decisions.", }, { q: "Pricing?", a: "Tiered per buyer profile — self-serve SaaS, custom deployment, multi-store portfolio. Discovery call covers the right tier.", }, ], }; ## What this is The canonical Demand Forecasting & Inventory Engine, tuned for Shopify-native integration. See the [canonical product page in the Operations Algorithms Suite](/suites/operations-algorithms/demand-forecasting-inventory-engine) for the modeling backbone, the signal-set rationale, and the technical detail. The Shopify-tuned tuning consists of: - Data integration directly with Shopify Orders API, Inventory API, and Sales Channels metadata. - Per-channel demand attribution from Shopify's channel breakdown (online store, POS, social channels, marketplaces). - Integration with Shopify Flow for the replenishment-workflow downstream side. - Theme-app-extension surface for the operator-facing layer where appropriate. The packaging tiers handle the buyer range — self-serve SaaS for mom-and-pop, custom deployment for established brands, multi-tenant for portfolio operators. ## What you get - The forecasting model deployed against your Shopify data. - Shopify-Inventory-API-wired replenishment recommendations. - Per-channel attribution where the store operates across channels. - Operator UI consistent with Shopify Admin conventions. - Quarterly model refresh. FAQ: - Q: Is this just the OAS Demand Forecasting Engine relabeled for Shopify? A: It's the same modeling backbone. What's different is the data integration (Shopify Orders / Inventory / Sales-Channels APIs as canonical sources, channel-attribution from Shopify metafields, theme-app-extension signal for the storefront-aware piece) and the deployment shape (wired to Shopify's Inventory operations rather than a generic ERP). - Q: What packaging tier fits our store? A: Self-serve SaaS for mom-and-pop and single-founder stores; custom deployment for established brands with 5–50 SKU categories; multi-tenant for brand holdcos and DTC portfolios. The model is the same — the packaging differs. - Q: How does it handle Shopify-specific data? A: Shopify metafields, draft orders, abandoned-checkout signal, Shopify Sales-Channels per-channel breakdown — all fed into the forecasting model. Where the operator uses Shopify Flow, the engine integrates with Flow triggers for replenishment workflows. - Q: Is this different from Klaviyo Predictive forecasting? A: Klaviyo's predictive layer focuses on customer-side prediction (next purchase date, predicted spending). This product focuses on inventory-side prediction (SKU-level demand). Complementary — different operating decisions. - Q: Pricing? A: Tiered per buyer profile — self-serve SaaS, custom deployment, multi-store portfolio. Discovery call covers the right tier. --- ## Diligence Red-Flag Engine URL: https://orientedplatforms.com/suites/private-equity/diligence-red-flag-engine Suite: private-equity Tier: Pre-deal Engagement: 1–2 week sprint per target · risk heatmap report Buyer: Deal teams · Operating partners Problem: Financial and legal diligence reads thousands of pages per target. The anomalies, the off-market contract clauses, the related-party transactions — they're in there, but the diligence team finds them by hand in a compressed window. Deliverable: An AI-extraction-and-review layer that ingests the data room, surfaces the anomalies and the off-market clauses, benchmarks against comparable transactions, and screens beneficial ownership against sanctions and PEP lists — delivered as a risk heatmap the deal team works against. Related: technical-dd-engine, deal-sourcing-engine , { q: "What does the heatmap actually look like?", a: "Four risk dimensions per target — financial-statement anomalies, contract-clause risk (off-market terms, change-of-control triggers, restrictive covenants), related-party / beneficial-ownership exposure, regulatory / sanctions exposure. Each scored R/Y/G with the specific findings linked to source documents in the data room.", }, { q: "How accurate is the contract extraction?", a: "Extraction is reliable for the common clause families (term, termination, indemnity, exclusivity, change-of-control, MFN). The model surfaces clauses with confidence scores; high-confidence findings go straight into the heatmap, lower-confidence findings get flagged for analyst review. The output is a tool for the diligence team, not a replacement for it.", }, { q: "What's the cost-time tradeoff?", a: "On a typical mid-market deal, the engagement takes 1–2 weeks from data-room access to packaged report, and replaces roughly 30–40 hours of analyst time on the extraction-and-anomaly-detection work. The analyst time saved goes into the judgment work where it actually pays off.", }, { q: "Pricing?", a: "Per-target, scoped to data-room size and the depth of regulatory screening required. Discovery call covers both.", }, ], }; ## What this is A diligence accelerator that takes a data room and a few days, and gives the deal team back a risk heatmap with the anomalies surfaced and the off-market clauses flagged. Four dimensions: - **Financial-statement anomalies.** Trial-balance checks, accruals trajectory, related-party exposure, revenue-recognition anomalies relative to sector peers. - **Contract-clause risk.** Extraction across the contract corpus — term length, termination triggers, MFN clauses, change-of-control language, indemnity asymmetry — benchmarked against comparable-transaction norms. - **Beneficial ownership and sanctions.** Screening against major lists (OFAC, EU, UK sanctions; PEP databases) plus relationship-graph analysis on ownership chains. - **Regulatory exposure.** Industry-specific (healthcare, fintech, defense) regulatory posture mapped against the target's operations. ## How it's built Document AI for extraction (LayoutLM-class for structured-document fields, dedicated contract-clause models for the legal half), graph database for ownership and relationship analysis, sanctions screening via the standard list feeds. Anomaly detection layers a classical statistical baseline with a model-trained-on-peer-set comparison. ## What you get - The risk heatmap with source-document links per finding. - The contract-clause extraction as a structured dataset (rows: contracts, columns: clause families). - A short partner-readable summary — what the heatmap concludes, in one page. - A working session with the deal team to walk findings before close. FAQ: - Q: Xapien does sanctions and ownership screening. Why this? A: Xapien is excellent at the screening half. This product is broader — it also extracts and analyzes the financial statements and the contract corpus, surfaces anomalies against comparable transactions, and runs the integrations across the full diligence stack in one pass. If your firm already uses Xapien and wants the rest of the stack to match, this layers over it; if you're starting from scratch, this is the integrated alternative. - Q: What does the heatmap actually look like? A: Four risk dimensions per target — financial-statement anomalies, contract-clause risk (off-market terms, change-of-control triggers, restrictive covenants), related-party / beneficial-ownership exposure, regulatory / sanctions exposure. Each scored R/Y/G with the specific findings linked to source documents in the data room. - Q: How accurate is the contract extraction? A: Extraction is reliable for the common clause families (term, termination, indemnity, exclusivity, change-of-control, MFN). The model surfaces clauses with confidence scores; high-confidence findings go straight into the heatmap, lower-confidence findings get flagged for analyst review. The output is a tool for the diligence team, not a replacement for it. - Q: What's the cost-time tradeoff? A: On a typical mid-market deal, the engagement takes 1–2 weeks from data-room access to packaged report, and replaces roughly 30–40 hours of analyst time on the extraction-and-anomaly-detection work. The analyst time saved goes into the judgment work where it actually pays off. - Q: Pricing? A: Per-target, scoped to data-room size and the depth of regulatory screening required. Discovery call covers both. --- ## Document Intelligence Engine URL: https://orientedplatforms.com/suites/ai-implementation/document-intelligence-engine Suite: ai-implementation Tier: Document & knowledge intelligence Engagement: 8–14 week build · ongoing operation Buyer: COOs · Operations directors · Finance teams · Compliance leads Problem: Most established businesses accumulate document workflows that scale linearly with growth — invoices, contracts, supplier correspondence, customer onboarding documents, regulatory filings. Each workflow has its own quirks, none of them are automated, the operations team spends real hours per week on routine extraction. Deliverable: A document-AI pipeline that ingests the business's document corpus, classifies by type, extracts the relevant fields, routes to downstream systems with confidence-graded review queue. Related: process-automation-agents, finance-operations-ai, k-1-extraction-engine, statement-capital-call-ingestion-engine , { q: "How is this different from the PE Diligence Red-Flag Engine?", a: "Same pattern. The PE Diligence engine is shaped specifically for the per-deal diligence sprint and the deal-team risk-heatmap output. This is the horizontal version for general document workflows — same extraction backbone, no PE-specific specializations.", }, { q: "What document types are supported?", a: "Invoices, contracts, purchase orders, shipping documents, receipts and expense documents, customer onboarding forms, regulatory filings, certifications, ID documents. Per-engagement, new document classes are added — the model adapts.", }, { q: "What's the integration pattern with downstream systems?", a: "Per-document-type routing — invoices to the AP system, contracts to the legal team, customer documents to the CRM. The routing layer is configurable and works with the business's existing software stack (ERP, CRM, legal-document-management, custom systems).", }, { q: "Pricing?", a: "Scoped to document volume and document-type breadth. Discovery call covers both.", }, ], }; ## What this is A horizontal document AI engagement for established businesses. Three layers: - **Ingestion.** Email-attachment intake, SFTP, file-upload, per-source connectors. The document corpus enters via whatever path the business already uses. - **Classification and extraction.** Per-document-type model handling — invoices vs. contracts vs. shipping docs. Per-type extraction with confidence scoring. - **Routing and downstream integration.** Per-document-type routing rules. Integration with the business's downstream systems. ## How it's built LayoutLM-class document AI for the structured extraction, BERT-class clause-extraction models for the legal-language fields, per-document-type templates as a fast path. Routing layer in Python with configurable rules. Adapters into the business's downstream systems (ERP, CRM, document management). ## What you get - The ingestion-and-classification pipeline. - Per-document-type extraction models. - The routing layer with configurable rules. - Integration with downstream systems. - The review-queue UI for confidence-graded human-in-loop handling. FAQ: - Q: How is this different from the K-1 Extraction Engine in the FO Suite? A: K-1 Extraction is vertical-specialized — built specifically for the family-office tax-season K-1 workflow with FO-specific integrations (AtlasFive, partnership-cross-check, etc.). This is the horizontal version for general businesses — same modeling backbone, generic document classification and extraction layer, no FO-specific specializations. If you're an FO, use the K-1 product. If you're a general business with similar workflows, this is the right tool. - Q: How is this different from the PE Diligence Red-Flag Engine? A: Same pattern. The PE Diligence engine is shaped specifically for the per-deal diligence sprint and the deal-team risk-heatmap output. This is the horizontal version for general document workflows — same extraction backbone, no PE-specific specializations. - Q: What document types are supported? A: Invoices, contracts, purchase orders, shipping documents, receipts and expense documents, customer onboarding forms, regulatory filings, certifications, ID documents. Per-engagement, new document classes are added — the model adapts. - Q: What's the integration pattern with downstream systems? A: Per-document-type routing — invoices to the AP system, contracts to the legal team, customer documents to the CRM. The routing layer is configurable and works with the business's existing software stack (ERP, CRM, legal-document-management, custom systems). - Q: Pricing? A: Scoped to document volume and document-type breadth. Discovery call covers both. --- ## Dynamic Pricing & Promotion Engine URL: https://orientedplatforms.com/suites/operations-algorithms/dynamic-pricing-promotion-engine Suite: operations-algorithms Tier: Commercial optimization Engagement: 8–12 week build per category · ongoing iteration Buyer: Commercial leads · Pricing teams · CMOs Problem: Pricing decisions and promotion calendars are set on instinct plus a quarterly comp-set review. Price elasticity by segment is unknown, promotion cannibalization is unmodeled, and the timing-and-depth of promotions is anchored to last year's calendar. Deliverable: An elasticity-and-promotion model — per-segment price elasticity (or discount-elasticity for negotiated B2B), promotion-cannibalization modeling, recommended timing and depth that maximizes net revenue. Related: demand-forecasting-inventory-engine , { q: "What about promotion calendar optimization?", a: "The promotion-cannibalization layer models how a promotion in week N affects sales in weeks N-1 and N+1 — the pull-forward and pull-back effects that make 'incremental sales from promotion' often smaller than the gross sales reading suggests. Calendar recommendations emerge from optimizing against the model.", }, { q: "How is elasticity estimated for products with limited price-change history?", a: "Bayesian elasticity with industry-comparable priors, plus suggested experimentation plan. We're upfront when the data is too thin for a confident elasticity estimate — the engine surfaces uncertainty rather than producing a precise-but-wrong number.", }, { q: "Does it handle competitive pricing dynamics?", a: "Where the business tracks competitor pricing, it's a model input. The engine surfaces when the business is materially out of line with the comp set. We don't model competitor response to the business's price changes — that's game-theoretic territory we're upfront about avoiding.", }, { q: "Pricing?", a: "Scoped per category and per integration surface. Discovery call covers both.", }, ], }; ## What this is A pricing-and-promotion engine for commercial teams that want pricing decisions to be modeled rather than instinct-anchored. Three components: - **Elasticity modeling.** Per-segment, per-product elasticity (or discount-elasticity for B2B). Bayesian with informative priors for the data-thin cases. - **Promotion-cannibalization modeling.** Pull-forward and pull-back effects modeled explicitly. Net incremental revenue calculated against the cannibalization baseline. - **Recommendation layer.** Timing-and-depth recommendations against the business's revenue or margin objective. Configurable to optimize whichever the commercial team has chosen. ## How it's built PyMC for the Bayesian elasticity, LightGBM with monotonic constraints for non-linear pricing-response modeling, optimization layer (linear programming where the problem fits, simulated annealing where it doesn't). Integration into the business's pricing system or e-commerce platform for execution. ## What you get - Per-segment elasticity estimates with uncertainty. - The promotion-cannibalization model. - Recommended pricing and promotion calendar. - Experimentation plan for cases where current data is thin. - Quarterly model refresh. FAQ: - Q: How is this different from the PE Suite's Pricing & Margin Optimizer? A: Same modeling backbone, different commercial shape. The PE version is built around the operating-partner-funded engagement on a single portco. This product is for direct-to-business deployment — the commercial team buys it for their own business, not via an outside investor. - Q: What about promotion calendar optimization? A: The promotion-cannibalization layer models how a promotion in week N affects sales in weeks N-1 and N+1 — the pull-forward and pull-back effects that make 'incremental sales from promotion' often smaller than the gross sales reading suggests. Calendar recommendations emerge from optimizing against the model. - Q: How is elasticity estimated for products with limited price-change history? A: Bayesian elasticity with industry-comparable priors, plus suggested experimentation plan. We're upfront when the data is too thin for a confident elasticity estimate — the engine surfaces uncertainty rather than producing a precise-but-wrong number. - Q: Does it handle competitive pricing dynamics? A: Where the business tracks competitor pricing, it's a model input. The engine surfaces when the business is materially out of line with the comp set. We don't model competitor response to the business's price changes — that's game-theoretic territory we're upfront about avoiding. - Q: Pricing? A: Scoped per category and per integration surface. Discovery call covers both. --- ## Dynamic Pricing for Shopify URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/dynamic-pricing-shopify Suite: shopify-ops-intelligence Tier: Storefront & customer intelligence Engagement: 6–12 week deployment · self-serve to custom packaging Buyer: DTC operators · Shopify-Plus brands · Multi-store DTC holdcos Problem: Shopify stores price by intuition and run promotions on calendar habit — without elasticity modeling, the promotion calendar produces gross-sales lift that's mostly pull-forward from un-promoted weeks. Deliverable: A Shopify-tuned deployment of the canonical Dynamic Pricing & Promotion Engine — wired to Shopify Discounts, Shopify Functions for custom pricing logic, and the storefront experimentation infrastructure. Related: dynamic-pricing-promotion-engine, demand-forecasting-shopify, shopify-operations-workflow-automation , { q: "What about Shopify Markets and per-market pricing?", a: "Shopify Markets integration is supported. The pricing model can produce per-market recommendations, fed to Markets pricing rules.", }, { q: "How is this different from the OAS canonical?", a: "Same modeling backbone. What's different is the Shopify integration surface — Discounts API, Functions, Markets, the storefront-experimentation infrastructure. Cross-link to the canonical for the modeling detail.", }, { q: "What's the typical impact on DTC margin?", a: "Per-engagement varies. Typical findings: 200–500 bps of margin uplift from elasticity-informed pricing and promo timing. Smaller stores often see larger relative impact because they're starting from less-sophisticated pricing.", }, { q: "Pricing?", a: "Tiered per buyer profile. Discovery call covers the right tier.", }, ], }; ## What this is The canonical Dynamic Pricing & Promotion Engine, tuned for Shopify-native execution. See the [canonical product page in the Operations Algorithms Suite](/suites/operations-algorithms/dynamic-pricing-promotion-engine) for the modeling backbone, elasticity-and-cannibalization detail, and technical depth. The Shopify-tuned tuning consists of: - Direct integration with Shopify Discounts API for price-list and promotion management. - Shopify Functions integration for cart-evaluated pricing logic where the runtime budget permits. - Shopify Markets support for per-market pricing recommendations. - Storefront experimentation infrastructure integration for A/B testing of price points and promotion structures. ## What you get - The pricing model deployed against your Shopify data. - Shopify Discounts API integration for execution. - Shopify Functions logic for the cart-side decisions that warrant it. - Operator UI consistent with Shopify Admin. - Quarterly model refresh and experimentation infrastructure. FAQ: - Q: Can Shopify Functions actually run our pricing logic in real time? A: Yes, within the constraints of the Functions runtime — fast, deterministic, cart-evaluated. For pricing logic that exceeds the runtime budget, the engine falls back to price-list updates via the API rather than runtime computation. The engagement scopes which logic runs where. - Q: What about Shopify Markets and per-market pricing? A: Shopify Markets integration is supported. The pricing model can produce per-market recommendations, fed to Markets pricing rules. - Q: How is this different from the OAS canonical? A: Same modeling backbone. What's different is the Shopify integration surface — Discounts API, Functions, Markets, the storefront-experimentation infrastructure. Cross-link to the canonical for the modeling detail. - Q: What's the typical impact on DTC margin? A: Per-engagement varies. Typical findings: 200–500 bps of margin uplift from elasticity-informed pricing and promo timing. Smaller stores often see larger relative impact because they're starting from less-sophisticated pricing. - Q: Pricing? A: Tiered per buyer profile. Discovery call covers the right tier. --- ## Dynamic Rental Pricing Engine URL: https://orientedplatforms.com/suites/real-estate/dynamic-rental-pricing-engine Suite: real-estate Tier: For RE operators Engagement: 8–12 week build · ongoing weekly pricing cadence Buyer: Multifamily operators · Commercial property managers · Leasing teams Problem: Multifamily and commercial rental pricing is set quarterly by the leasing team, anchored to comps the operator pulls from CoStar — and then sits until the next quarterly review. Demand moves weekly; pricing doesn't. Deliverable: A pricing model trained on the property's leasing history, competitor positioning, and macro signals — produces weekly pricing recommendations at the unit level, with the underlying demand forecast and the competitor-comp context surfaced. Related: tenant-intelligence-engine , { q: "What about Beyond Pricing or AirDNA?", a: "Those are short-term-rental products. We deliberately don't play in STR — the market is crowded and the data shape is different (high-frequency turnover, channel optimization). Our focus is commercial multifamily and longer-term commercial leases where the pricing cadence is weekly, not hourly.", }, { q: "What data does the model need?", a: "Three years of leasing history (signed lease values, vacancy patterns, concession data), competitor comps (CoStar feed or alternative), macro signals (regional employment, rent CPI), and ideally any seasonality data the property has. Where the property is new construction, the model leans on regional priors with documented uncertainty.", }, { q: "Does the operator have to follow the recommendations?", a: "No — the operator finalizes. The model produces the recommendation and the reasoning; the leasing team can accept, override, or run a side-by-side experiment. We track override decisions and surface where overrides outperformed and where they underperformed.", }, { q: "Pricing?", a: "Scoped to portfolio scale and pricing-cadence complexity. Discovery call covers both.", }, ], }; ## What this is A demand-and-pricing layer for the commercial-multifamily and CRE operator. Three components: - **Demand forecasting.** Per-unit and per-submarket demand model trained on leasing history. Daily-grain demand prediction; weekly-grain pricing-relevance. - **Competitor positioning.** Per-comp tracking of competitor pricing and concession behavior. Surfaces the moments where the property's pricing is materially out of line with the comp set. - **Pricing recommendation.** Weekly per-unit recommendation with documented assumptions. Operator-side UI for review and override. ## How it's built Statsmodels and Prophet for the time-series baseline, LightGBM for the non-linear demand modeling, CoStar API integration where the operator subscribes (or alternative comp-data sources). Recommendation surfaces through the operator's existing property-management system where integration permits. ## What you get - The demand-forecasting model per property. - Weekly pricing recommendation pipeline. - Operator review UI with override tracking. - Quarterly model refresh and override-analysis retrospective. - Per-submarket calibration as the portfolio expands. FAQ: - Q: How is this different from AppFolio or other multifamily software? A: AppFolio handles transactional rental ops. The pricing layer they offer is rule-based and quarterly-cadence. This product is a forecasting model — daily demand prediction, weekly pricing recommendation, with the operator finalizing. The two integrate: AppFolio for transactional ops, this for the pricing layer. - Q: What about Beyond Pricing or AirDNA? A: Those are short-term-rental products. We deliberately don't play in STR — the market is crowded and the data shape is different (high-frequency turnover, channel optimization). Our focus is commercial multifamily and longer-term commercial leases where the pricing cadence is weekly, not hourly. - Q: What data does the model need? A: Three years of leasing history (signed lease values, vacancy patterns, concession data), competitor comps (CoStar feed or alternative), macro signals (regional employment, rent CPI), and ideally any seasonality data the property has. Where the property is new construction, the model leans on regional priors with documented uncertainty. - Q: Does the operator have to follow the recommendations? A: No — the operator finalizes. The model produces the recommendation and the reasoning; the leasing team can accept, override, or run a side-by-side experiment. We track override decisions and surface where overrides outperformed and where they underperformed. - Q: Pricing? A: Scoped to portfolio scale and pricing-cadence complexity. Discovery call covers both. --- ## Enterprise SaaS Spend Optimization URL: https://orientedplatforms.com/suites/operations-algorithms/enterprise-saas-spend-optimization Suite: operations-algorithms Tier: Operations research Engagement: 4–8 week audit · optional ongoing optimization Buyer: CFOs · CIOs · IT directors · Procurement leads Problem: Enterprise SaaS spend has grown to 5–15% of revenue for typical mid-market and enterprise companies — and most companies don't know which licenses are actually used, which vendors are redundant, where the seat-count is over-provisioned, or what consolidation would save. Deliverable: An audit-plus-optimization engagement that maps the company's SaaS stack against actual usage, identifies redundant vendors and over-provisioned licenses, models the consolidation scenarios, recommends the contract renegotiations that would maximize savings. , { q: "How is this different from SubMagician Enterprise?", a: "SubMagician Enterprise is the product — software the company subscribes to that runs the usage tracking and optimization ongoing. This is a productized service for companies that don't want a product subscription but want the analytical work done once (or recurring). Different commercial shape, same underlying optimization math.", }, { q: "What data does the audit need?", a: "License-and-billing data from the company's vendor list, SSO logs for usage signal where available, expense reports or AP data for vendor footprint discovery. Where the company doesn't have clean inventory, the audit includes a discovery phase to assemble it.", }, { q: "What's the typical savings?", a: "Per-engagement varies. Typical findings: 15–30% of licenses unused or under-used, 5–10% of vendor spend on consolidatable categories, 3–8% from renegotiation against discovered usage data. Aggregate savings typically 10–25% of total SaaS spend.", }, { q: "Pricing?", a: "Fixed-fee for the audit, optional ongoing engagement. Discovery call scopes the company's SaaS spend baseline.", }, ], }; ## What this is A cost-optimization engagement framed as a constrained-optimization problem. Three components: - **Usage discovery and modeling.** Per-vendor and per-license usage data assembled. Where signal is direct (SSO logs, API usage), it's used; where signal is indirect (expense reports, anecdotal), it's noted with appropriate uncertainty. - **Optimization analysis.** Vendor-redundancy identification, license rightsizing math, consolidation scenarios with documented assumptions and risk profiles. - **Renegotiation recommendation.** The contract-renegotiation playbook against the discovered usage data — which vendors to renegotiate, what leverage exists, what target savings to anchor to. ## How it's built Data-pipeline layer to assemble usage signal (SSO integration, AP-data parsing, vendor-API pulls). Analytical layer in Python (Polars / DuckDB) with optimization math for the consolidation scenarios. Recommendation packaged as a finance-team-readable document. ## What you get - The complete SaaS-stack map with documented usage. - The vendor-redundancy and license-rightsizing analysis. - Consolidation scenarios with quantified savings. - The renegotiation playbook for the procurement team. - Optional ongoing engagement for quarterly re-audit. FAQ: - Q: How is this different from Vendr, Tropic, Spendflo, Zylo? A: Those are mature SaaS spend management products — they cover the contract-management and procurement workflow well. This engagement is the analytical layer that complements them: usage modeling, vendor-redundancy identification, optimization math against the company's constraints. Companies often use both — this for the analytical recommendation, the management SaaS for ongoing procurement workflow. - Q: How is this different from SubMagician Enterprise? A: SubMagician Enterprise is the product — software the company subscribes to that runs the usage tracking and optimization ongoing. This is a productized service for companies that don't want a product subscription but want the analytical work done once (or recurring). Different commercial shape, same underlying optimization math. - Q: What data does the audit need? A: License-and-billing data from the company's vendor list, SSO logs for usage signal where available, expense reports or AP data for vendor footprint discovery. Where the company doesn't have clean inventory, the audit includes a discovery phase to assemble it. - Q: What's the typical savings? A: Per-engagement varies. Typical findings: 15–30% of licenses unused or under-used, 5–10% of vendor spend on consolidatable categories, 3–8% from renegotiation against discovered usage data. Aggregate savings typically 10–25% of total SaaS spend. - Q: Pricing? A: Fixed-fee for the audit, optional ongoing engagement. Discovery call scopes the company's SaaS spend baseline. --- ## Exit-Prep Automation URL: https://orientedplatforms.com/suites/private-equity/exit-prep-automation Suite: private-equity Tier: Exit + LP Engagement: 4–8 week sprint per exit · ongoing data room maintenance Buyer: GP principals · IR teams · Operating partners Problem: Exit prep is months of work compressed into the window between decision and process launch — data rooms assembled, decks built, comparable-transaction analyses pulled together, buyer lists refined. The IR team and the operating partners burn weeks on it; the prep quality varies by whoever pulled which thread together. Deliverable: An exit-prep package — automated data room construction from the portco's existing systems, investor-deck assembly with portco metrics auto-populated, comparable-transaction analysis against current-market multiples, buyer-pool intelligence for the strategic and financial pools. Related: portfolio-intelligence-platform, lp-reporting-engine , { q: "What's in the investor deck assembly?", a: "Template-driven deck with the portco metrics auto-populated from the Portfolio Intelligence Platform — growth, margin, cash flow, customer cohort trends, churn, sector benchmarks. The narrative and the strategic positioning stay with the IR team; the data layer that supports them stays current automatically as the exit window approaches.", }, { q: "How is the buyer-pool intelligence built?", a: "For each exit, a refreshed view of the strategic pool (acquirers that have made comparable transactions, recent M&A activity in adjacent sectors) and the financial pool (PE funds with mandates that match the portco's profile, recent fund vintages with deployable capital, historical deal sizes that match the EBITDA range). Sourced from the same data infrastructure the Deal-Sourcing Engine runs on.", }, { q: "Does this work for any exit type?", a: "Strategic sale and secondary buyout are the strongest use cases. IPO prep is partial — the data-room and metric-assembly layers work the same way, but the regulatory and underwriter-management work is outside the scope. We're upfront about that.", }, { q: "Pricing?", a: "Per exit, scoped to portco complexity and the depth of buyer-pool intelligence required. Discovery call covers both.", }, ], }; ## What this is A productized engagement that takes the months of exit prep and compresses the assembly half — the parts that are data and document work, not judgment work — into a four-to-eight-week sprint. Three layers: - **Data-room construction.** Pulls portco documents from existing systems (file shares, contract management, ERP) into a deal-team-friendly structure, with documented versioning so the process refresh doesn't lose history. - **Deck assembly.** Template-driven investor deck with portco metrics auto-populated. The IR team writes the strategic narrative; the data layer that supports it stays current as the window approaches. - **Comparable-transaction and buyer-pool intelligence.** Refreshed views of strategic and financial buyer pools, anchored to current market multiples. Sourced from the same infrastructure that powers the Deal-Sourcing Engine. ## How it's built Document-pipeline layer for data-room assembly (pulling from SharePoint, Notion, Box, file shares), template-driven deck generation (python-pptx-class for PowerPoint, or your firm's preferred slide-authoring tool), comparable-transaction analysis on the same data infrastructure used elsewhere in the suite. Buyer-pool intelligence runs against the deal-sourcing graph. ## What you get - The structured data room assembled from portco source systems. - The investor deck with auto-populated metric pages. - The comparable-transaction analysis and buyer-pool intelligence packages. - A working session with the IR team to walk the package before process launch. - Ongoing refresh as the exit window evolves. FAQ: - Q: We use SmartRoom for data rooms. Does this replace it? A: No — it feeds it. SmartRoom is excellent at hosting and access management. This product handles the work upstream of the data room: pulling the documents together from the portco's systems, structuring them by deal-team-friendly category, refreshing them through the process. SmartRoom (or any data-room platform) hosts what we assemble. - Q: What's in the investor deck assembly? A: Template-driven deck with the portco metrics auto-populated from the Portfolio Intelligence Platform — growth, margin, cash flow, customer cohort trends, churn, sector benchmarks. The narrative and the strategic positioning stay with the IR team; the data layer that supports them stays current automatically as the exit window approaches. - Q: How is the buyer-pool intelligence built? A: For each exit, a refreshed view of the strategic pool (acquirers that have made comparable transactions, recent M&A activity in adjacent sectors) and the financial pool (PE funds with mandates that match the portco's profile, recent fund vintages with deployable capital, historical deal sizes that match the EBITDA range). Sourced from the same data infrastructure the Deal-Sourcing Engine runs on. - Q: Does this work for any exit type? A: Strategic sale and secondary buyout are the strongest use cases. IPO prep is partial — the data-room and metric-assembly layers work the same way, but the regulatory and underwriter-management work is outside the scope. We're upfront about that. - Q: Pricing? A: Per exit, scoped to portco complexity and the depth of buyer-pool intelligence required. Discovery call covers both. --- ## Family Report Drafter URL: https://orientedplatforms.com/suites/family-office/family-report-drafter Suite: family-office Tier: Forecasting + reporting Engagement: 6–10 week build · ongoing operation Buyer: CFOs · Operations directors · Communications leads Problem: Quarterly family reports are written from scratch every quarter — performance summary, allocation commentary, year-over-year context, family-member-relevant narrative. The CFO drafts the first version; staff revises; legal reviews; the principals get a polished document that took a person-week to produce. Deliverable: An LLM-powered drafting layer that produces quarterly family reports, capital-call notices, tax-footnote narrative, and ad-hoc communications — trained on the FO's historical document structure and preferred tone, with the CFO finalizing. Related: multi-entity-consolidation-platform, conversational-portfolio-assistant, liquidity-cash-forecasting-engine , { q: "What about per-family-member personalization?", a: "The reports can be parameterized per recipient — different family members see different levels of detail, different commentary depth, different attached schedules. Drafted from a common data source with recipient-specific framing.", }, { q: "Does this hallucinate numbers?", a: "Numbers come from the data layer (Multi-Entity Consolidation Platform or your equivalent), inserted via structured templating — not generated by the LLM. The LLM writes the prose around the numbers. Hallucinated numbers are not a failure mode of this architecture.", }, { q: "How much CFO time does it actually save?", a: "Typical pattern: from a person-week of drafting to a few hours of review and revision. The CFO still owns the final document and the strategic framing; the engine handles the structure and the routine prose.", }, { q: "Pricing?", a: "Scoped to report cadence, recipient count, and the breadth of document types covered. Discovery call covers all three.", }, ], }; ## What this is The output layer of the suite — the place where the data flows through to the family. Three components: - **Tone-trained drafting.** Fine-tuned on the FO's historical report corpus. Drafts read in the FO's voice, not in a generic LLM voice. - **Data-grounded number insertion.** Numbers come from the canonical data layer via structured templating. The LLM never generates a financial figure. - **Per-recipient parameterization.** Common report drafted once, framed per recipient (principals, family members, advisors) with appropriate detail and tone. ## How it's built Commercial-API LLM (Claude-class, GPT-class) with the FO's report corpus as a fine-tuning anchor, or on-prem Llama-class with the same approach. Structured templating layer (Jinja-class) for the data-insertion points. Per-recipient configuration as a declarative rule set. Output formats: PDF, Word, HTML — whatever the FO needs for downstream distribution. ## What you get - The fine-tuned drafting model deployed to your FO. - Templates for the canonical report types (quarterly performance, annual summary, capital-call notice, tax-footnote narrative). - Per-recipient parameterization configured to your family's preferences. - The CFO review UI with markup-and-finalize workflow. - Ongoing tone calibration as the report corpus grows. FAQ: - Q: How does it preserve the FO's voice? A: Fine-tuned on the FO's historical report corpus — typically two to three years of prior quarterly reports plus a curated set of preferred-tone examples. The drafts come out reading like the FO's previous reports because the model has learned the FO's voice. Where principals or family members have individual preferences (more conservative tone, specific phrasings to avoid), those are encoded as constraints. - Q: What about per-family-member personalization? A: The reports can be parameterized per recipient — different family members see different levels of detail, different commentary depth, different attached schedules. Drafted from a common data source with recipient-specific framing. - Q: Does this hallucinate numbers? A: Numbers come from the data layer (Multi-Entity Consolidation Platform or your equivalent), inserted via structured templating — not generated by the LLM. The LLM writes the prose around the numbers. Hallucinated numbers are not a failure mode of this architecture. - Q: How much CFO time does it actually save? A: Typical pattern: from a person-week of drafting to a few hours of review and revision. The CFO still owns the final document and the strategic framing; the engine handles the structure and the routine prose. - Q: Pricing? A: Scoped to report cadence, recipient count, and the breadth of document types covered. Discovery call covers all three. --- ## Field Operations Automation URL: https://orientedplatforms.com/suites/ai-implementation/field-operations-automation Suite: ai-implementation Tier: Workflow & operations automation Engagement: 6–10 week build · ongoing operation Buyer: Owner-operators · Field-service operations managers · Trade-business CEOs Problem: Field-service businesses — HVAC companies, electrical contractors, solar installers, plumbing operations — run scheduling, dispatch, customer communication, quote generation, and follow-up across software stacks that don't talk to each other. The operator wears every hat at small scale; at growing scale, the operator becomes the bottleneck. Deliverable: An AI layer for the field-service operating stack — scheduling and dispatch optimization, automated customer communications, quote-generation drafting, follow-up automation. Integrates with the standard field-service software (ServiceTitan, Jobber, Housecall Pro) or with the business's existing custom stack. Related: process-automation-agents, customer-support-ai, logistics-routing-optimizer , { q: "How does it integrate with ServiceTitan / Jobber / Housecall Pro?", a: "Standard API integration with each. ServiceTitan is the canonical case — most established field-service businesses use it. Jobber and Housecall Pro for the smaller operators. Custom-stack integration where the business runs its own software.", }, { q: "What does the scheduling-optimization piece actually do?", a: "Multi-job-per-day scheduling that minimizes drive time and matches technician skill to job requirements. For businesses with skill-tiered technicians (entry-level on standard maintenance, senior on complex installs), the engine handles the matching. For businesses with single-tier crews, it focuses on route optimization.", }, { q: "Can it generate quotes automatically?", a: "Drafts quotes — based on job description, prior similar jobs, and the business's standard pricing. Owner reviews before sending to customer. The engine handles the routine 60-80% of quote requests; the harder cases (custom configurations, unusual jobs) stay with the owner.", }, { q: "Pricing?", a: "Scoped to truck count and integration depth. Discovery call covers both. Pricing is sized for the field-service market specifically — accessible at owner-operator scale.", }, ], }; ## What this is A field-operations engagement built explicitly for the trade-business buyer. Four components: - **Scheduling and dispatch.** Optimization-based routing across the crew, with skill-matching where the business has tiered crews. - **Customer communications.** Reminder messages, confirmation flows, follow-up sequences. Owner-reviewed templates for the higher-stakes messages. - **Quote generation.** Drafts from job description, prior similar jobs, and standard pricing. Owner finalizes. - **Follow-up automation.** Post-job feedback collection, review-request flows, maintenance-renewal outreach. ## How it's built Lightweight stack — the field-service market is cost-sensitive, so the architecture is built for accessibility. Integration with the standard FSM platforms (ServiceTitan, Jobber, Housecall Pro) via their APIs. Custom-stack integration where the business runs its own. The optimization layer reuses the OR backbone from the Logistics & Routing Optimizer. ## What you get - The scheduling and dispatch optimization integrated with your FSM platform. - The customer communication automation. - The quote-generation drafting layer. - The follow-up automation flows. - Pricing sized for field-service businesses, not enterprise. FAQ: - Q: Does this work for a 5-truck HVAC company or just larger operations? A: Both. The packaging adapts — for the smaller operator, it's a focused deployment on the highest-leverage workflows (typically scheduling and customer follow-up). For larger field-service operations, it's the broader stack covering dispatch optimization, quote-cycle management, and multi-job-type coordination. The product itself works at both ends. - Q: How does it integrate with ServiceTitan / Jobber / Housecall Pro? A: Standard API integration with each. ServiceTitan is the canonical case — most established field-service businesses use it. Jobber and Housecall Pro for the smaller operators. Custom-stack integration where the business runs its own software. - Q: What does the scheduling-optimization piece actually do? A: Multi-job-per-day scheduling that minimizes drive time and matches technician skill to job requirements. For businesses with skill-tiered technicians (entry-level on standard maintenance, senior on complex installs), the engine handles the matching. For businesses with single-tier crews, it focuses on route optimization. - Q: Can it generate quotes automatically? A: Drafts quotes — based on job description, prior similar jobs, and the business's standard pricing. Owner reviews before sending to customer. The engine handles the routine 60-80% of quote requests; the harder cases (custom configurations, unusual jobs) stay with the owner. - Q: Pricing? A: Scoped to truck count and integration depth. Discovery call covers both. Pricing is sized for the field-service market specifically — accessible at owner-operator scale. --- ## Finance Operations AI URL: https://orientedplatforms.com/suites/ai-implementation/finance-operations-ai Suite: ai-implementation Tier: Workflow & operations automation Engagement: 8–12 week build · ongoing operation Buyer: CFOs · Controllers · Finance ops leads Problem: Finance ops work scales linearly with business size — invoice processing, expense categorization, AP and AR reconciliation, payment matching, fraud-pattern detection. The finance team spends real hours per week on routine that should be automated. Deliverable: An AI layer over the finance-ops workflows — invoice ingestion and posting, expense categorization, AP/AR reconciliation, payment matching, fraud-pattern detection. Integrates with the business's accounting system (NetSuite, QuickBooks, Sage, Xero, custom). Related: document-intelligence-engine, invoice-bill-pay-engine , { q: "What about the reconciliation half?", a: "AR reconciliation matches incoming payments to invoices using transaction-detail matching (amount, reference, customer attribution). AP reconciliation matches vendor invoices to POs and receipts. Where matching is ambiguous, the system flags rather than guessing.", }, { q: "What's the fraud-detection layer?", a: "Standard patterns (duplicate invoices, same-amount-different-reference, vendor-impersonation attempts, anomalous payment requests). Per-business, the rule set is customized based on prior fraud incidents and the business's risk profile.", }, { q: "Does it actually post to the ledger automatically?", a: "Configurable. High-confidence transactions can auto-post (with audit trail). Lower-confidence go to controller review. The auto-post threshold is set by the controller — the system doesn't decide unilaterally.", }, { q: "Pricing?", a: "Scoped to transaction volume and integration depth. Discovery call covers both.", }, ], }; ## What this is A finance-ops engagement built for general businesses. Four components: - **Invoice processing.** Ingestion, extraction, vendor classification, GL prediction. Same shape as the FO version, generic-business specialization. - **Expense categorization.** Receipt extraction, category prediction, policy-compliance checking (e.g., per-diem limits, vendor restrictions). - **AP/AR reconciliation.** Payment matching, dispute identification, aging analysis. - **Fraud detection.** Standard patterns plus business-specific rule set. ## How it's built Document AI for the extraction layers, classification models for vendor and expense categorization, rule engine for the policy-compliance and fraud-detection layers. Integration with NetSuite / QuickBooks / Sage / Xero / custom accounting platforms. ## What you get - The AP processing pipeline. - The expense categorization layer. - The AR reconciliation layer. - The fraud-detection rule set. - Integration with your accounting platform. - Quarterly model refresh and rule-set review. FAQ: - Q: How is this different from the FO Invoice & Bill-Pay Engine? A: Same modeling backbone, different scoping. The FO version is specialized for the family-office AP profile (multi-entity, household-and-property vendor categories, family-member allocation logic). This is the general-business version — broader vendor profile, standard B2B/B2C AP, no FO specializations. If you're an FO, use the FO product. If you're a general business, this is the right tool. - Q: What about the reconciliation half? A: AR reconciliation matches incoming payments to invoices using transaction-detail matching (amount, reference, customer attribution). AP reconciliation matches vendor invoices to POs and receipts. Where matching is ambiguous, the system flags rather than guessing. - Q: What's the fraud-detection layer? A: Standard patterns (duplicate invoices, same-amount-different-reference, vendor-impersonation attempts, anomalous payment requests). Per-business, the rule set is customized based on prior fraud incidents and the business's risk profile. - Q: Does it actually post to the ledger automatically? A: Configurable. High-confidence transactions can auto-post (with audit trail). Lower-confidence go to controller review. The auto-post threshold is set by the controller — the system doesn't decide unilaterally. - Q: Pricing? A: Scoped to transaction volume and integration depth. Discovery call covers both. --- ## Follow-on Decision Engine URL: https://orientedplatforms.com/suites/venture-capital/follow-on-decision-engine Suite: venture-capital Tier: Portfolio + LP Engagement: 8–12 week build · per-vintage configuration Buyer: Partners · Portfolio teams · Investment committee Problem: Follow-on decisions at most mid-market funds are made on partner intuition plus a couple of spreadsheet checks — should we follow on, at what valuation, against what dilution. The funds that have systematized this make better decisions; most funds haven't. Deliverable: A decision-support layer that takes the fund's reserves, the portco's current performance and trajectory, and the round terms — outputs a structured recommendation against the fund's discipline rules with documented assumptions. Related: portfolio-pulse-dashboard, fund-communications-engine , { q: "What discipline rules does the engine encode?", a: "Per-fund configuration: maximum reserve percentage per portco, maximum concentration per sector or stage, follow-on threshold based on portco trajectory metrics, valuation-discipline rules (e.g., not following on above N× from last round). The partner team configures the rules; the engine applies them.", }, { q: "How does it handle the 'fund-returner' edge case?", a: "Most discipline rules have explicit override paths for the partner-conviction case — the engine surfaces the override decision (and its reserves impact) rather than blocking it. Discipline isn't pretending IC always follows rules; it's making the deviations visible.", }, { q: "What's the data source?", a: "Portfolio Pulse Dashboard for the portco trajectory data, the fund's accounting system for reserves, the round-term modeling layer for dilution math. Where the fund doesn't yet have Portfolio Pulse, we build a lighter portco-data layer as part of the engagement.", }, { q: "Pricing?", a: "Scoped to portfolio size and the discipline-rule complexity. Discovery call covers both.", }, ], }; ## What this is A decision-support layer for the follow-on call. Four components per decision: - **Portco trajectory summary.** Last twelve months of revenue, growth rate, gross margin, cash position, runway. Source: Portfolio Pulse Dashboard or equivalent. - **Reserves math.** Current reserves, reserve allocation against current portfolio, impact of this follow-on on remaining reserves. - **Dilution math.** Round terms (valuation, round size, fund's check), resulting ownership pre- and post-, dilution against next anticipated round. - **Discipline check.** Per-fund rules applied — reserve concentration, valuation discipline, sector concentration. Overrides explicitly flagged with their implications. ## How it's built Reserves and dilution math in a deterministic modeling layer. Discipline rules expressed as a declarative rule engine — the rules live in code, versioned, with auditable application per decision. Integration with the fund's accounting system for current reserve state. ## What you get - The decision-support document per follow-on. - The configured discipline rules, versioned. - Reserves and dilution modeling against the fund's accounting state. - A retrospective dashboard — how prior follow-on decisions tracked against the engine's recommendation, surfacing where the partner judgment was right or wrong. FAQ: - Q: We make follow-on decisions in IC meetings. Why a tool? A: The tool doesn't replace the IC — it produces a structured pre-read. The partner walking into IC has a document with the portco's trajectory, the reserves implication of following on, the dilution math, and the historical-vintage comparison. The IC discussion focuses on the judgment call, not on assembling the inputs. - Q: What discipline rules does the engine encode? A: Per-fund configuration: maximum reserve percentage per portco, maximum concentration per sector or stage, follow-on threshold based on portco trajectory metrics, valuation-discipline rules (e.g., not following on above N× from last round). The partner team configures the rules; the engine applies them. - Q: How does it handle the 'fund-returner' edge case? A: Most discipline rules have explicit override paths for the partner-conviction case — the engine surfaces the override decision (and its reserves impact) rather than blocking it. Discipline isn't pretending IC always follows rules; it's making the deviations visible. - Q: What's the data source? A: Portfolio Pulse Dashboard for the portco trajectory data, the fund's accounting system for reserves, the round-term modeling layer for dilution math. Where the fund doesn't yet have Portfolio Pulse, we build a lighter portco-data layer as part of the engagement. - Q: Pricing? A: Scoped to portfolio size and the discipline-rule complexity. Discovery call covers both. --- ## Founder Network Intelligence URL: https://orientedplatforms.com/suites/venture-capital/founder-network-intelligence Suite: venture-capital Tier: Deal pipeline Engagement: 8–12 week build · ongoing signal feed Buyer: Partners · Principals · Sourcing leads Problem: Early-stage VC backs founders, not companies — but the companies don't exist yet. The signal that matters is the engineering or product leader who just left Stripe with no public next role, the founding designer who left Figma three weeks ago, the cluster of staff engineers who left the same scaled startup in the same quarter. Right now most funds find this through happenstance. Deliverable: A people-level tracking layer — monitors departures from a curated 'talent watchlist' of notable companies, surfaces clusters and individuals to the partners with context (role, tenure, who they worked with), refreshes daily. Related: sector-mapping-engine, deal-sourcing-signal-platform, startup-evaluation-engine , { q: "Which 'notable companies' are tracked?", a: "Per-fund, curated. Most funds start with a list of 50–200 scaled startups and notable scale-ups in their thesis area — companies whose alumni typically become founders. The list evolves as the partners refine; this is configuration, not fixed.", }, { q: "What's the partner-side experience?", a: "A weekly digest — notable departures from watchlist companies, organized by role and seniority. Plus a real-time channel (Slack, email) for the high-priority signals (named technical leaders, cluster departures). The partner has the choice of weekly skim or real-time alert.", }, { q: "Doesn't Harmonic do this?", a: "Harmonic focuses on the company side — they surface companies in stealth or recently founded. This product is upstream — it surfaces the people before they've started the company. The two are complementary; some funds run both. Where they overlap (companies founded by tracked individuals), the signal lights up across both products.", }, { q: "Pricing?", a: "Scoped to watchlist size and the partner-alert tier (weekly vs. real-time channels). Discovery call covers both.", }, ], }; ## What this is The product that does what every VC partner wishes someone was doing for them. Three layers: - **Watchlist construction.** Per-fund curated list of notable companies whose alumni become founders. Evolves with the partners. - **People-level signal ingestion.** Public LinkedIn changes, GitHub activity, public writing and conference patterns. Departure detection. Role and seniority normalization. - **Partner notification.** Weekly digest with clustering and prioritization. Real-time channel for high-priority signals (named technical leaders, cluster departures from the same company, founder-archetype individuals). ## How it's built Headless-browser-class scraping of public profile changes (within site terms-of-service rate limits), public-API integrations where the source provides them (GitHub, GitLab), and a manual-curation overlay where the partners flag specific people to track. Embedding-based clustering on department-and-team correlation to surface "ten engineers from team X all left within the same six weeks." ## What you get - The watchlist configuration tool for the partners. - The weekly digest delivered to partners' inbox. - The real-time channel for high-priority signals. - A partner-side UI to drill into individual people — tenure, role history, who-they-worked-with graph. - Quarterly review of watchlist quality with the partners. FAQ: - Q: How do you actually get the people-level data? A: Public LinkedIn profile changes, GitHub activity, public conference and writing patterns, the public departure announcements that founders themselves post. We don't scrape private data and we don't broker introductions; we surface signal that's already public but hard to track in aggregate. - Q: Which 'notable companies' are tracked? A: Per-fund, curated. Most funds start with a list of 50–200 scaled startups and notable scale-ups in their thesis area — companies whose alumni typically become founders. The list evolves as the partners refine; this is configuration, not fixed. - Q: What's the partner-side experience? A: A weekly digest — notable departures from watchlist companies, organized by role and seniority. Plus a real-time channel (Slack, email) for the high-priority signals (named technical leaders, cluster departures). The partner has the choice of weekly skim or real-time alert. - Q: Doesn't Harmonic do this? A: Harmonic focuses on the company side — they surface companies in stealth or recently founded. This product is upstream — it surfaces the people before they've started the company. The two are complementary; some funds run both. Where they overlap (companies founded by tracked individuals), the signal lights up across both products. - Q: Pricing? A: Scoped to watchlist size and the partner-alert tier (weekly vs. real-time channels). Discovery call covers both. --- ## Fund Communications Engine URL: https://orientedplatforms.com/suites/venture-capital/fund-communications-engine Suite: venture-capital Tier: Portfolio + LP Engagement: 6–10 week build · ongoing operation Buyer: IR teams · Fundraise leads · GP principals Problem: Quarterly investor updates, annual LP letters, fundraise data rooms and pitch decks for the next fund — all of it written from scratch, all of it pulling the same portfolio data via the same person-week assembly process every quarter. Deliverable: An LLM-and-templating layer covering the fund's recurring and one-off communications — investor updates, LP letters, fundraise materials (data room, pitch deck) — drafted from portfolio data with the fund's voice and finalized by the IR team. Related: portfolio-pulse-dashboard, follow-on-decision-engine , { q: "What's the voice-preservation approach?", a: "Fine-tuned on the fund's historical communications — typically two-to-three years of quarterly updates and annual letters. The drafts read in the fund's voice; the IR team finalizes the strategic framing.", }, { q: "Does it hallucinate portfolio numbers?", a: "Numbers come from the data layer (Portfolio Pulse Dashboard, fund accounting), inserted via structured templating. The LLM writes the prose; the LLM doesn't generate the financials.", }, { q: "How does it handle the 'good news' bias problem in investor updates?", a: "Configurable per fund. Some IR teams want neutral framing; others want the partner-tonality preserved. The engine generates a neutral-baseline draft and a partner-tonality draft side-by-side; the IR team chooses which to ship.", }, { q: "Pricing?", a: "Scoped to communication cadence and the breadth of document types covered. Discovery call covers both.", }, ], }; ## What this is The fund's communications surface, automated where the work is mechanical. Three planes: - **Recurring communications.** Quarterly investor updates, annual LP letters, capital-call notices. Drafted on cadence, finalized by IR. - **One-off communications.** Fundraise pitch decks, data-room assembly for prospective LPs, ad-hoc partner-letter generation. On-demand. - **Personalization layer.** Per-LP framing where the LP base is segmented (institutional vs. family-office LPs may receive different framings of the same underlying data). ## How it's built Same architecture as the FO Family Report Drafter — fine-tuned LLM for voice, structured templating for numbers, per-recipient parameterization. The differences are domain: VC track-record artifacts (IRR by vintage, deal-by-deal returns, attribution analysis) instead of FO multi-entity accounting. ## What you get - The fine-tuned drafting model deployed to your fund. - Templates for the canonical communication types. - Per-LP parameterization configured to the LP base. - The IR review UI with markup-and-finalize workflow. - Fundraise data-room assembly and refresh. FAQ: - Q: How does this handle the fundraise data room specifically? A: Data-room assembly is the most labor-intensive piece — track record summaries per portco, deal-by-deal returns analysis, attribution decomposition, comparable-fund benchmarking. The engine pulls from the fund's accounting and portfolio data, generates the data-room artifacts to a documented template structure, and refreshes them through the fundraise process. - Q: What's the voice-preservation approach? A: Fine-tuned on the fund's historical communications — typically two-to-three years of quarterly updates and annual letters. The drafts read in the fund's voice; the IR team finalizes the strategic framing. - Q: Does it hallucinate portfolio numbers? A: Numbers come from the data layer (Portfolio Pulse Dashboard, fund accounting), inserted via structured templating. The LLM writes the prose; the LLM doesn't generate the financials. - Q: How does it handle the 'good news' bias problem in investor updates? A: Configurable per fund. Some IR teams want neutral framing; others want the partner-tonality preserved. The engine generates a neutral-baseline draft and a partner-tonality draft side-by-side; the IR team chooses which to ship. - Q: Pricing? A: Scoped to communication cadence and the breadth of document types covered. Discovery call covers both. --- ## HR Operations AI URL: https://orientedplatforms.com/suites/ai-implementation/hr-operations-ai Suite: ai-implementation Tier: Workflow & operations automation Engagement: 6–10 week build · ongoing operation Buyer: Heads of People · TA leads · People ops Problem: People ops accumulates routine work — resume screening for the high-volume reqs, interview scheduling across calendars, employee communications drafted from templates, onboarding workflows that should be automated and aren't. Deliverable: An AI layer over the People-Ops workflows — resume screening with bias-audit, interview scheduling, draft generation for employee communications, onboarding workflow automation. Integrates with the existing ATS and HRIS. Related: process-automation-agents, internal-knowledge-assistant , { q: "What about candidate experience?", a: "Configurable. Some businesses prefer fully-automated scheduling and standard responses; others prefer all candidate-facing communications human-reviewed. The engagement scopes the candidate-facing posture during discovery.", }, { q: "What HRIS systems do you integrate with?", a: "Workday, BambooHR, Rippling, Gusto, Justworks, plus custom platforms via standard API. The ATS layer (Greenhouse, Lever, Ashby) integrates separately.", }, { q: "Does it draft performance reviews or other sensitive communications?", a: "It can draft routine ones (offer letters, onboarding emails, policy reminders, anniversary notes). For sensitive communications (performance feedback, terminations, escalation responses), the engine surfaces the structure but the People-team writes the substance. We're explicit about where the line is.", }, { q: "Pricing?", a: "Scoped to employee count, hiring volume, and integration depth. Discovery call covers all three.", }, ], }; ## What this is A People-Ops augmentation engagement. Four components: - **Resume screening.** Per-req screening model with bias audit. Produces ranked list for the hiring manager. - **Interview scheduling.** Cross-calendar coordination, panel-building, candidate-side flexibility. - **Communications drafting.** Routine employee comms drafted from templates and trained patterns. Sensitive comms surfaced for human authoring. - **Onboarding automation.** Workflow orchestration across the systems involved (IT provisioning, payroll setup, document collection, training enrollment). ## How it's built LightGBM with monotonic constraints for the screening layer (interpretability matters for bias defense). Calendar-integration for scheduling. LLM layer for drafting. Workflow orchestration (Temporal-class for the complex onboarding pipelines) integrated with the HRIS and ATS. ## What you get - The screening pipeline with bias-audit documentation. - The interview-scheduling layer. - The communications-draft system with review workflow. - The onboarding workflow automation. - Quarterly bias-audit refresh and model retraining. FAQ: - Q: How do you handle bias in resume screening? A: Carefully and explicitly. The screening model is audited for bias against the standard protected-class proxy variables. Demographic correlations get surfaced and pruned. The screening produces a ranked list with confidence; the hiring manager makes the decision. We document the bias-audit methodology per engagement. - Q: What about candidate experience? A: Configurable. Some businesses prefer fully-automated scheduling and standard responses; others prefer all candidate-facing communications human-reviewed. The engagement scopes the candidate-facing posture during discovery. - Q: What HRIS systems do you integrate with? A: Workday, BambooHR, Rippling, Gusto, Justworks, plus custom platforms via standard API. The ATS layer (Greenhouse, Lever, Ashby) integrates separately. - Q: Does it draft performance reviews or other sensitive communications? A: It can draft routine ones (offer letters, onboarding emails, policy reminders, anniversary notes). For sensitive communications (performance feedback, terminations, escalation responses), the engine surfaces the structure but the People-team writes the substance. We're explicit about where the line is. - Q: Pricing? A: Scoped to employee count, hiring volume, and integration depth. Discovery call covers all three. --- ## Internal Knowledge Assistant URL: https://orientedplatforms.com/suites/ai-implementation/internal-knowledge-assistant Suite: ai-implementation Tier: Document & knowledge intelligence Engagement: 6–10 week build · ongoing model maintenance Buyer: COOs · Heads of operations · Knowledge management leads Problem: Established businesses accumulate institutional knowledge that's hard to access — policy documents nobody remembers exist, runbooks scattered across SharePoint and Confluence, prior-project records that would answer the current project's questions, customer-history records that the service team can't find in time. Deliverable: An LLM-powered Q&A assistant on the business's internal document corpus — team-facing chat interface, permission-aware, with answer-with-citation so users can verify before acting. Related: document-intelligence-engine, customer-support-ai, conversational-portfolio-assistant , { q: "What about hallucination?", a: "Every answer is grounded in cited source documents. The assistant doesn't generate answers without retrievable backing; where the corpus doesn't contain the answer, it says so rather than making one up. We measure hallucination rate per engagement on a held-out question set.", }, { q: "How is permission handling done?", a: "Document-level permissions enforced at retrieval — the user only sees answers retrievable from documents they have access to. Integrates with the business's existing access controls (Active Directory, Okta, custom-role systems). The LLM doesn't bypass the access boundary.", }, { q: "What systems can it ingest from?", a: "Standard document management (SharePoint, Confluence, Google Drive, Notion). CRM (Salesforce, HubSpot). Ticket systems (Zendesk, Jira, Linear). Custom databases via direct connector. Per-engagement, the connector set is scoped to the business's actual systems.", }, { q: "Pricing?", a: "Scoped to corpus size and user-base size. Discovery call covers both.", }, ], }; ## What this is The team-facing knowledge access layer. Three planes: - **Corpus ingestion.** Per-source connectors. Indexing with embedding-based retrieval. Per-engagement fine-tuning on the business's terminology and document patterns. - **Permission-aware retrieval.** Document-level access controls integrated with the business's existing identity infrastructure. Users see only what they can see. - **Grounded Q&A.** Answers cite source documents. Hallucination bounded by retrieval — no answer without backing. ## How it's built Commercial-API LLM (Claude-class, GPT-class) for the inference layer, or on-prem Llama-class for businesses with that requirement. Embedding-based retrieval (commercial API for the common case, on-prem dense-embedding deployment for the sensitive case). Permission enforcement at the retrieval layer, audited per engagement. ## What you get - The connectors into the business's document systems. - The retrieval-and-answer infrastructure. - The permission-aware deployment. - A team-facing chat interface (Slack, Teams, web — your choice). - Hallucination-rate measurement and quarterly tuning. FAQ: - Q: How is this different from ChatGPT Enterprise or Copilot for the same use case? A: ChatGPT Enterprise and Copilot are excellent for the common case (Microsoft 365 corpus, Google Workspace corpus). The differences this product offers: connectors into systems beyond the canonical Microsoft/Google universe (custom databases, internal applications, niche document management systems), per-engagement fine-tuning on the business's terminology, and a permission architecture that integrates with the business's existing access controls. - Q: What about hallucination? A: Every answer is grounded in cited source documents. The assistant doesn't generate answers without retrievable backing; where the corpus doesn't contain the answer, it says so rather than making one up. We measure hallucination rate per engagement on a held-out question set. - Q: How is permission handling done? A: Document-level permissions enforced at retrieval — the user only sees answers retrievable from documents they have access to. Integrates with the business's existing access controls (Active Directory, Okta, custom-role systems). The LLM doesn't bypass the access boundary. - Q: What systems can it ingest from? A: Standard document management (SharePoint, Confluence, Google Drive, Notion). CRM (Salesforce, HubSpot). Ticket systems (Zendesk, Jira, Linear). Custom databases via direct connector. Per-engagement, the connector set is scoped to the business's actual systems. - Q: Pricing? A: Scoped to corpus size and user-base size. Discovery call covers both. --- ## Invoice & Bill-Pay Engine URL: https://orientedplatforms.com/suites/family-office/invoice-bill-pay-engine Suite: family-office Tier: Ingestion Engagement: 6–10 week build · year-round operation Buyer: Controllers · AP teams · Operations directors Problem: The family office pays hundreds of invoices a month — vendor management fees, household-staff payroll-adjacent, property maintenance, professional services, charitable. The AP workflow is manual, the GL-coding is by hand, the duplicate-invoice fraud risk is non-zero, and the controller spends real hours on it weekly. Deliverable: An AP pipeline that ingests invoices from email and vendor portals, classifies the vendor, predicts the GL code, suggests payment-batch timing, detects duplicates and anomalies, and posts to the ledger of record with audit trail. Related: statement-capital-call-ingestion-engine, multi-entity-consolidation-platform , { q: "How does duplicate detection work?", a: "Two layers. The first catches the obvious — same vendor, same amount, same date range, slightly different reference numbers (a common fraud pattern). The second catches the subtler case — invoice for services-already-delivered, matched against the property-service contract or staff-employment record. The duplicate flag goes to the controller for review, never auto-paid.", }, { q: "What's the GL-coding model?", a: "Trained on the FO's historical AP data — vendor-to-GL-code patterns the team has used for years. Where the FO has thin history (new family member's household, recently acquired property), the model leans on category-similarity from similar FO deployments. Coding stays controller-reviewable.", }, { q: "Can it handle the multi-entity allocation?", a: "Yes — for invoices that should split across entities (e.g., a property expense that allocates between the trust that owns the property and the family-member trust that uses it), the engine suggests the split based on historical patterns and configurable rules. Controller confirms before posting.", }, { q: "Pricing?", a: "Scoped to invoice volume and entity complexity. Discovery call covers both.", }, ], }; ## What this is An AP automation engagement built around the family office's specific transaction profile. Four layers: - **Intake.** Email-attachment, vendor-portal pulling (for vendors with portal-based invoicing), file-upload for one-offs. Per-vendor templates where the volume justifies, OCR-and-extract otherwise. - **Classification and coding.** Vendor identification, GL-code prediction, multi-entity allocation suggestion, payment-batch timing recommendation. All controller-reviewable. - **Duplicate and anomaly detection.** Standard duplicate patterns plus services-already-delivered pattern. Flags routed to controller; never auto-paid. - **Payment execution and posting.** Integration with the FO's bank or payment provider for execution, structured posting to the ledger with audit trail. ## How it's built Document AI for extraction, classification model trained on the FO's historical AP, rule engine for the multi-entity allocation logic. Integrations into the FO's bank ACH platform, AtlasFive / Sage / QuickBooks for ledger posting. Audit trail in append-only event log. ## What you get - The AP intake and processing pipeline. - The vendor-classification and GL-coding models. - The duplicate-and-anomaly detection layer. - The controller review UI with approval workflow. - The payment-execution integration. FAQ: - Q: Why an FO-specific AP product instead of standard AP tools? A: Standard AP tools (Bill.com, Tipalti) are built for the typical-business AP profile. FO AP has different shape: more entities, more household-and-property vendors that don't fit standard B2B categorization, more sensitivity to private-vendor relationships, more requirement for audit trail per family member's expense allocation. The product is built for that shape. - Q: How does duplicate detection work? A: Two layers. The first catches the obvious — same vendor, same amount, same date range, slightly different reference numbers (a common fraud pattern). The second catches the subtler case — invoice for services-already-delivered, matched against the property-service contract or staff-employment record. The duplicate flag goes to the controller for review, never auto-paid. - Q: What's the GL-coding model? A: Trained on the FO's historical AP data — vendor-to-GL-code patterns the team has used for years. Where the FO has thin history (new family member's household, recently acquired property), the model leans on category-similarity from similar FO deployments. Coding stays controller-reviewable. - Q: Can it handle the multi-entity allocation? A: Yes — for invoices that should split across entities (e.g., a property expense that allocates between the trust that owns the property and the family-member trust that uses it), the engine suggests the split based on historical patterns and configurable rules. Controller confirms before posting. - Q: Pricing? A: Scoped to invoice volume and entity complexity. Discovery call covers both. --- ## iOS App Build URL: https://orientedplatforms.com/suites/ios-app-development/ios-app-build Suite: ios-app-development Tier: Full builds Engagement: 6–8 week build · App Store submission included Buyer: iOS founders · CEOs adding an iOS surface Problem: Founders shipping their first iOS app face a year of decisions about stack, monetization plumbing, App Store rules, and retention architecture. Most under-budget by 3×. Deliverable: A complete iOS app from concept to App Store — native SwiftUI, monetization wired (RevenueCat / Apple Pay / In-App Purchase), CloudKit sync, retention triggers, App Store submission and first review handled. Related: ios-app-store-optimization, ios-monetization-integration , { q: "What's in the 6–8 weeks?", a: "Week 1: scope lock, design system, architecture decisions. Weeks 2–5: build (SwiftUI surfaces, data layer, monetization, sync). Week 6: TestFlight beta, retention instrumentation, App Store assets. Weeks 7–8: App Store submission, review handling, post-launch monitoring. The timeline assumes the founder is decisive on product scope; if scope drifts, the timeline drifts with it.", }, { q: "What about App Store review rejections?", a: "Pre-submission review against the App Store Review Guidelines is part of the engagement. The first submission is typically approved on first or second pass. Where rejections happen, we handle the response and re-submission — that's included.", }, { q: "What if I need ongoing development after the build?", a: "Optional post-launch retainer at a different shape (smaller, monthly, with explicit scope per cycle). Or the build hands off to your in-house team with full documentation. The build itself is the deliverable; ongoing is opt-in.", }, { q: "Pricing?", a: "Fixed-fee for the standard build shape; scoped against complexity for non-standard apps (multi-platform sync, complex backend, heavy AI integration). Discovery call covers scope.", }, ], }; ## What this is A productized iOS app engagement for founders and businesses shipping their first iOS surface. Six to eight weeks from kickoff to App Store, with the assumption that you arrive decisive on product scope and we own the technical execution. Four phases inside the timeline: - **Lock.** Product scope, design system, monetization model, data shape. The decisions that get made here are the decisions the build operates against. We document them so changes are visible. - **Build.** Native SwiftUI surfaces, CloudKit + SwiftData persistence, RevenueCat for monetization, retention-instrumentation layer. Apple Human Interface Guidelines compliance is the bar, not a goal. - **Ship.** TestFlight beta, App Store assets (screenshots, copy, keywords), submission. First-review handling included. - **Land.** Post-launch monitoring of crash, retention, and conversion metrics. Documentation handoff if the founder takes the codebase in-house from there. ## How it's built Stack: Swift / SwiftUI for surfaces, SwiftData + CloudKit for persistence and sync, RevenueCat for monetization plumbing, Apple Pay + In-App Purchase for transactions, Push Notifications + Deep Linking for retention. AI-powered features (where in scope) layer on top via the OpenAI or Anthropic SDKs with on-device fallbacks where the use case warrants. Widget support for retention-critical surfaces. ## What you get - A native iOS app shipped to the App Store. - Source code with documentation. - App Store listing and post-submission review handled. - Retention-instrumentation hooked to your analytics platform. - Monetization wired and tested end-to-end. - Post-launch monitoring for the first 30 days. FAQ: - Q: Why native SwiftUI and not React Native or Flutter? A: Cross-platform frameworks ship faster on day one and underperform on day ninety — animation polish, system-integration consistency, and App Store review-pass rates all favor native. For an MVP that has to actually retain users, native wins. We're upfront when a cross-platform approach is the right call (rare in iOS-first markets). - Q: What's in the 6–8 weeks? A: Week 1: scope lock, design system, architecture decisions. Weeks 2–5: build (SwiftUI surfaces, data layer, monetization, sync). Week 6: TestFlight beta, retention instrumentation, App Store assets. Weeks 7–8: App Store submission, review handling, post-launch monitoring. The timeline assumes the founder is decisive on product scope; if scope drifts, the timeline drifts with it. - Q: What about App Store review rejections? A: Pre-submission review against the App Store Review Guidelines is part of the engagement. The first submission is typically approved on first or second pass. Where rejections happen, we handle the response and re-submission — that's included. - Q: What if I need ongoing development after the build? A: Optional post-launch retainer at a different shape (smaller, monthly, with explicit scope per cycle). Or the build hands off to your in-house team with full documentation. The build itself is the deliverable; ongoing is opt-in. - Q: Pricing? A: Fixed-fee for the standard build shape; scoped against complexity for non-standard apps (multi-platform sync, complex backend, heavy AI integration). Discovery call covers scope. --- ## iOS App Store Optimization URL: https://orientedplatforms.com/suites/ios-app-development/ios-app-store-optimization Suite: ios-app-development Tier: Specialized engagements Engagement: 3–5 week sprint · ongoing iteration optional Buyer: iOS app operators · indie developers · DTC brands with iOS surface Problem: Most apps on the App Store ship with a one-time-written listing and never revisit it. ASO is the difference between organic discovery and being invisible. Deliverable: Refreshed App Store listing — keyword strategy, copy, screenshot and video assets — plus a measurement framework for ongoing iteration. Related: ios-app-build, ios-monetization-integration , { q: "How long until ASO impact shows up?", a: "Keyword ranking shifts typically land within 2–4 weeks of submission. Conversion-rate impact from refreshed screenshots is faster (days). Cumulative organic-install lift takes 6–12 weeks to stabilize.", }, { q: "Do you handle localizations?", a: "Primary engagement covers English. Additional locales scoped per market (we focus on the 2–3 that move the most installs for your app rather than spreading across 30).", }, { q: "Pricing?", a: "Fixed-fee per market. Discovery call covers scope.", }, ], }; ## What this is An ASO engagement for iOS apps already on the App Store. Three to five weeks, focused on the parts of ASO that actually move install velocity. ## What you get - Keyword strategy with per-keyword ranking targets. - Refreshed listing copy (title, subtitle, description). - Screenshot set optimized for conversion (8 screens). - Preview video if app warrants. - Measurement framework for ongoing iteration. FAQ: - Q: What's actually changed when the engagement ends? A: App Store listing copy (title, subtitle, description, keyword field), screenshot set (8 screenshots optimized for conversion), preview video where the app supports it, and a per-keyword tracking framework so future iteration is measurable. - Q: How long until ASO impact shows up? A: Keyword ranking shifts typically land within 2–4 weeks of submission. Conversion-rate impact from refreshed screenshots is faster (days). Cumulative organic-install lift takes 6–12 weeks to stabilize. - Q: Do you handle localizations? A: Primary engagement covers English. Additional locales scoped per market (we focus on the 2–3 that move the most installs for your app rather than spreading across 30). - Q: Pricing? A: Fixed-fee per market. Discovery call covers scope. --- ## iOS Monetization Integration URL: https://orientedplatforms.com/suites/ios-app-development/ios-monetization-integration Suite: ios-app-development Tier: Specialized engagements Engagement: 2–4 week sprint · production-ready monetization Buyer: iOS app operators · founders adding monetization · indie devs Problem: Apple's monetization stack (StoreKit, Apple Pay, IAP) is the most under-rated reason apps fail to convert. The plumbing is unforgiving — receipt validation, restore handling, edge-case states — and the costs of getting it wrong are real revenue. Deliverable: Production-grade monetization integration — RevenueCat backbone, paywall flows tested against the App Store Review Guidelines, receipt validation, restore-purchase handling, subscription lifecycle events wired into your analytics. Related: ios-app-build, ios-app-store-optimization , { q: "What paywall designs do you build?", a: "Per-app, tuned to your conversion model — single-tier vs. multi-tier, free trial vs. discount, regional pricing. The implementation supports A/B testing through RevenueCat experiments. Design is informed by your app's specific user funnel.", }, { q: "What about Apple's review process?", a: "All paywall flows pre-tested against the App Store Review Guidelines (Section 3 in particular — auto-renewable subscriptions). The first submission with monetization typically passes; where rejection happens, response and resubmission is included.", }, { q: "Pricing?", a: "Fixed-fee for the standard integration shape. Discovery call covers scope.", }, ], }; ## What this is A monetization integration engagement for iOS apps — getting Apple's payment stack production-ready without re-inventing it. ## What you get - RevenueCat backbone configured for your app. - Paywall flows reviewed against the App Store Review Guidelines. - Receipt validation and restore-purchase handling. - Subscription lifecycle events wired into your analytics. - A/B testing infrastructure for paywall optimization. FAQ: - Q: Why RevenueCat and not raw StoreKit? A: RevenueCat absorbs the worst of StoreKit's pain — receipt validation across Apple's complex purchase states, subscription lifecycle events, cross-platform unification when you later add Android, integrations with analytics platforms. The cost-vs-build tradeoff is decisively in RevenueCat's favor for ~95% of apps. - Q: What paywall designs do you build? A: Per-app, tuned to your conversion model — single-tier vs. multi-tier, free trial vs. discount, regional pricing. The implementation supports A/B testing through RevenueCat experiments. Design is informed by your app's specific user funnel. - Q: What about Apple's review process? A: All paywall flows pre-tested against the App Store Review Guidelines (Section 3 in particular — auto-renewable subscriptions). The first submission with monetization typically passes; where rejection happens, response and resubmission is included. - Q: Pricing? A: Fixed-fee for the standard integration shape. Discovery call covers scope. --- ## K-1 Extraction & Validation Engine URL: https://orientedplatforms.com/suites/family-office/k-1-extraction-engine Suite: family-office Tier: Ingestion Engagement: 8–12 week build · annual tax-season operation Buyer: CFOs · Controllers · Tax operations leads Problem: Tax season at a family office means hundreds of K-1 PDFs arriving in irregular formats over six weeks — 200+ extractable fields each, manual entry to the GL, manual reconciliation against the partnership filings the CFO already received. Deliverable: A document-AI pipeline that ingests the K-1 corpus as it arrives, extracts all 200+ fields with confidence scores, maps to the FO's chart of accounts, flags inconsistencies against partnership returns, and posts to AtlasFive (or your fund-accounting system) with audit trail. Related: statement-capital-call-ingestion-engine, multi-entity-consolidation-platform , { q: "We use AtlasFive. Does this integrate?", a: "Yes — AtlasFive integration is the canonical case. We also support Sage Intacct, QuickBooks, NetSuite, and custom-built FO ledgers. The pipeline writes structured journal entries with the K-1 source linked so the controller can audit back to the source PDF.", }, { q: "What about state K-1s and amended K-1s?", a: "State K-1s are supported (each state's format is registered as a layout). Amended K-1s flow through a separate path — when an amended K-1 arrives for a partnership the engine has already processed, the controller gets the diff with both versions side-by-side and a one-click reposting workflow once they accept.", }, { q: "How do you handle the partnership filings cross-check?", a: "If your fund-accounting system has the partnership returns ingested, the engine cross-checks K-1 reported income against the partnership-level allocations and flags discrepancies. Where the FO has direct partnership relationships (LP into managed funds), this catches the 'partnership says $X, K-1 says $Y' problem before it reaches the tax preparer.", }, { q: "Pricing?", a: "Scoped to K-1 volume and integration surface. Discovery call covers both.", }, ], }; ## What this is A document-AI pipeline for the single most painful annual workflow in a family office. Four layers: - **Ingestion.** Email-attachment and SFTP intake. Per-partnership tracking so the controller can see what's arrived and what's still outstanding. - **Extraction.** All 200+ K-1 fields with per-field confidence scoring. Standard layouts processed end-to-end automatically; layout anomalies routed to review. - **Validation.** Cross-check against partnership returns where available. Internal consistency checks within the K-1 itself. Year-over-year reasonableness for recurring partnerships. - **Posting.** Structured journal entries to AtlasFive / Sage Intacct / QuickBooks / NetSuite / custom FO ledger, with source-PDF linkage for audit trail. ## How it's built LayoutLM-class document model for the structured-field extraction, with per-partnership templates as a fast path. Validation rules expressed as a declarative rule engine — the rule library compounds as new anomaly patterns are caught and codified. Postgres for canonical storage, with the source PDFs versioned in cold storage. Integration adapters per fund-accounting system. ## What you get - The ingestion-and-extraction pipeline, running through tax season. - The review queue UI for the controller — low-confidence and amended-K-1 workflows. - Audit trail from source PDF to GL entry. - The validation rule library, documented and versioned. - Annual tax-season operation — we keep the pipeline current with new IRS K-1 form revisions. FAQ: - Q: What's the accuracy on extraction? A: On the standard K-1 layout, the model extracts 95%+ of fields at high confidence — those go straight to the GL with audit logging. The remaining 5% (low-confidence fields, layout anomalies, or fields the model hasn't seen before) go to a review queue the controller works through. Net effect on a typical tax season: the controller spends a few hours on edge cases instead of several weeks on routine entry. - Q: We use AtlasFive. Does this integrate? A: Yes — AtlasFive integration is the canonical case. We also support Sage Intacct, QuickBooks, NetSuite, and custom-built FO ledgers. The pipeline writes structured journal entries with the K-1 source linked so the controller can audit back to the source PDF. - Q: What about state K-1s and amended K-1s? A: State K-1s are supported (each state's format is registered as a layout). Amended K-1s flow through a separate path — when an amended K-1 arrives for a partnership the engine has already processed, the controller gets the diff with both versions side-by-side and a one-click reposting workflow once they accept. - Q: How do you handle the partnership filings cross-check? A: If your fund-accounting system has the partnership returns ingested, the engine cross-checks K-1 reported income against the partnership-level allocations and flags discrepancies. Where the FO has direct partnership relationships (LP into managed funds), this catches the 'partnership says $X, K-1 says $Y' problem before it reaches the tax preparer. - Q: Pricing? A: Scoped to K-1 volume and integration surface. Discovery call covers both. --- ## Lease Abstraction Engine URL: https://orientedplatforms.com/suites/real-estate/lease-abstraction-engine Suite: real-estate Tier: For RE operators Engagement: 6–10 week build · ongoing operation Buyer: Lease administration teams · Asset managers · Acquisitions teams Problem: Commercial leases run 50–200 pages with 100+ extractable terms. Lease administration teams transcribe them into the lease abstract by hand, with the per-lease entry taking 4–8 hours of senior-analyst time and error rates that show up in rent-escalation cycles years later. Deliverable: A document-AI pipeline that extracts the canonical commercial-lease terms (commencement, term, base rent, escalation structure, option periods, expense pass-through structure, exclusions, default triggers, transfer restrictions) into a structured database — with confidence scoring, review queue, and audit trail back to source. Related: dynamic-rental-pricing-engine , { q: "What's the extraction accuracy?", a: "On standard commercial leases, 92–96% of fields extracted at high confidence. Standard fields (commencement, term, base rent, escalation type) hit higher; complex fields (expense exclusion language, non-standard option terms) hit lower with explicit confidence flags. The review queue handles the low-confidence cases.", }, { q: "Can it handle amendments and side letters?", a: "Yes — amendment processing is the harder case. When an amendment arrives for an already-abstracted lease, the engine produces a diff highlighting which terms changed, with the prior version preserved in the audit history. The lease admin team confirms before posting.", }, { q: "What about non-English leases?", a: "US-English at launch. UK-English supported. Other languages and jurisdictions per-engagement, with explicit caveats about per-jurisdiction term-extraction calibration.", }, { q: "Pricing?", a: "Scoped to lease volume and lease-complexity profile. Discovery call covers both.", }, ], }; ## What this is A lease abstraction platform for operators with portfolios where the lease-administration workload scales linearly with portfolio size — and where the cost of an abstraction error (missed escalation, missed option deadline) shows up years later in lost revenue. Three layers: - **Document ingestion.** Lease PDFs, amendments, side letters — single-document or bulk-upload. Per-jurisdiction template recognition. - **Extraction.** 100+ canonical terms extracted with per-field confidence. Standard commercial-lease structure plus the long tail of non-standard provisions. - **Operator surface.** Lease abstract database with structured search, review queue for low-confidence fields, audit trail back to source PDFs. ## How it's built LayoutLM-class document AI for the structured fields, dedicated clause-extraction models (BERT-class fine-tuned on commercial-lease corpus) for the legal-language fields, rule-based post-processing for the cross-field consistency (e.g., commencement + term must produce expiration). Integration with lease-administration platforms (Yardi, MRI, AppFolio) for posting. ## What you get - The lease abstraction pipeline running against your document corpus. - The structured lease database with audit trail. - Review-queue UI for the lease administration team. - Amendment-diff workflow. - Integration into your lease-admin platform of choice. FAQ: - Q: How is this different from LeaseLense, Trullion, or VTS lease abstraction? A: Those are mature products and handle the standard cases well — typical retail and office leases. This product is differentiated for the harder cases: industrial leases with complex expense pass-throughs, mixed-use leases with multiple use categories, ground leases with non-standard structures. Where the standard products handle the common patterns, ours handles the long tail. Many operators use both. - Q: What's the extraction accuracy? A: On standard commercial leases, 92–96% of fields extracted at high confidence. Standard fields (commencement, term, base rent, escalation type) hit higher; complex fields (expense exclusion language, non-standard option terms) hit lower with explicit confidence flags. The review queue handles the low-confidence cases. - Q: Can it handle amendments and side letters? A: Yes — amendment processing is the harder case. When an amendment arrives for an already-abstracted lease, the engine produces a diff highlighting which terms changed, with the prior version preserved in the audit history. The lease admin team confirms before posting. - Q: What about non-English leases? A: US-English at launch. UK-English supported. Other languages and jurisdictions per-engagement, with explicit caveats about per-jurisdiction term-extraction calibration. - Q: Pricing? A: Scoped to lease volume and lease-complexity profile. Discovery call covers both. --- ## Legal & Compliance Document Summarizer URL: https://orientedplatforms.com/suites/family-office/legal-compliance-document-summarizer Suite: family-office Tier: Ingestion Engagement: 6–10 week build · ongoing operation Buyer: FO General Counsel · Outside counsel · Controller Problem: Trust documents, family-office contracts, foundation governance, real-property documents, employment agreements — the legal corpus accumulates faster than the GC has time to read it. Routine review (lease renewals, vendor contract anniversaries, trust-amendment cycles) sits in a backlog. Deliverable: An LLM-and-extraction layer over the FO's legal document corpus — summarizes incoming documents, extracts and tracks key clauses, surfaces anomalies against precedent, generates working drafts for routine review. Related: k-1-extraction-engine, multi-entity-consolidation-platform , { q: "What's the scope of 'legal documents' here?", a: "Trust agreements and amendments, partnership agreements (the LP-side documents), real-property lease and purchase documents, employment agreements (household staff and FO employees), vendor contracts above a materiality threshold, regulatory correspondence (state filings, beneficiary notifications). Configurable per FO.", }, { q: "How do you handle confidentiality given the sensitivity of FO legal documents?", a: "Documents stay in the FO's environment. The LLM layer runs against your infrastructure (cloud, on-prem, hybrid — your call) with no external data sharing. Where we use commercial models (GPT-class, Claude-class), we use API tiers that exclude inference data from training. Documented in the engagement.", }, { q: "What does the anomaly flagging actually catch?", a: "Three patterns. (1) Off-precedent terms — a new vendor contract that differs materially from the FO's standard. (2) Clause expirations and renewal dates that need attention. (3) Cross-document inconsistencies — when a trust amendment and a partnership agreement conflict on a beneficiary's entitlement, for example. The GC reviews the flag; the engine doesn't make the call.", }, { q: "Pricing?", a: "Scoped to document corpus size and review cadence. Discovery call covers both.", }, ], }; ## What this is A review layer over the FO's legal document corpus — built for the GC who reads everything but only has time to read the things that matter. Three layers: - **Document ingestion and summarization.** Per-document summary in the GC's preferred style (length, focus, format), generated as documents enter the corpus. - **Clause tracking and anomaly flagging.** Key clauses (term, termination, indemnity, change-of-control, beneficiary entitlement, distribution waterfall) extracted and tracked. Anomalies against the FO's precedent surfaced. - **Working-draft generation.** For routine review (lease renewal letters, beneficiary notifications, standard vendor renewals), the engine drafts the working version; the GC reviews and finalizes. ## How it's built Document AI for layout-aware extraction, embedding-based precedent matching against the FO's historical document base, LLM-based summarization with controlled output style. Where the FO requires on-prem deployment, the LLM layer runs on local hardware; otherwise commercial-API inference with no-training tiers. ## What you get - The summarization pipeline running against new documents. - The clause-tracking dashboard for the GC. - The anomaly-flagging system with precedent comparison. - The working-draft generator for the routine document classes the GC identifies. - A documented confidentiality architecture for the FO's compliance team. FAQ: - Q: Does this replace outside counsel? A: No. Outside counsel does the judgment work — drafting, negotiation, novel-issue research. This handles the volume work — reading the contract before counsel does so the GC can focus the engagement on the parts that matter, summarizing meeting notes so the GC remembers what was discussed, tracking clause expirations so renewal review doesn't sit in a backlog. - Q: What's the scope of 'legal documents' here? A: Trust agreements and amendments, partnership agreements (the LP-side documents), real-property lease and purchase documents, employment agreements (household staff and FO employees), vendor contracts above a materiality threshold, regulatory correspondence (state filings, beneficiary notifications). Configurable per FO. - Q: How do you handle confidentiality given the sensitivity of FO legal documents? A: Documents stay in the FO's environment. The LLM layer runs against your infrastructure (cloud, on-prem, hybrid — your call) with no external data sharing. Where we use commercial models (GPT-class, Claude-class), we use API tiers that exclude inference data from training. Documented in the engagement. - Q: What does the anomaly flagging actually catch? A: Three patterns. (1) Off-precedent terms — a new vendor contract that differs materially from the FO's standard. (2) Clause expirations and renewal dates that need attention. (3) Cross-document inconsistencies — when a trust amendment and a partnership agreement conflict on a beneficiary's entitlement, for example. The GC reviews the flag; the engine doesn't make the call. - Q: Pricing? A: Scoped to document corpus size and review cadence. Discovery call covers both. --- ## Liquidity & Cash Forecasting Engine URL: https://orientedplatforms.com/suites/family-office/liquidity-cash-forecasting-engine Suite: family-office Tier: Forecasting + reporting Engagement: 8–12 week build · quarterly model refresh Buyer: CFOs · Treasury leads · Operations directors Problem: Family-office liquidity management is part forecasting and part scrambling — capital calls land with 10 days' notice, distributions arrive on uncertain schedules, household and property outflows are recurring but rarely modeled. Idle cash sits in checking; tight months catch the treasury team by surprise. Deliverable: A liquidity forecasting model trained on the family's inflow and outflow patterns plus macro signals (Fed rates, sector benchmarks for investment distributions) — surfaces predicted shortfalls and excesses 60 days ahead with the driving factors documented. Related: multi-entity-consolidation-platform, statement-capital-call-ingestion-engine , { q: "What data does the model need?", a: "Three to five years of monthly cash-flow history across the family's entities — sourced from the Multi-Entity Consolidation Platform if deployed, or a one-time backfill if not. Plus capital-call schedules from the GPs (where committed but not called), and household-spend forecasts the CFO maintains.", }, { q: "What does the 60-day alert actually look like?", a: "Weekly summary email to the CFO and treasury lead: liquidity position 60 days forward, projected shortfalls (if any) with the contributing capital calls and outflows, projected excesses with the contributing distributions. Color-graded by confidence. Drill-through to the source obligations.", }, { q: "Can it recommend cash deployments?", a: "It surfaces excesses with documented duration estimates. The deployment decision (sweep to money-market, deploy to T-bills, reserve for upcoming call) stays with the treasury team. We don't want this product to drift into investment-advice territory.", }, { q: "Pricing?", a: "Scoped to entity count and the depth of macro-signal integration. Discovery call covers both.", }, ], }; ## What this is A forecasting layer for family-wide liquidity. Three components: - **Inflow model.** Distribution forecasting per GP relationship (committed vs. uncommitted, vintage-based likelihood, manager-specific cadence), expected returns on direct holdings, recurring income. - **Outflow model.** Committed capital calls (with vintage-based call-rate priors for the uncalled commitment base), tax obligations (federal and state estimated payments per entity), household and property recurring spend, planned philanthropic distributions. - **Reconciliation and alerts.** Net position projected weekly across the 60-day window. Alerts fire when projected position crosses CFO-configured thresholds. ## How it's built Statsmodels for the time-series baseline, PyMC for the Bayesian commitment-modeling (where small samples and strong priors meet), LightGBM for the non-linear household-spend modeling. Integrates with the Multi-Entity Consolidation Platform for the historical data layer. ## What you get - The forecasting model with documented assumptions and uncertainty bands. - The weekly alert summary to the CFO and treasury lead. - The committed-but-uncalled commitment tracker with vintage-anchored call-rate priors. - Quarterly model refresh — retrained on the new data, recalibrated against the prior quarter's actual. - Documented methodology for the CFO's auditor. FAQ: - Q: How accurate is the forecast given how irregular FO cash flows are? A: Distributions and capital calls are the noisy half. The model surfaces the expected range with explicit uncertainty, not point estimates pretending to be certain. Where the variance is high (early-stage VC vintages, opportunistic real-estate distributions), the alert thresholds widen so the controller isn't drowning in false positives. - Q: What data does the model need? A: Three to five years of monthly cash-flow history across the family's entities — sourced from the Multi-Entity Consolidation Platform if deployed, or a one-time backfill if not. Plus capital-call schedules from the GPs (where committed but not called), and household-spend forecasts the CFO maintains. - Q: What does the 60-day alert actually look like? A: Weekly summary email to the CFO and treasury lead: liquidity position 60 days forward, projected shortfalls (if any) with the contributing capital calls and outflows, projected excesses with the contributing distributions. Color-graded by confidence. Drill-through to the source obligations. - Q: Can it recommend cash deployments? A: It surfaces excesses with documented duration estimates. The deployment decision (sweep to money-market, deploy to T-bills, reserve for upcoming call) stays with the treasury team. We don't want this product to drift into investment-advice territory. - Q: Pricing? A: Scoped to entity count and the depth of macro-signal integration. Discovery call covers both. --- ## Logistics & Routing Optimizer URL: https://orientedplatforms.com/suites/operations-algorithms/logistics-routing-optimizer Suite: operations-algorithms Tier: Operations research Engagement: 8–14 week build · ongoing operation Buyer: Logistics directors · Operations managers · Distribution leads Problem: Last-mile and distribution routing decisions are made in spreadsheets or by dispatcher intuition — both of which produce routes that look reasonable but are demonstrably non-optimal against fuel, time, and vehicle-capacity constraints. Deliverable: A routing-and-distribution optimization engine — solves vehicle routing problem (VRP) variants for the business's fleet and constraints, produces daily route assignments with documented cost reduction vs. the prior method. Related: workforce-scheduling-engine, production-resource-planner , { q: "Which VRP variants do you handle?", a: "Standard CVRP (capacitated), VRPTW (with time windows), MDVRP (multi-depot), VRPPD (pickup-and-delivery). Where the business has constraint variants we haven't pre-built (e.g., driver-skill matching, multi-trip-per-vehicle, fleet heterogeneity), we extend the formulation.", }, { q: "What's the typical cost reduction?", a: "Vs. dispatcher-intuition routing: typically 8–18% reduction in vehicle-miles, with similar effects on fuel and time. Vs. spreadsheet routing with reasonable manual heuristics: typically 4–10%. The engagement scopes a baseline measurement so the reduction is measurable, not asserted.", }, { q: "How does it handle dynamic changes during the day?", a: "Re-optimization runs as needed — for fleets with mid-day stop additions or route disruption, the engine re-solves against the updated constraint set. Latency is sub-minute for typical fleet sizes; for very large fleets the engagement scopes the architectural changes required.", }, { q: "Pricing?", a: "Scoped to fleet size, constraint complexity, and integration depth. Discovery call covers all three.", }, ], }; ## What this is A classical-OR routing engagement for logistics operations where routing decisions move real cost. Three layers: - **Problem formulation.** The business's routing problem expressed as a VRP variant with the specific constraints encoded — time windows, vehicle capacity, driver skill, pickup-and-delivery sequencing, multi-depot logic. - **Solver.** Gurobi or OR-Tools, depending on license and scale. Hybrid heuristic-plus-exact methods for the larger problem instances. - **Operational integration.** Daily route generation, dispatcher UI for review and override, integration into the fleet's telematics or routing system for execution. ## How it's built OR-Tools as the default solver, Gurobi where the business already licenses or where the problem scale justifies. Python orchestration layer for the daily problem formulation and result post-processing. Dispatcher UI in a lightweight web app. ## What you get - The formulated VRP variant with documented constraint handling. - The solver deployment. - Daily route generation pipeline. - Dispatcher UI for review and override. - Baseline-and-improvement measurement documentation. FAQ: - Q: Why classical OR instead of ML? A: Routing has well-understood mathematical structure (vehicle routing problem, traveling salesman, related variants). Classical OR solvers (Gurobi, OR-Tools) produce optimal-or-near-optimal solutions deterministically, with explainable constraint handling. ML approaches to routing exist but underperform classical methods on well-defined problems with hard constraints. We use ML where ML is the right tool; for routing, OR is the right tool. - Q: Which VRP variants do you handle? A: Standard CVRP (capacitated), VRPTW (with time windows), MDVRP (multi-depot), VRPPD (pickup-and-delivery). Where the business has constraint variants we haven't pre-built (e.g., driver-skill matching, multi-trip-per-vehicle, fleet heterogeneity), we extend the formulation. - Q: What's the typical cost reduction? A: Vs. dispatcher-intuition routing: typically 8–18% reduction in vehicle-miles, with similar effects on fuel and time. Vs. spreadsheet routing with reasonable manual heuristics: typically 4–10%. The engagement scopes a baseline measurement so the reduction is measurable, not asserted. - Q: How does it handle dynamic changes during the day? A: Re-optimization runs as needed — for fleets with mid-day stop additions or route disruption, the engine re-solves against the updated constraint set. Latency is sub-minute for typical fleet sizes; for very large fleets the engagement scopes the architectural changes required. - Q: Pricing? A: Scoped to fleet size, constraint complexity, and integration depth. Discovery call covers all three. --- ## LP Reporting Engine URL: https://orientedplatforms.com/suites/private-equity/lp-reporting-engine Suite: private-equity Tier: Exit + LP Engagement: 10–16 week build · ongoing reporting cycle Buyer: Finance teams · IR teams · CFOs Problem: Quarterly LP reporting consumes the finance team for two weeks every quarter — calculating IRR and MOIC across vehicles, generating per-LP PDFs in each LP's preferred format, populating portal templates, then K-1 and 1099 XML exports at year-end. The work is mechanical, and the finance team would rather spend the time on anything else. Deliverable: An automated reporting pipeline — calculates IRR / MOIC / DPI / TVPI per vehicle, generates per-LP report PDFs in each LP's preferred format, populates LP portals via API where available, produces ILPA-template-compliant ESG reports, and exports K-1 / 1099 XML for the year-end tax cycle. Related: portfolio-intelligence-platform, exit-prep-automation , { q: "What's the K-1 / 1099 XML piece?", a: "The IRS XBRL / XML export formats for K-1 and 1099. The piece nobody enjoys building because the schemas are unforgiving and the tax cycle has hard deadlines. We build the export, validate it against the IRS schema, and integrate it with your fund-accounting system's tax workpaper output.", }, { q: "How do you handle the custom LP formats?", a: "Each LP has their own template — quarterly summary in a specific layout, capital-call notice in a specific format, certain calculations presented in certain ways. We build the per-LP template library, parameterized so when the LP requests a small change it's a config update, not a rebuild. The library compounds — engagement N covers the formats encountered to date, future LPs reuse or extend.", }, { q: "What's the audit-trail story?", a: "Every output is traceable: which fund-accounting snapshot produced which calculation, which template version generated which PDF, when each portal push happened. Auditors get a clean trail; LPs get versioned documents.", }, { q: "Pricing?", a: "Scoped to vehicle count, LP base size, and the breadth of custom-format requirements. Discovery call covers all three.", }, ], }; ## What this is An automated LP reporting pipeline for the boring half of fund operations — the mechanical work the finance team would gladly hand off. Four planes: - **Performance calculation.** IRR, MOIC, DPI, TVPI per vehicle, per LP, per share class. Audited against the fund-accounting system's source of record. - **Document generation.** Per-LP PDFs in each LP's preferred format, parameterized for layout, branding, and disclosure requirements. ILPA-template-compliant where the LP requires it. - **Portal population.** API integration where the LP's portal supports it; file-drop or email delivery otherwise. Audit trail on every push. - **Tax export.** K-1 and 1099 XML in IRS-compliant XBRL / XML. Schema-validated before submission. ## How it's built Postgres for the calculation layer, dbt for the transformation logic, reportlab or weasyprint for PDF generation, requests-class pipelines for portal APIs. Tax-export layer uses the IRS published schemas with our own schema-validation tooling. Audit trail in append-only event log. ## What you get - The performance-calculation pipeline, audited against fund-accounting source. - The per-LP template library, parameterized. - The portal-push pipeline with audit trail. - The K-1 / 1099 XML exporter, validated against IRS schema. - Ongoing reporting-cycle support — quarterly and year-end. FAQ: - Q: We use AtlasFive for fund accounting. Does this replace it? A: No — it sits on top. AtlasFive (or your preferred fund-accounting system) remains the system of record. This pipeline reads from it, applies the LP-specific reporting transformations, generates the deliverables, and pushes to portals. Same pattern works with Investran, eFront, or whatever your firm uses. - Q: What's the K-1 / 1099 XML piece? A: The IRS XBRL / XML export formats for K-1 and 1099. The piece nobody enjoys building because the schemas are unforgiving and the tax cycle has hard deadlines. We build the export, validate it against the IRS schema, and integrate it with your fund-accounting system's tax workpaper output. - Q: How do you handle the custom LP formats? A: Each LP has their own template — quarterly summary in a specific layout, capital-call notice in a specific format, certain calculations presented in certain ways. We build the per-LP template library, parameterized so when the LP requests a small change it's a config update, not a rebuild. The library compounds — engagement N covers the formats encountered to date, future LPs reuse or extend. - Q: What's the audit-trail story? A: Every output is traceable: which fund-accounting snapshot produced which calculation, which template version generated which PDF, when each portal push happened. Auditors get a clean trail; LPs get versioned documents. - Q: Pricing? A: Scoped to vehicle count, LP base size, and the breadth of custom-format requirements. Discovery call covers all three. --- ## Macro Risk Overlay URL: https://orientedplatforms.com/suites/hedge-fund/macro-risk-overlay Suite: hedge-fund Tier: Portfolio & risk Engagement: 12–16 week engagement · quarterly model review Buyer: CIOs · CROs · Portfolio construction leads Problem: Position sizing and hedging are usually intuition-anchored at the desk level — fine in steady regimes, dangerous when the regime breaks. Funds want a system that classifies the regime, scales exposures accordingly, and surfaces the moments when the regime is shifting before the P&L tells them. Deliverable: A regime classifier trained on rates, vol, credit-spread, and macro-data series — paired with a recommended position-sizing and hedging overlay that the portfolio construction team consumes alongside the existing risk framework. Related: alternative-data-signal-engine, prediction-market-alpha-layer , { q: "What macro variables drive the regime classification?", a: "Default features: short rate, long rate, term spread, vol (VIX + sector vol), credit spreads (IG + HY), USD index, gold/copper ratio, breakeven inflation. Hyperparameters and feature selection scoped to the strategy. The classifier is regularized — interpretability matters when the CIO has to explain why exposures got cut.", }, { q: "What does the overlay actually recommend?", a: "Three things. (1) Strategy-level exposure scaling — how much capital each strategy gets in the current regime. (2) Hedge recommendations — vol, credit, FX overlay sizing tied to regime confidence. (3) Transition alerts — surfaced when the regime classifier crosses confidence thresholds, with the underlying feature deltas driving the transition.", }, { q: "How do you avoid overfitting given how few regime breaks there are in history?", a: "Walk-forward validation with explicit attention to the small-sample problem. Multiple regime taxonomies stress-tested rather than picking the one that backtested best. CIO-side acceptance criteria explicitly include 'does this generalize past the training window' rather than just hit-rate on holdout. Where the data is thin, we say so out loud.", }, { q: "Pricing?", a: "Scoped against the data, the strategy mix, and the integration depth. Discovery call covers all three.", }, ], }; ## What this is A portfolio-level overlay engagement. Two paired deliverables: - **Macro regime classifier.** A model that classifies the current macro environment into a small number of regimes — inflationary vs. disinflationary, risk-on vs. risk-off, vol-expanding vs. vol-contracting, or whatever taxonomy the fund's strategy mix calls for. Probability-weighted, not hard-classified — the overlay needs uncertainty to size positions sanely. - **Position-sizing and hedging overlay.** Translates regime probabilities into strategy-level exposure scaling, hedge sizing recommendations, and transition alerts. Consumed by portfolio construction alongside the existing risk framework — not replacing it, layered on it. ## How it's built Backbone: a regularized classifier (Bayesian or LightGBM-with-monotonic-constraints, depending on interpretability requirements) trained on rates, vol, credit-spread, and macro-data series. Walk-forward validation with explicit attention to the small-sample problem. The overlay layer translates classifier output into recommendation through a fund-specific rule set scoped during the engagement. Integration: the overlay surfaces through your existing risk dashboards. No new system for the desk to check. ## What you get - The regime classifier model — trained, documented, version-controlled. - The overlay rule set — sizing and hedging recommendations tied to regime confidence. - Transition alerts wired into your existing risk infra. - Quarterly model review — the regime taxonomy retrained on rolling data, the rule set re-examined against the prior quarter's P&L. - Documentation written for the CIO and CRO, not the engineers. FAQ: - Q: How is this different from Bayesline / ALEX? A: Bayesline ships a packaged regime + risk-overlay product. We build a custom one — trained on your data, calibrated to your strategy mix, surfaced through your existing risk infra. If the packaged version fits your fund, buy it. If your strategy mix doesn't map cleanly onto a packaged product (multi-strat with idiosyncratic books, prop-trading-flavored macro, or anything where the canonical regime taxonomy doesn't apply), this is the engagement for the bespoke version. - Q: What macro variables drive the regime classification? A: Default features: short rate, long rate, term spread, vol (VIX + sector vol), credit spreads (IG + HY), USD index, gold/copper ratio, breakeven inflation. Hyperparameters and feature selection scoped to the strategy. The classifier is regularized — interpretability matters when the CIO has to explain why exposures got cut. - Q: What does the overlay actually recommend? A: Three things. (1) Strategy-level exposure scaling — how much capital each strategy gets in the current regime. (2) Hedge recommendations — vol, credit, FX overlay sizing tied to regime confidence. (3) Transition alerts — surfaced when the regime classifier crosses confidence thresholds, with the underlying feature deltas driving the transition. - Q: How do you avoid overfitting given how few regime breaks there are in history? A: Walk-forward validation with explicit attention to the small-sample problem. Multiple regime taxonomies stress-tested rather than picking the one that backtested best. CIO-side acceptance criteria explicitly include 'does this generalize past the training window' rather than just hit-rate on holdout. Where the data is thin, we say so out loud. - Q: Pricing? A: Scoped against the data, the strategy mix, and the integration depth. Discovery call covers all three. --- ## Multi-Entity Consolidation Platform URL: https://orientedplatforms.com/suites/family-office/multi-entity-consolidation-platform Suite: family-office Tier: Consolidation Engagement: 12–20 week build · ongoing data ops Buyer: CFOs · Controllers · Operations directors Problem: Wealth lives across dozens of entities — trusts, partnerships, holding companies, personal accounts, charitable foundations — each with its own ledger. The CFO sees the picture by manually consolidating from a stack of monthly reports. The principals see the picture even more rarely. Deliverable: A consolidation platform that ETLs from each entity's source-of-record system, normalizes to a unified chart of accounts, handles FX and intercompany eliminations, surfaces per-family-member and per-asset-type views, and enforces privacy partitions where the structure requires them. Related: conversational-portfolio-assistant, liquidity-cash-forecasting-engine, family-report-drafter , { q: "How does the privacy partitioning work?", a: "Per-family-member access controls expressed as row-level security in the data layer. The CFO sees everything; one principal sees their own entities and the consolidated family view; another principal might see only their direct holdings. The partition rules are documented per FO and enforced at the query layer, not the application layer.", }, { q: "What's the unified chart of accounts approach?", a: "A canonical CoA with per-entity mappings. Each entity's source ledger maps to the canonical structure; reports run against the canonical. When an entity changes its accounting (new categorization, restructured CoA), the mapping updates without breaking the reports.", }, { q: "How are intercompany eliminations handled?", a: "Inter-entity transfers tracked as a paired transaction set — a transfer from Trust A to Holding Co B shows up in both ledgers, eliminated at the consolidation layer. Where the FO's existing books have unrecorded intercompany legs, the platform surfaces them for the controller to resolve.", }, { q: "Pricing?", a: "Scoped to entity count and the source-system complexity. Discovery call covers both.", }, ], }; ## What this is The data infrastructure that makes the family office legible across entities. Three layers: - **ETL.** Per-entity connectors — accounting systems (AtlasFive, QuickBooks, NetSuite, Sage), custodian feeds, partnership statements (from the Statement & Capital-Call Ingestion Engine), trust accounting. Idempotent, retried, point-in-time. - **Normalization.** Unified chart of accounts with per-entity mappings. FX normalization at month-end. Intercompany elimination logic. - **Surface.** Per-family-member, per-entity-type, per-asset-class views. Privacy partitions enforced at the query layer. Drill-down to source entity and source transaction. ## How it's built Postgres or Snowflake as canonical storage, dbt for the transformation layer (with privacy partitioning expressed in dbt models), Prefect or Airflow for orchestration. Dashboard surfaces in Metabase, Hex, or a custom UI — the FO's preference. Privacy enforcement via row-level security at the database layer. ## What you get - The unified schema and chart-of-accounts mapping. - Per-entity ETL connectors maintained as ongoing data ops. - Dashboards configured to the FO's reporting standards. - Privacy-partition rules documented and enforced. - Runbook for the data ops team handing off the platform. FAQ: - Q: Doesn't Addepar already do this? A: Addepar does it well for the investment-portfolio half — performance, allocation, exposure across investment entities. This platform handles a broader scope: trust-level cash flows, operating-company holdings, partnership-level distributions, family-member expense allocation. Some FOs run both — Addepar for investment view, this for the operational consolidation. Others use this as the unified layer. - Q: How does the privacy partitioning work? A: Per-family-member access controls expressed as row-level security in the data layer. The CFO sees everything; one principal sees their own entities and the consolidated family view; another principal might see only their direct holdings. The partition rules are documented per FO and enforced at the query layer, not the application layer. - Q: What's the unified chart of accounts approach? A: A canonical CoA with per-entity mappings. Each entity's source ledger maps to the canonical structure; reports run against the canonical. When an entity changes its accounting (new categorization, restructured CoA), the mapping updates without breaking the reports. - Q: How are intercompany eliminations handled? A: Inter-entity transfers tracked as a paired transaction set — a transfer from Trust A to Holding Co B shows up in both ledgers, eliminated at the consolidation layer. Where the FO's existing books have unrecorded intercompany legs, the platform surfaces them for the controller to resolve. - Q: Pricing? A: Scoped to entity count and the source-system complexity. Discovery call covers both. --- ## Multi-Store Portfolio Intelligence URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/multi-store-portfolio-intelligence Suite: shopify-ops-intelligence Tier: Shopify-native operations Engagement: 10–16 week build · ongoing data ops Buyer: DTC holdco operators · PE portfolio teams · Multi-brand commercial leads Problem: DTC brand holdcos and multi-store portfolios run each store on its own Shopify admin, with each store's data living in its own silo. The cross-store view — which brands are growing, which are stalling, where the shared signals live — is assembled manually if at all. Deliverable: A portfolio platform — ETL across multiple Shopify stores into a unified analytical layer, cross-store and cross-brand dashboards, shared signal extraction (which products cross-perform, which customer patterns repeat across brands), portfolio-level operating alerts. Related: shopify-operations-workflow-automation, portfolio-intelligence-platform , { q: "What's the cross-store benchmarking layer?", a: "Per-brand metrics normalized for comparison — gross margin, conversion rate, AOV, repeat rate, CAC where the marketing-spend data is integrated. The holdco operator sees which brands are outperforming the portfolio average and which are dragging. Drill-down per brand to identify why.", }, { q: "What about shared-signal extraction across brands?", a: "Where the brands share customer overlap (typical for adjacent-category portfolios), the platform surfaces cross-brand customer patterns — customers who shop brand A also predictively shop brand B, products that share buyer demographics across brands. Useful for cross-brand merchandising and customer-acquisition strategy.", }, { q: "How is this different from the OAS / PE Portfolio Intelligence Platform?", a: "Similar shape, Shopify-specific. The PE version handles cross-portfolio-company data integration across diverse ERPs. This version specializes in Shopify's data model and storefront-level signals — better fit for DTC holdcos and multi-brand portfolios where every store is on Shopify.", }, { q: "Pricing?", a: "Scoped to store count and integration breadth. Discovery call covers both.", }, ], }; ## What this is The flagship Shopify-native product. Three layers: - **Multi-store ETL.** Per-store data pipeline (Shopify Plus org integration where available, per-store API otherwise) into a unified analytical layer. - **Cross-store analytics and benchmarking.** Normalized per-brand metrics for comparison. Portfolio-average benchmarks. Drill-down per store. - **Shared signal extraction.** Cross-brand customer overlap, product affinity across brands, demographic patterns shared across the portfolio. ## How it's built Per-store Shopify API connectors (Plus org or independent), Postgres or Snowflake for canonical storage, dbt for the normalization layer. Dashboard in Metabase, Hex, or a custom UI. Cross-brand customer-overlap analysis with privacy-preserving identifiers (hashed email matching, not raw PII). ## What you get - Per-store ETL connectors maintained as ongoing data ops. - The unified analytical layer. - Cross-store and cross-brand dashboards. - Shared-signal extraction surfaced for the holdco operator. - Privacy-preserving customer-overlap analysis. - Quarterly portfolio-review packaged document for the operator's IC or board. FAQ: - Q: How does it handle Shopify Plus organizations with multiple stores under one org? A: Shopify Plus org integration is the canonical case. Stores under one Plus org get unified at the data layer with documented org-and-store hierarchy. Stores outside a Plus org (independent Shopify subscriptions under common ownership) integrate via per-store API connections. - Q: What's the cross-store benchmarking layer? A: Per-brand metrics normalized for comparison — gross margin, conversion rate, AOV, repeat rate, CAC where the marketing-spend data is integrated. The holdco operator sees which brands are outperforming the portfolio average and which are dragging. Drill-down per brand to identify why. - Q: What about shared-signal extraction across brands? A: Where the brands share customer overlap (typical for adjacent-category portfolios), the platform surfaces cross-brand customer patterns — customers who shop brand A also predictively shop brand B, products that share buyer demographics across brands. Useful for cross-brand merchandising and customer-acquisition strategy. - Q: How is this different from the OAS / PE Portfolio Intelligence Platform? A: Similar shape, Shopify-specific. The PE version handles cross-portfolio-company data integration across diverse ERPs. This version specializes in Shopify's data model and storefront-level signals — better fit for DTC holdcos and multi-brand portfolios where every store is on Shopify. - Q: Pricing? A: Scoped to store count and integration breadth. Discovery call covers both. --- ## Real-Time Personalization for Shopify URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/personalization-shopify Suite: shopify-ops-intelligence Tier: Storefront & customer intelligence Engagement: 8–14 week deployment · custom packaging Buyer: DTC operators · Shopify-Plus brands · DTC engineering teams Problem: Product recommendations in Shopify themes are typically random or 'frequently bought together' — missing the per-user personalization that's available with proper recommendation infrastructure. Deliverable: A Shopify-tuned deployment of the canonical Real-Time Personalization API — surfaces recommendations through Shopify theme app extensions, native storefront sections, or headless storefront API integration. Related: real-time-personalization-api, customer-clustering-shopify , { q: "How does it integrate with the storefront?", a: "Three paths. Theme app extension for stores using Shopify's themes (drag-and-drop into Liquid). Native storefront sections for online-store-2.0 themes with section-based architecture. Headless storefront API for stores running custom React/Next.js fronts.", }, { q: "What about Shopify Hydrogen / headless storefronts?", a: "First-class supported. The recommendation API is REST + GraphQL; integration into Hydrogen storefronts is straightforward. Most Shopify-Plus stores running Hydrogen find this the easier integration vs. theme-app-extension.", }, { q: "What's the latency budget?", a: "Sub-100ms p99 for the API call. Theme rendering adds the Shopify rendering budget on top — total perceived latency depends on storefront performance.", }, { q: "Pricing?", a: "Custom deployment only — the integration depth varies enough that self-serve doesn't fit. Discovery call covers the tier.", }, ], }; ## What this is The canonical Real-Time Personalization API, tuned for Shopify storefront delivery. See the [canonical product page in the Operations Algorithms Suite](/suites/operations-algorithms/real-time-personalization-api) for the modeling backbone, recommendation stack, and SubMagician-integration detail. The Shopify-tuned tuning consists of: - Theme app extension for direct drag-and-drop integration into Shopify themes. - Native storefront-2.0 sections for Liquid-based themes. - Shopify Hydrogen / headless storefront API integration for stores running custom fronts. - Shopify Customer signal pipeline as the user-context source. ## What you get - The recommendation model deployed against your store's data. - Theme integration (theme app extension OR native sections OR headless API). - A/B test infrastructure for measuring lift on conversion and AOV. - Operator UI consistent with Shopify Admin. - Quarterly model refresh. FAQ: - Q: Doesn't Shopify already do 'frequently bought together' recommendations? A: Yes, at the basic level. The native recommendation surface uses popularity and co-purchase signal — useful but unpersonalized. This product layers personalized recommendations on top, using the full per-user signal (browsing history, past purchase, cluster assignment, contextual signal). - Q: How does it integrate with the storefront? A: Three paths. Theme app extension for stores using Shopify's themes (drag-and-drop into Liquid). Native storefront sections for online-store-2.0 themes with section-based architecture. Headless storefront API for stores running custom React/Next.js fronts. - Q: What about Shopify Hydrogen / headless storefronts? A: First-class supported. The recommendation API is REST + GraphQL; integration into Hydrogen storefronts is straightforward. Most Shopify-Plus stores running Hydrogen find this the easier integration vs. theme-app-extension. - Q: What's the latency budget? A: Sub-100ms p99 for the API call. Theme rendering adds the Shopify rendering budget on top — total perceived latency depends on storefront performance. - Q: Pricing? A: Custom deployment only — the integration depth varies enough that self-serve doesn't fit. Discovery call covers the tier. --- ## Portfolio Forecasting Engine URL: https://orientedplatforms.com/suites/private-equity/portfolio-forecasting-engine Suite: private-equity Tier: Hold Engagement: 8–12 week build · quarterly model refresh Buyer: Operating partners · Portco CFOs · Valuation teams Problem: Portco forecasts are spreadsheet-built, partner-adjusted, and rolled up to fund valuation through inconsistent assumptions. The result is a fund valuation that everyone trusts at a one-line summary level and no one trusts under the hood. Deliverable: Predictive forecasting models per portco — quarterly cash-flow and EBITDA projections trained on the portco's internal financials and sector-comparable data, with structured scenario planning (cost-cut sensitivity, price-elasticity scenarios, demand-shock testing) that feeds straight into the fund's valuation model. Related: portfolio-intelligence-platform, pricing-margin-optimizer , { q: "What data does the model need?", a: "Three years of monthly portco financials (P&L line-item depth, balance sheet, cash flow), the portco's customer-cohort or revenue-segment breakdown if relevant, and access to sector-comparable benchmarks (we provide the comparables layer). Where the portco has thinner history, we use sector-anchored priors with documented uncertainty.", }, { q: "How accurate are the forecasts?", a: "On stable mid-market portcos with three-plus years of history, the model's 90-day forecast typically tracks within 5–8% on EBITDA. On earlier-stage or post-acquisition-integration portcos, the band widens; we surface the uncertainty rather than hiding it. The valuation team consumes the forecast WITH the uncertainty band.", }, { q: "Does this replace the portco CFO's planning process?", a: "No. It runs in parallel — the portco CFO has the operating context, the engine has the cross-portfolio consistency and the scenario layer. Where they disagree, the disagreement itself is the useful artifact.", }, { q: "Pricing?", a: "Per-portco for build, ongoing for quarterly refresh. Discovery call covers the portco set.", }, ], }; ## What this is A forecasting layer for the fund's portfolio — replacing five inconsistent spreadsheet methodologies with one consistent model methodology applied per portco. Three components: - **Forecast models.** Time-series + driver-tree hybrid per portco, trained on internal financials and sector-comparable data. Quarterly cadence; monthly-grain output where the underlying data supports it. - **Scenario layer.** Structured what-ifs: cost-cut sensitivity, price-elasticity scenarios, demand-shock testing, FX scenarios for portcos with material non-domestic exposure. Feeds fund-level valuation models without manual re-modeling. - **Uncertainty surfacing.** Forecasts come with documented confidence bands. The valuation team consumes the forecast with the uncertainty, not as a point estimate. ## How it's built Statsmodels and PyMC for the time-series + Bayesian layers, LightGBM for non-linear driver modeling. Sector-comparable data sourced from your existing data infrastructure plus the public-comparables layer we maintain. Output served through the Portfolio Intelligence Platform if that's already in place, or as a standalone deliverable. ## What you get - Forecast models per portco, with documented assumptions and uncertainty bands. - The scenario library, configured to the fund's standard sensitivity set. - Quarterly refresh — the model retrained, the scenario library updated, the valuation hand-off packaged. - A methodology document the valuation team can stand behind when LPs ask how forecasts are built. FAQ: - Q: Our portcos already do their own forecasts. What's the value-add? A: Portco finance teams are great at the operating-detail layer; the platform sits on top with consistency. Same forecasting methodology applied across the portfolio means the valuation team isn't reconciling five different sets of assumptions when they roll up. And the scenario layer (cost-cut sensitivity, price-elasticity, demand shock) is what most portcos can't staff for. - Q: What data does the model need? A: Three years of monthly portco financials (P&L line-item depth, balance sheet, cash flow), the portco's customer-cohort or revenue-segment breakdown if relevant, and access to sector-comparable benchmarks (we provide the comparables layer). Where the portco has thinner history, we use sector-anchored priors with documented uncertainty. - Q: How accurate are the forecasts? A: On stable mid-market portcos with three-plus years of history, the model's 90-day forecast typically tracks within 5–8% on EBITDA. On earlier-stage or post-acquisition-integration portcos, the band widens; we surface the uncertainty rather than hiding it. The valuation team consumes the forecast WITH the uncertainty band. - Q: Does this replace the portco CFO's planning process? A: No. It runs in parallel — the portco CFO has the operating context, the engine has the cross-portfolio consistency and the scenario layer. Where they disagree, the disagreement itself is the useful artifact. - Q: Pricing? A: Per-portco for build, ongoing for quarterly refresh. Discovery call covers the portco set. --- ## Portfolio Intelligence Platform URL: https://orientedplatforms.com/suites/private-equity/portfolio-intelligence-platform Suite: private-equity Tier: Hold Engagement: 12–20 week build · ongoing data ops Buyer: Operating partners · GP principals · Portfolio teams Problem: Each portco has its own ERP, its own dashboards, its own monthly cadence. Operating partners see the book one portco at a time — by the time anomalies show up across the portfolio, two quarters have passed. Deliverable: A unified portfolio platform: ETL pipelines from each portco system (Excel, QuickBooks, NetSuite, Sage, Stripe) plus third-party data (Preqin, Bloomberg), normalized to a single schema, exposed through cross-portco dashboards with covenant tracking and liquidity alerts. Related: portfolio-forecasting-engine, pricing-margin-optimizer, post-acquisition-integration-tracker , { q: "What's the schema?", a: "A unified chart-of-accounts mapping with per-portco aliases, plus KPI definitions (gross margin, cash conversion, net retention, etc.) reconciled to your fund's reporting standards. Schema is documented and versioned — when a portco's accounting changes, the mapping updates without touching the dashboards.", }, { q: "What does covenant tracking actually look like?", a: "For each portco's debt covenants, the platform tracks the relevant ratios monthly and surfaces ratios approaching thresholds 60–90 days before a breach. The operating partner gets the alert with the underlying trajectory; the finance team gets the workspace to model the cure path.", }, { q: "How do you handle data quality issues from a portco that runs its books on Excel?", a: "Excel portcos are the common case in lower mid-market. The pipeline standardizes the templates, applies validation at ingest, and surfaces data-quality flags when the input drifts. We work with the portco finance team to fix structural issues; we don't pretend that bad data is good data.", }, { q: "Pricing?", a: "Scoped to portfolio size, source-system complexity, and integration depth. Discovery call covers all three.", }, ], }; ## What this is The data infrastructure layer that gives operating partners and GP principals a single, current view across the portfolio. Three planes: - **Ingestion.** Per-portco connectors — API-based where the portco's stack supports it, monthly-export pipeline where it doesn't. Idempotent, retried, point-in-time. - **Normalization.** Unified schema with per-portco mapping. Documented chart-of-accounts crosswalk, KPI reconciliation, currency normalization, intercompany elimination where relevant. - **Surface.** Cross-portco dashboards (KPI rollups, sector benchmarking, covenant tracking), liquidity alerts, configurable drill-down per portco. ## How it's built Postgres or Snowflake as canonical storage, dbt for the transformation layer, Prefect or Airflow for orchestration. Dashboard layer in Metabase, Superset, or whatever your firm already uses — we'd rather plug into your existing BI than introduce another tool. Per-portco connectors built once, maintained as a recurring data-ops engagement. ## What you get - The unified schema, documented and versioned. - Cross-portco dashboards in your existing BI layer. - Liquidity and covenant alerts wired into your firm's alerting infrastructure. - Data-quality monitoring that surfaces drift before it shows up in reporting. - Runbook for the ongoing data ops. FAQ: - Q: We've tried platform consolidation before and it failed because the portcos resisted. How is this different? A: The integration runs against existing systems — we don't ask the portco to migrate their ERP. The portco gets a read-only connector (or a monthly export pipeline if real-time isn't feasible). The friction surface is small enough that it usually clears. - Q: What's the schema? A: A unified chart-of-accounts mapping with per-portco aliases, plus KPI definitions (gross margin, cash conversion, net retention, etc.) reconciled to your fund's reporting standards. Schema is documented and versioned — when a portco's accounting changes, the mapping updates without touching the dashboards. - Q: What does covenant tracking actually look like? A: For each portco's debt covenants, the platform tracks the relevant ratios monthly and surfaces ratios approaching thresholds 60–90 days before a breach. The operating partner gets the alert with the underlying trajectory; the finance team gets the workspace to model the cure path. - Q: How do you handle data quality issues from a portco that runs its books on Excel? A: Excel portcos are the common case in lower mid-market. The pipeline standardizes the templates, applies validation at ingest, and surfaces data-quality flags when the input drifts. We work with the portco finance team to fix structural issues; we don't pretend that bad data is good data. - Q: Pricing? A: Scoped to portfolio size, source-system complexity, and integration depth. Discovery call covers all three. --- ## Portfolio Pulse Dashboard URL: https://orientedplatforms.com/suites/venture-capital/portfolio-pulse-dashboard Suite: venture-capital Tier: Portfolio + LP Engagement: 8–12 week build · ongoing data ops Buyer: Partners · Portfolio teams · Platform team Problem: Visible.vc and Standard Metrics work — if your portcos consistently upload their monthly data. They never consistently upload. The result is partial visibility, lagging by weeks, with the same partner emails asking for the same updates. Deliverable: A portfolio dashboard built on direct integrations into the systems your portcos already use — Stripe for revenue, Mercury for cash, AWS/GCP billing for technical-spend, GitHub for engineering velocity. Read-only, opt-in per portco, refreshed daily. Related: follow-on-decision-engine, fund-communications-engine , { q: "Which integrations are supported?", a: "At launch: Stripe (revenue and customer count), Mercury (banking and cash position), AWS / GCP / Azure billing (technical spend trajectory), GitHub (commits, PRs, contributor count as engineering proxy). Per-engagement we add the ones the fund's portfolio uses heavily — common adds: Vanta (compliance posture), Linear (product velocity), HubSpot (top-of-funnel).", }, { q: "What about portcos that won't grant API access?", a: "Fall back to the upload-form pattern; the dashboard handles both flows. The point is to make access frictionless for the portcos who'll grant it, not to gate the portfolio view on universal adoption.", }, { q: "What's the partner-side experience?", a: "Cross-portco dashboard — sortable by metric, drillable per portco. Plus an anomaly-detection layer that flags portcos with material deviation from their trajectory (revenue stall, cash runway shortening faster than burn, eng velocity dropping). The partner gets a weekly summary.", }, { q: "Pricing?", a: "Scoped to portfolio size and integration breadth. Discovery call covers both.", }, ], }; ## What this is A portfolio monitoring platform built around the principle that data should come to the fund, not the other way around. Three layers: - **Integration layer.** Read-only OAuth integrations into the systems portcos already use. Each integration is opt-in, scoped, and revocable by the portco. - **Canonical metric layer.** Per-portco data normalized to fund-standard metrics — revenue, gross margin, cash runway, customer count, churn (where computable), engineering velocity. - **Cross-portco surface.** Partner-side dashboard with anomaly detection, drill-down per portco, configurable alerting. ## How it's built OAuth integration adapters per source, Postgres for canonical storage, dbt for the metric normalization layer. Dashboard in Metabase or a custom UI per fund preference. Anomaly detection runs at the canonical metric layer — declarative thresholds for the common patterns (runway shortening, revenue stall), classifier-based detection for the subtler cases. ## What you get - The integration adapters per source — maintained as ongoing data ops. - The canonical metric layer with documented definitions. - The partner dashboard with drill-down and alerting. - Weekly partner summary email. - Per-portco onboarding playbook for the integration-grant conversation. FAQ: - Q: Will portcos actually agree to read-only API access? A: Most early-stage portcos agree — the alternative is them filling out the fund's monthly form, and read-only API access is less work for them. The integration ask is explicit about scope (financials only, no customer PII, no employee data) and reversible (they can revoke any time). Adoption rate in our experience is meaningfully higher than upload-form adoption. - Q: Which integrations are supported? A: At launch: Stripe (revenue and customer count), Mercury (banking and cash position), AWS / GCP / Azure billing (technical spend trajectory), GitHub (commits, PRs, contributor count as engineering proxy). Per-engagement we add the ones the fund's portfolio uses heavily — common adds: Vanta (compliance posture), Linear (product velocity), HubSpot (top-of-funnel). - Q: What about portcos that won't grant API access? A: Fall back to the upload-form pattern; the dashboard handles both flows. The point is to make access frictionless for the portcos who'll grant it, not to gate the portfolio view on universal adoption. - Q: What's the partner-side experience? A: Cross-portco dashboard — sortable by metric, drillable per portco. Plus an anomaly-detection layer that flags portcos with material deviation from their trajectory (revenue stall, cash runway shortening faster than burn, eng velocity dropping). The partner gets a weekly summary. - Q: Pricing? A: Scoped to portfolio size and integration breadth. Discovery call covers both. --- ## Post-Acquisition Integration Tracker URL: https://orientedplatforms.com/suites/private-equity/post-acquisition-integration-tracker Suite: private-equity Tier: Hold Engagement: 6–10 week build · ongoing per integration Buyer: Operating partners · Integration leads Problem: Post-close integration runs across HR, finance, product, and ops — each with its own status reports, each with its own definition of 'on track.' Operating partners discover slippage when board prep starts, three weeks after the slippage was visible in the docs. Deliverable: An NLP and ML layer that reads the recurring integration artifacts — board decks, weekly status reports, ops dashboards, strategy memos — extracts integration-milestone status, predicts timeline slippage, and surfaces missed synergies before board prep makes them visible. Related: portfolio-intelligence-platform, portfolio-forecasting-engine , { q: "How does the slippage prediction actually work?", a: "The model is trained on prior integrations — milestone-status language patterns that preceded slippage versus ones that didn't. 'Slight delay,' 'awaiting input,' 'pushed to next cycle' — these phrases have predictive content. The model surfaces high-risk patterns three to four weeks before they typically materialize as visible slippage.", }, { q: "What's the operating partner's day-to-day experience?", a: "A weekly summary email: which workstreams are on track, which are showing leading indicators of slippage, what synergies look at-risk. The summary links into the source documents so the operating partner can drill in. The point is to make the integration legible without making it heavy.", }, { q: "Can it tell us when a CEO is about to leave?", a: "It can surface the pattern that often precedes it — language shifts in their written updates, meeting cadence changes, document-authorship patterns. It can't predict the conversation that hasn't happened yet, but it can surface signals worth talking to the CEO about. Used responsibly.", }, { q: "Pricing?", a: "Per integration. Discovery call covers the document corpus and the operating-partner cadence.", }, ], }; ## What this is An NLP and ML layer that turns the existing post-close documentation flow into a real-time integration signal. Three layers: - **Document ingestion.** Per-integration document feed — board decks, status memos, ops dashboards, strategy artifacts. Connected to wherever the portco keeps them (SharePoint, Notion, Google Drive, etc.). - **Milestone extraction.** Per-workstream milestone status pulled from natural-language updates. Where the team uses structured trackers, those feed in too; the NLP layer fills the gap where they don't. - **Slippage prediction.** Trained on prior integrations — language patterns that preceded slippage versus ones that didn't. Surfaces high-risk workstreams weeks before they show up as actual delay. ## How it's built Document AI for layout-aware extraction (LayoutLM-class), embedding models for status-language patterns, classification heads trained on labeled prior-integration data. The "trained on prior integrations" piece is shaped per fund — we start with our base model and fine-tune on the fund's historical integrations as that data accumulates. ## What you get - The weekly operating-partner summary, by workstream. - Slippage-prediction alerts with the underlying language pattern that triggered them. - The document corpus indexed and queryable — when the partner asks "what did we last say about pricing strategy?", the answer is one query. - A retrospective dashboard per integration — how predictions tracked against outcomes, so the model's calibration is visible. FAQ: - Q: Why NLP instead of just a project-management tool? A: Project-management tools work when everyone uses them consistently. Post-close, the portco's existing artifacts are the truth — board decks, status memos, ops dashboards — and asking the team to also keep a PM tool current creates a parallel set of records that drift. The NLP layer reads what already exists, which is the truth. - Q: How does the slippage prediction actually work? A: The model is trained on prior integrations — milestone-status language patterns that preceded slippage versus ones that didn't. 'Slight delay,' 'awaiting input,' 'pushed to next cycle' — these phrases have predictive content. The model surfaces high-risk patterns three to four weeks before they typically materialize as visible slippage. - Q: What's the operating partner's day-to-day experience? A: A weekly summary email: which workstreams are on track, which are showing leading indicators of slippage, what synergies look at-risk. The summary links into the source documents so the operating partner can drill in. The point is to make the integration legible without making it heavy. - Q: Can it tell us when a CEO is about to leave? A: It can surface the pattern that often precedes it — language shifts in their written updates, meeting cadence changes, document-authorship patterns. It can't predict the conversation that hasn't happened yet, but it can surface signals worth talking to the CEO about. Used responsibly. - Q: Pricing? A: Per integration. Discovery call covers the document corpus and the operating-partner cadence. --- ## Prediction-Market Alpha Layer URL: https://orientedplatforms.com/suites/hedge-fund/prediction-market-alpha-layer Suite: hedge-fund Tier: Alpha layer Engagement: 6–10 week build · ongoing pred-market data feed Buyer: Macro PMs · Event-driven PMs · Policy-themed funds Problem: Kalshi and Polymarket aggregate informed bettors who care intensely about being right. The implied probabilities on Fed rate decisions, geopolitical outcomes, election results — they move before macro markets do. Most funds aren't wiring those probabilities into their decision stack. Deliverable: A clean feed of prediction-market probabilities mapped to your existing macro and event-driven framework — Fed move probabilities, geopolitical risk markers, election-implied probabilities, joined to the equity sector exposures and macro positions they should influence. Related: alternative-data-signal-engine, cross-lingual-news-filings-intelligence, macro-risk-overlay , { q: "Which markets do you cover?", a: "Kalshi (Fed moves, jobs reports, geopolitical, elections), Polymarket (broader event coverage, less curated, more liquid for some themes), Manifold and PredictIt where signal is clean enough. Source-specific reliability scoring — Kalshi data quality is higher than Polymarket on most macro contracts; the layer reflects that.", }, { q: "Distinction from your Prediction Markets work for platforms themselves?", a: "Different product, different buyer. The platform-side work (pricing, simulation, intelligence tools FOR Kalshi/Polymarket-class operators) is its own engagement. This layer is for hedge funds CONSUMING prediction-market signal. Two distinct buyers, two distinct deliverables — we keep them separate.", }, { q: "What's the latency?", a: "Near-real-time for the major contracts (Kalshi Fed-decision, Polymarket high-volume events). Daily for the thin contracts where intraday noise dominates. Per-contract documented.", }, { q: "Pricing?", a: "Scoped against contract coverage and the latency tier you need. Discovery call covers both.", }, ], }; ## What this is A custom integration layer that takes prediction-market probabilities — Kalshi, Polymarket, select smaller markets — and joins them to the framework your fund already uses to size macro and event-driven positions. Three layers: - **Ingestion.** Per-market data feeds with documented latency. Source-reliability scoring per contract, per market. Backfill of historical contract resolutions for backtests. - **Mapping.** Pred-market contracts → the macro factors, sector exposures, and event probabilities your existing models consume. The mapping layer is the work; the raw prices are commodity. - **Disagreement detection.** Surfaces where pred-market disagrees with the rates curve (for Fed contracts) or equity-implied probability (for event contracts) — the moments where the signal matters. ## How it's built Direct API or websocket integration per market. Polars-based normalization pipeline. Disagreement detection runs on top of your fund's existing rates curve and equity vol surface — pulled via your existing data infrastructure or built into the engagement. ## What you get - Per-contract live and historical data, normalized. - The mapping from contract universe to your fund's macro factor framework. - Disagreement alerts when pred-market diverges from other implied-probability series. - Backfill for backtest validation. - Documented per-contract reliability so PMs know when to trust the series. FAQ: - Q: Aren't prediction-market prices already public? A: The prices are. The work is mapping them onto your decision framework — converting the implied probabilities into the macro factors and equity exposures your PMs already trade on, joining the prediction-market series against your existing macro data, and surfacing the moments where pred-market disagrees with the rates curve or the equity-implied probability. - Q: Which markets do you cover? A: Kalshi (Fed moves, jobs reports, geopolitical, elections), Polymarket (broader event coverage, less curated, more liquid for some themes), Manifold and PredictIt where signal is clean enough. Source-specific reliability scoring — Kalshi data quality is higher than Polymarket on most macro contracts; the layer reflects that. - Q: Distinction from your Prediction Markets work for platforms themselves? A: Different product, different buyer. The platform-side work (pricing, simulation, intelligence tools FOR Kalshi/Polymarket-class operators) is its own engagement. This layer is for hedge funds CONSUMING prediction-market signal. Two distinct buyers, two distinct deliverables — we keep them separate. - Q: What's the latency? A: Near-real-time for the major contracts (Kalshi Fed-decision, Polymarket high-volume events). Daily for the thin contracts where intraday noise dominates. Per-contract documented. - Q: Pricing? A: Scoped against contract coverage and the latency tier you need. Discovery call covers both. --- ## Pricing & Margin Optimizer URL: https://orientedplatforms.com/suites/private-equity/pricing-margin-optimizer Suite: private-equity Tier: Hold Engagement: 8–14 week build per portco · ongoing iteration Buyer: Operating partners · Portco commercial leads · CROs Problem: Pricing decisions at portcos are made on instinct and unit economics that haven't been updated since acquisition. The price-elasticity is unknown, the segment-level margin profile is fuzzy, and the levers that would move the next print are hidden in customer data nobody has time to analyze. Deliverable: An ML layer on the portco's product, customer, and channel data — estimates price-elasticity per segment, identifies the margin levers worth pulling, simulates the impact of pricing and packaging changes before they ship. Related: portfolio-intelligence-platform, portfolio-forecasting-engine , { q: "What data does the model need?", a: "Transaction-level history (customer, product, date, price, quantity, channel), customer-segment metadata, competitive pricing data where the portco has access, and ideally one or two prior pricing changes to anchor the elasticity estimate. Where the portco has thin data, we use industry-comparable elasticity priors with documented uncertainty.", }, { q: "How do you handle B2B portcos where each customer is negotiated?", a: "Negotiated B2B is the harder case — list price doesn't matter, what matters is the discount distribution. The model adapts to estimate discount-elasticity by segment and surface the customers where the discount is leaving margin on the table. Same structure, different lever.", }, { q: "What's the typical EBITDA impact?", a: "Honestly varies wildly — 50bps to 400bps depending on how much the portco was leaving on the table. The early engagements always find more upside than expected; the later ones find optimization. We scope to a concrete pricing-experiment-and-measurement plan rather than promise a multiplier.", }, { q: "Pricing?", a: "Per portco, scoped to data complexity and the breadth of the pricing program. Discovery call covers both.", }, ], }; ## What this is A pricing intelligence engagement for hold-period portcos where price and margin are the next-quarter-print lever. Three deliverables: - **Elasticity model.** Per-segment price-elasticity (or discount-elasticity, for negotiated B2B), trained on the portco's transaction history. Output: "raise price on segment X by Y%, expect Z% volume impact," with uncertainty bands. - **Margin-lever map.** The set of pricing and packaging changes that would move EBITDA, ranked by expected impact and risk. Surfaces the obvious-in-hindsight ones (segment-level under-pricing, sub-scale discounts) that don't show up in the existing reports. - **Simulation environment.** Before-and-after scenario modeling for each proposed change. The operating partner sees the modeled impact before the change ships, with documented assumptions. ## How it's built Bayesian elasticity modeling (PyMC) for the small-sample / strong-prior cases; LightGBM with monotonic constraints where the data is rich enough to learn non-linear patterns. Integration with the portco's billing or CRM system for execution; or, more commonly, a recommendation document the portco's commercial team executes. ## What you get - The elasticity model and the margin-lever map. - The simulation environment, configured to the portco's pricing structure. - A working session with the portco commercial team to prioritize and sequence changes. - Ongoing iteration as pricing changes ship — the model re-calibrates on the new data. FAQ: - Q: Most price-elasticity work is academic and doesn't deploy. How is this different? A: Two ways. First, the model output is an action-oriented recommendation — 'raise price on segment X by Y%, expect Z% volume impact' — not a regression coefficient. Second, we wire the recommendation through to a deployable change, so the operating partner can see the impact instead of asking the portco team to interpret an academic output. - Q: What data does the model need? A: Transaction-level history (customer, product, date, price, quantity, channel), customer-segment metadata, competitive pricing data where the portco has access, and ideally one or two prior pricing changes to anchor the elasticity estimate. Where the portco has thin data, we use industry-comparable elasticity priors with documented uncertainty. - Q: How do you handle B2B portcos where each customer is negotiated? A: Negotiated B2B is the harder case — list price doesn't matter, what matters is the discount distribution. The model adapts to estimate discount-elasticity by segment and surface the customers where the discount is leaving margin on the table. Same structure, different lever. - Q: What's the typical EBITDA impact? A: Honestly varies wildly — 50bps to 400bps depending on how much the portco was leaving on the table. The early engagements always find more upside than expected; the later ones find optimization. We scope to a concrete pricing-experiment-and-measurement plan rather than promise a multiplier. - Q: Pricing? A: Per portco, scoped to data complexity and the breadth of the pricing program. Discovery call covers both. --- ## Process Automation Agents URL: https://orientedplatforms.com/suites/ai-implementation/process-automation-agents Suite: ai-implementation Tier: Workflow & operations automation Engagement: 8–14 week build · ongoing operation Buyer: COOs · Operations directors · CIOs Problem: Cross-functional processes — onboarding a new customer that touches sales, finance, support, and product; processing a vendor change that hits procurement, finance, legal, and operations; running a quarterly close that coordinates across teams — fall through the gaps in single-function tools and exceed Zapier-class linear automation. Deliverable: A multi-step agent orchestration layer — workflows expressed as agent-coordinated processes, integrated with the business's existing systems, with human-in-loop checkpoints where the workflow needs them. Related: document-intelligence-engine, customer-support-ai, finance-operations-ai , { q: "What does 'agent' actually mean in practice?", a: "A workflow component that maintains state, makes context-dependent decisions, and orchestrates calls to other systems and other agents. Concretely: LLM-driven decision logic plus deterministic action execution plus state persistence. The 'agents' aren't autonomous in the alarming-sense; they're scoped to defined workflows with explicit boundaries.", }, { q: "What about reliability and observability?", a: "Every agent step logged with structure. Every decision point auditable. Every external action tracked with success/failure. Failure modes recover gracefully (idempotent retries) or escalate to humans. Production observability is a first-class requirement, not an afterthought.", }, { q: "How do you handle the 'agent goes rogue' concern?", a: "Scoped permissions, audit logs, human-in-loop checkpoints at the steps the business cares about. The agents aren't running arbitrary code; they're executing within a defined workflow with explicit guardrails. The architecture is the safety, not vibes.", }, { q: "Pricing?", a: "Scoped to workflow complexity. Discovery call covers scope.", }, ], }; ## What this is A workflow-orchestration engagement for cross-functional processes. Three layers: - **Workflow definition.** Per-process workflow expressed as a multi-step coordination — which agents do what, in what order, with what decision logic at branching points, with what human-in-loop checkpoints. - **System integration.** Connectors into the business's existing systems (CRM, ERP, support, finance, custom). The workflow orchestrates across them; the systems-of-record stay as systems-of-record. - **Observability and recovery.** Structured logging, audit trail, idempotent retries, escalation paths. Production-grade across the workflow surface. ## How it's built LLM layer (Claude-class, GPT-class, on-prem where required) for the decision logic. State management in Postgres or a workflow engine (Temporal-class for the complex cases). Integration adapters per system. Observability stack (OpenTelemetry-class). ## What you get - The workflow definitions for the processes you've prioritized. - The agent orchestration layer. - System integration with your existing software stack. - Observability and audit infrastructure. - Documentation and runbooks for the ops team handing off the workflows. FAQ: - Q: Why agents instead of just better Zapier? A: Linear automation (Zapier, n8n, Make) handles trigger-action chains well. For cross-functional processes with branching logic, error recovery, multi-step coordination across heterogeneous systems, and contextual decision-making, agent-orchestrated workflows handle structure the linear tools miss. We use Zapier-class tools where they fit; we build agent workflows where they don't. - Q: What does 'agent' actually mean in practice? A: A workflow component that maintains state, makes context-dependent decisions, and orchestrates calls to other systems and other agents. Concretely: LLM-driven decision logic plus deterministic action execution plus state persistence. The 'agents' aren't autonomous in the alarming-sense; they're scoped to defined workflows with explicit boundaries. - Q: What about reliability and observability? A: Every agent step logged with structure. Every decision point auditable. Every external action tracked with success/failure. Failure modes recover gracefully (idempotent retries) or escalate to humans. Production observability is a first-class requirement, not an afterthought. - Q: How do you handle the 'agent goes rogue' concern? A: Scoped permissions, audit logs, human-in-loop checkpoints at the steps the business cares about. The agents aren't running arbitrary code; they're executing within a defined workflow with explicit guardrails. The architecture is the safety, not vibes. - Q: Pricing? A: Scoped to workflow complexity. Discovery call covers scope. --- ## Production & Resource Planner URL: https://orientedplatforms.com/suites/operations-algorithms/production-resource-planner Suite: operations-algorithms Tier: Operations research Engagement: 10–16 week build · ongoing operation Buyer: Production directors · Supply chain leads · Plant managers Problem: Production decisions at most manufacturers — what to produce, in what quantities, against what input mix, allocated to which downstream demand — are made through ERP-driven heuristics plus production-manager judgment. The result is workable but rarely optimal against the actual constraint set. Deliverable: A linear-programming model for the business's production-planning problem — what to make, how much, in what mix, allocated to which demand. Run weekly or per planning cycle, with documented improvement vs. the prior method. Related: logistics-routing-optimizer, workforce-scheduling-engine, demand-forecasting-inventory-engine , { q: "What kinds of problems do you model?", a: "Production planning (what to make, when), blending (what input mix for what output mix), multi-echelon supply allocation (from production to distribution centers to channels), recipe-and-substitution optimization (where input substitution is allowed within quality bounds). Per-engagement, the problem formulation matches the business's actual decision structure.", }, { q: "How does it handle uncertainty in demand and input cost?", a: "Two paths. For modest uncertainty, scenario-based LP (run the LP under representative scenarios, evaluate solution stability). For larger uncertainty, stochastic programming or robust optimization where the engagement scopes the methodology. We're upfront when the problem fits each approach.", }, { q: "What's the typical impact?", a: "Per-engagement varies. Margin uplift from input-mix optimization is typically in the 2–8% range; production-throughput gains from better sequencing typically 5–15%. The engagement scopes baseline measurement so the impact is documented, not asserted.", }, { q: "Pricing?", a: "Scoped to problem complexity and integration depth. Discovery call covers both.", }, ], }; ## What this is A production-planning engagement for manufacturers where the planning decisions are constraint-optimization problems. Three layers: - **Problem formulation.** The production decision expressed as a linear program with the business's constraints (input availability, production capacity, recipe rules, downstream demand commitments, quality bounds). - **Solver.** Gurobi, CPLEX, or open-source equivalents depending on license and scale. Hybrid heuristic-plus-exact methods for the larger instances. - **Operational integration.** Per-planning-cycle execution, planner UI for review and scenario exploration, integration with the business's ERP for execution. ## How it's built Python optimization stack (pyomo or pulp for the formulation layer, Gurobi or CBC for the solver). Per-engagement, the formulation captures the business's actual constraint structure rather than fitting the problem to a generic template. ## What you get - The formulated LP model with documented constraints. - The solver deployment. - Per-cycle planning pipeline. - Planner UI for review and what-if analysis. - Baseline-and-improvement documentation. FAQ: - Q: Why LP instead of an APS (Advanced Planning Solution) like SAP IBP? A: Enterprise APS is excellent for businesses that fit its data model. For mid-market manufacturers and for enterprises with non-standard constraints (custom blending formulas, multi-recipe production lines, recipe-cost-and-availability tradeoffs), custom LP captures the constraint set faithfully. Many engagements end up running alongside the business's existing APS, not replacing it. - Q: What kinds of problems do you model? A: Production planning (what to make, when), blending (what input mix for what output mix), multi-echelon supply allocation (from production to distribution centers to channels), recipe-and-substitution optimization (where input substitution is allowed within quality bounds). Per-engagement, the problem formulation matches the business's actual decision structure. - Q: How does it handle uncertainty in demand and input cost? A: Two paths. For modest uncertainty, scenario-based LP (run the LP under representative scenarios, evaluate solution stability). For larger uncertainty, stochastic programming or robust optimization where the engagement scopes the methodology. We're upfront when the problem fits each approach. - Q: What's the typical impact? A: Per-engagement varies. Margin uplift from input-mix optimization is typically in the 2–8% range; production-throughput gains from better sequencing typically 5–15%. The engagement scopes baseline measurement so the impact is documented, not asserted. - Q: Pricing? A: Scoped to problem complexity and integration depth. Discovery call covers both. --- ## Property Valuation Engine URL: https://orientedplatforms.com/suites/real-estate/property-valuation-engine Suite: real-estate Tier: For RE investment teams Engagement: 8–14 week build · ongoing model refresh Buyer: Investment teams · REIT acquisitions · Underwriters · Brokers Problem: Underwriting at scale requires consistent valuations across a pipeline of dozens of properties — but the comparable-sales analysis, the rent-roll modeling, the cap-rate sensitivity scenarios all happen on a per-property basis in spreadsheets, the analyst time scales linearly with deal flow. Deliverable: An automated valuation model that ingests comparable sales, rents, macro-data, and property features — produces instant valuations with documented uncertainty, plus sensitivity scenarios (cap-rate moves, rent growth assumptions, expense trajectory) the deal team uses for underwriting. Related: site-selection-intelligence , { q: "What's the modeling stack?", a: "Ensemble of LightGBM, XGBoost, and a geographically-weighted regression (GWR) layer for spatial correction — the same stack OpenAVMKit uses on the assessor side, applied to investor-side workflows. Where the portfolio has specific property types (multifamily, industrial, mixed-use) we tune the ensemble per type rather than running one general model.", }, { q: "Does it handle commercial as well as residential?", a: "Yes — multifamily, single-tenant industrial, retail, mixed-use. Office is supported but model quality varies with how distressed and re-pricing-heavy the local market is; we document the per-market uncertainty explicitly.", }, { q: "How are the sensitivity scenarios structured?", a: "Per-deal, the deal team configures the scenarios that matter — typically cap-rate moves of +/- 50–150 bps, rent growth ranges from -2% to +6% per year, expense trajectory variations. The engine produces the valuation surface across all combinations; the deal team focuses on the cells that matter for their underwriting bar.", }, { q: "Pricing?", a: "Scoped to portfolio scope, property-type breadth, and model-refresh cadence. Discovery call covers all three.", }, ], }; ## What this is A valuation platform for deal teams running real underwriting volume. Three layers: - **Data ingestion.** Comparable sales (MLS, public records, syndicated commercial feeds), rent rolls and rent comparables, macro-data (Treasury rates, regional employment, CPI), per-property features (square footage, unit count, age, amenity scoring). - **Modeling.** Ensemble valuation model (LightGBM + XGBoost + GWR) tuned per property type. Per-market calibration. Documented uncertainty per estimate. - **Scenario layer.** Sensitivity analysis across configurable axes — cap-rate, rent growth, expense trajectory, exit assumptions. Surface visualization for the deal team. ## How it's built Modeling stack as referenced (LightGBM, XGBoost, GWR via PySAL). Postgres or Snowflake for canonical storage. Per-market calibration runs quarterly; per-property-type ensembles tune on engagement and on retrain. PDF report generation for broker- and investor-facing valuations where the workflow needs them. ## What you get - The ensemble model, calibrated to your portfolio's markets and property types. - The sensitivity-scenario engine. - PDF report generation for outbound deliverables. - Per-market uncertainty documentation. - Quarterly model refresh. FAQ: - Q: How is this different from HouseCanary, Reonomy, Quantarium? A: The single-point AVM is a commodity at this point. What's not commodity is the sensitivity layer — the deal team rarely cares about the point estimate alone; they care about valuation under different cap-rate, growth, and expense scenarios. The engine produces the full scenario surface, not just the point. Plus the model is custom-trained against your portfolio's geographies and property types, not a one-size-fits-all national model. - Q: What's the modeling stack? A: Ensemble of LightGBM, XGBoost, and a geographically-weighted regression (GWR) layer for spatial correction — the same stack OpenAVMKit uses on the assessor side, applied to investor-side workflows. Where the portfolio has specific property types (multifamily, industrial, mixed-use) we tune the ensemble per type rather than running one general model. - Q: Does it handle commercial as well as residential? A: Yes — multifamily, single-tenant industrial, retail, mixed-use. Office is supported but model quality varies with how distressed and re-pricing-heavy the local market is; we document the per-market uncertainty explicitly. - Q: How are the sensitivity scenarios structured? A: Per-deal, the deal team configures the scenarios that matter — typically cap-rate moves of +/- 50–150 bps, rent growth ranges from -2% to +6% per year, expense trajectory variations. The engine produces the valuation surface across all combinations; the deal team focuses on the cells that matter for their underwriting bar. - Q: Pricing? A: Scoped to portfolio scope, property-type breadth, and model-refresh cadence. Discovery call covers all three. --- ## Real-Time Personalization API URL: https://orientedplatforms.com/suites/operations-algorithms/real-time-personalization-api Suite: operations-algorithms Tier: Customer intelligence Engagement: 8–12 week build · ongoing model maintenance Buyer: Heads of growth · Product leads · Engineering teams Problem: Web and app surfaces recommend the same items to everyone or worse, items chosen by manual merchandising. The data exists to do better — purchase history, browsing patterns, contextual signal — but the recommendation system that ties them together hasn't been built. Deliverable: An API that returns the next-best-product, next-best-content, or next-best-offer per user — fed by the client's own behavior data, augmented (with consent) by Subscription Economy Benchmarks contextual signal where the use case warrants. Related: customer-clustering-ltv-engine, subscription-economy-benchmarks-api , { q: "What's the modeling stack?", a: "Neural collaborative filtering as the baseline, gradient-boosted reranking for the final candidate list, contextual bandit for the exploration-exploitation tradeoff in production. Per-engagement, the stack adapts to the latency and scale requirements.", }, { q: "How do you handle cold-start users?", a: "Cold-start uses the segment-level model from Customer Clustering & LTV Engine if it's deployed, otherwise falls back to a popularity-with-stratification baseline. Where the SubMagician signal is permitted, cold-start cases get a meaningful uplift from the subscription-footprint context.", }, { q: "What's the latency commitment?", a: "Sub-100ms p99 at typical scale (single-digit-million users, single-digit-thousand RPS). At higher scale or for sub-50ms requirements, the engagement scopes the architectural changes required.", }, { q: "Pricing?", a: "Scoped to traffic, model complexity, and integration depth. Discovery call covers all three.", }, ], }; ## What this is A personalization API engagement for businesses that want recommendations to actually move the metric. Three layers: - **Behavioral signal ingestion.** Per-user click, purchase, dwell, return — fed into the recommendation backbone. - **Recommendation modeling.** Neural collaborative filtering as backbone, gradient-boosted reranker for the final candidate list, contextual bandit for production exploration. - **API serving.** Low-latency serve infrastructure with the API contract documented for the client's engineering team. ## How it's built PyTorch for the neural backbone, LightGBM for the reranker, contextual-bandit infrastructure (LinUCB or Thompson-class). Online serving via FastAPI with a Redis-class feature store. Subscription Economy Benchmarks integration where permitted — the integration is explicit and consented per engagement. ## What you get - The recommendation model trained on the client's data. - The API contract and serving infrastructure. - Documentation of the SubMagician integration (if used) including consent boundary. - A/B test infrastructure for measuring lift. - Quarterly model refresh and online-bandit monitoring. FAQ: - Q: How does the SubMagician data integration work? A: Per-engagement, with explicit consent in scope. SubMagician users have consented to anonymized aggregate use of their subscription-pattern data; that aggregate becomes a contextual signal layer for the personalization model. For client engagements where this is permitted, the model sees not just 'this user clicked X' but 'users with this subscription footprint typically next-engage with Y.' Where the client's compliance posture excludes external data, the model uses client-data only. - Q: What's the modeling stack? A: Neural collaborative filtering as the baseline, gradient-boosted reranking for the final candidate list, contextual bandit for the exploration-exploitation tradeoff in production. Per-engagement, the stack adapts to the latency and scale requirements. - Q: How do you handle cold-start users? A: Cold-start uses the segment-level model from Customer Clustering & LTV Engine if it's deployed, otherwise falls back to a popularity-with-stratification baseline. Where the SubMagician signal is permitted, cold-start cases get a meaningful uplift from the subscription-footprint context. - Q: What's the latency commitment? A: Sub-100ms p99 at typical scale (single-digit-million users, single-digit-thousand RPS). At higher scale or for sub-50ms requirements, the engagement scopes the architectural changes required. - Q: Pricing? A: Scoped to traffic, model complexity, and integration depth. Discovery call covers all three. --- ## Repeat-Purchase & Churn for Shopify URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/repeat-purchase-churn-shopify Suite: shopify-ops-intelligence Tier: Storefront & customer intelligence Engagement: 6–10 week deployment · self-serve to custom packaging Buyer: DTC operators · Subscription-product brands · Retention teams Problem: DTC repeat-purchase patterns are tracked but rarely predicted — the store knows the aggregate repeat-rate but doesn't know which customers are about to lapse or which subscribers are heading for churn. Deliverable: A Shopify-tuned deployment of the canonical Churn Prediction & Retention Engine — handles both transactional repeat-purchase prediction and subscription-aware churn (Recharge / Bold / Shopify Subscriptions integration), wires reactivation triggers into Klaviyo flows. Related: churn-prediction-retention-engine, customer-clustering-shopify , { q: "What about Shopify Subscriptions (the native one)?", a: "Supported. The data shape is similar to Recharge though some signal nuances differ. The model adapts.", }, { q: "What's the retention-action integration?", a: "Predicted-risk customers feed into Klaviyo segments (or Shopify Audiences) where the retention team has flows configured. The engine doesn't replace the marketing-flow infrastructure — it informs it with risk signal.", }, { q: "How is this different from the OAS canonical?", a: "Same modeling backbone, Shopify-and-subscription-app data integration on top. Cross-link to the canonical for the modeling detail.", }, { q: "Pricing?", a: "Tiered per buyer profile. Discovery call covers the right tier.", }, ], }; ## What this is The canonical Churn Prediction & Retention Engine, tuned for Shopify's repeat-purchase and subscription patterns. See the [canonical product page in the Operations Algorithms Suite](/suites/operations-algorithms/churn-prediction-retention-engine) for the modeling backbone, risk-driver attribution, and retention-action library. The Shopify-tuned tuning consists of: - Recharge / Bold / Shopify Subscriptions integration for subscription-aware churn modeling. - Shopify Customer and Orders APIs for the transactional repeat-purchase signal. - Klaviyo segment sync for retention-flow integration. - Shopify Audiences sync for marketing-campaign targeting. ## What you get - The churn model trained on your store's data. - Subscription-aware predictions for stores running subscription apps. - Klaviyo and Shopify Audiences sync. - Risk-driver attribution per predicted customer. - Quarterly model refresh. FAQ: - Q: How does it handle Recharge subscriptions? A: Recharge integration is canonical — subscription events (initial, renewal, skip, cancel) feed into the model as labeled signal. The churn prediction differentiates 'about to skip cycle' from 'about to cancel,' which require different retention actions. - Q: What about Shopify Subscriptions (the native one)? A: Supported. The data shape is similar to Recharge though some signal nuances differ. The model adapts. - Q: What's the retention-action integration? A: Predicted-risk customers feed into Klaviyo segments (or Shopify Audiences) where the retention team has flows configured. The engine doesn't replace the marketing-flow infrastructure — it informs it with risk signal. - Q: How is this different from the OAS canonical? A: Same modeling backbone, Shopify-and-subscription-app data integration on top. Cross-link to the canonical for the modeling detail. - Q: Pricing? A: Tiered per buyer profile. Discovery call covers the right tier. --- ## Sales & Marketing Operations AI URL: https://orientedplatforms.com/suites/ai-implementation/sales-marketing-operations-ai Suite: ai-implementation Tier: Workflow & operations automation Engagement: 8–12 week build · ongoing operation Buyer: CROs · CMOs · RevOps leads · Heads of growth Problem: Sales and marketing operations accumulate routine work — lead scoring done by hand or by rule-based scoring that doesn't capture nuance, CRM data hygiene that nobody owns, outbound sequences manually maintained, attribution analysis done quarterly when it should be weekly. Deliverable: An AI layer across the RevOps stack — predictive lead scoring, CRM data hygiene, outbound drafting and sequence-optimization, attribution analysis. Sits on top of the existing CRM and marketing automation. Related: customer-clustering-ltv-engine, churn-prediction-retention-engine , { q: "What about lead scoring specifically?", a: "Replaces rule-based scoring with a model trained on the business's actual conversion data. The score includes attribution to why it's high or low — fit factors, intent factors, timing factors — so the sales team knows what to do with the lead, not just whether it's good.", }, { q: "Does it auto-send outbound emails?", a: "Drafts, doesn't auto-send. The sales team reviews before sending. Where the business wants higher automation (mass-outbound on a low-touch product), the engagement can scope auto-send with controls — but the default is human-in-loop.", }, { q: "What does the CRM hygiene layer do?", a: "Deduplication, missing-field completion (where the missing data is inferrable from other sources), data-quality flagging for the records that need human attention. The CRM stays cleaner without weekly maintenance projects.", }, { q: "Pricing?", a: "Scoped to CRM size, lead volume, and integration depth. Discovery call covers all three.", }, ], }; ## What this is An AI layer for the sales and marketing operations stack. Four components: - **Predictive lead scoring.** Trained on the business's conversion data. Outputs score plus attribution to score drivers. - **CRM data hygiene.** Deduplication, missing-field inference, data-quality flagging. - **Outbound drafting.** Sequence-step generation, personalization, A/B suggestion. Always human-reviewed before sending. - **Attribution analysis.** Multi-touch attribution across the customer journey, with weekly cadence. ## How it's built LightGBM with calibration for lead scoring (calibrated probabilities the sales team can act on). Embedding-based deduplication for the CRM hygiene layer. LLM layer for outbound drafting. Attribution modeling via Bayesian or Markov-chain methods depending on data structure. ## What you get - The lead-scoring model integrated with your CRM. - The CRM-hygiene pipeline running ongoing. - The outbound-drafting layer with review workflow. - The attribution-analysis dashboard. - Quarterly model refresh and attribution review. FAQ: - Q: How is this different from HubSpot's AI features or Salesforce Einstein? A: Those are excellent at the common case — typical SaaS funnel, typical B2B sales motion. For businesses with more complex sales motions (multi-stakeholder enterprise, mixed B2B/B2C, channel-mediated), the built-in features underperform. Custom captures the structure the built-ins miss. - Q: What about lead scoring specifically? A: Replaces rule-based scoring with a model trained on the business's actual conversion data. The score includes attribution to why it's high or low — fit factors, intent factors, timing factors — so the sales team knows what to do with the lead, not just whether it's good. - Q: Does it auto-send outbound emails? A: Drafts, doesn't auto-send. The sales team reviews before sending. Where the business wants higher automation (mass-outbound on a low-touch product), the engagement can scope auto-send with controls — but the default is human-in-loop. - Q: What does the CRM hygiene layer do? A: Deduplication, missing-field completion (where the missing data is inferrable from other sources), data-quality flagging for the records that need human attention. The CRM stays cleaner without weekly maintenance projects. - Q: Pricing? A: Scoped to CRM size, lead volume, and integration depth. Discovery call covers all three. --- ## Sector Mapping Engine URL: https://orientedplatforms.com/suites/venture-capital/sector-mapping-engine Suite: venture-capital Tier: Deal pipeline Engagement: 6–8 week build · ongoing per-sector refresh Buyer: Associates · Principals · Sector partners Problem: Associates spend days building sector maps by hand — landscape diagrams in Figma, competitive matrices in Notion, hiring-and-funding trackers in spreadsheets. By the time the partner reviews, half the data is stale. Deliverable: An auto-updating sector mapping platform — landscape diagrams with company-activity signals (funding, hiring, product launches, supplier-customer mention graphs) refreshing daily, navigable from sector down to individual company. Related: founder-network-intelligence, deal-sourcing-signal-platform, startup-evaluation-engine , { q: "Which sectors do you cover?", a: "Per-engagement — we scope to the two-to-five sectors the fund actually invests in. Building a useful map for one sector takes time; building maps for fifteen sectors none of which are deeply useful is the failure mode we avoid.", }, { q: "What signals feed the map?", a: "Funding events (rounds, valuations, lead investors), hiring patterns (executive joins, technical-talent inflows), product launches and feature ships, partnership and customer announcements, exec departures. Per-sector, the signal weighting differs.", }, { q: "Can it tell us which companies are about to raise?", a: "It surfaces the leading indicators that often precede a round — hiring acceleration, new exec hires, key partnership announcements. It can't predict the conversation that hasn't happened yet, but it surfaces signals that move the partner-to-founder outreach forward by weeks.", }, { q: "Pricing?", a: "Scoped against sector count and refresh cadence. Discovery call covers both.", }, ], }; ## What this is The associate's leverage layer for sector research. Three components: - **Landscape construction.** Per-sector taxonomy — categories, sub-categories, the way the fund's partners think about the space. The taxonomy lives in code so it evolves with the partners' thinking. - **Signal ingestion.** Funding, hiring, product, partnership, exec-departure signals attached to companies. Per-sector signal weighting. - **Map rendering.** Visual landscape with companies positioned by sub-category and stage, sized by signal-velocity, color-graded by recency. Export-able to Figma for partner decks. ## How it's built Same data infrastructure that powers the Deal-Sourcing & Signal Platform — the work is the per-sector taxonomy and the signal weighting, not the raw ingestion. Map rendering in D3 or Visx for the web view, a separate exporter for Figma format. ## What you get - Per-sector taxonomy and map. - Auto-refresh against the underlying signal data. - Figma export for partner meetings. - Signal-history per company so the associate can show "this company has been heating up for three months." - Ongoing per-sector refresh as the fund adds coverage. FAQ: - Q: We build sector maps in Figma. Why not keep doing that? A: Figma maps look great in a partner meeting and go stale the next week. The Sector Mapping Engine produces the same visual but keeps the underlying data current — the partner deck always renders against fresh data. The visual layer can still export to Figma for the moments where polish matters. - Q: Which sectors do you cover? A: Per-engagement — we scope to the two-to-five sectors the fund actually invests in. Building a useful map for one sector takes time; building maps for fifteen sectors none of which are deeply useful is the failure mode we avoid. - Q: What signals feed the map? A: Funding events (rounds, valuations, lead investors), hiring patterns (executive joins, technical-talent inflows), product launches and feature ships, partnership and customer announcements, exec departures. Per-sector, the signal weighting differs. - Q: Can it tell us which companies are about to raise? A: It surfaces the leading indicators that often precede a round — hiring acceleration, new exec hires, key partnership announcements. It can't predict the conversation that hasn't happened yet, but it surfaces signals that move the partner-to-founder outreach forward by weeks. - Q: Pricing? A: Scoped against sector count and refresh cadence. Discovery call covers both. --- ## Shopify Operations Audit URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/shopify-operations-audit Suite: shopify-ops-intelligence Tier: Shopify-native operations Engagement: 2–4 week sprint · packaged report and recommendations Buyer: DTC founders · Shopify store owners · COOs Problem: Established Shopify stores accumulate operational debt — apps installed and partially deployed, workflows that should be optimized, data infrastructure that's outgrown its initial shape. The store owner senses the inefficiency but doesn't have time to assess and prioritize. Deliverable: A 2-4 week audit of the store's operations stack — current app inventory and gap analysis, workflow-optimization opportunities, data-infrastructure assessment, prioritized recommendations with effort-and-impact scoring. Packaged as an action plan the operator's team executes (or that we execute via the other Shopify Suite products). Related: shopify-operations-workflow-automation, multi-store-portfolio-intelligence , { q: "What do you actually look at during the audit?", a: "Current app stack (what's installed, what's actually used, what's redundant). Workflow inventory (manual processes, Flow workflows, custom integrations). Data infrastructure (what's tracked, what's analyzed, what's missing). Customer data quality. Inventory accuracy and forecasting maturity. Marketing-attribution infrastructure. Multi-store coordination if relevant.", }, { q: "What does the deliverable look like?", a: "A document for the operator (5-10 pages, partner-readable) summarizing findings, plus a prioritized recommendation list (typically 10-20 items, each scored on effort and expected impact). Plus a working session with the operator to walk through the document.", }, { q: "How do you compare to general Shopify consultants doing the same audit?", a: "Consultants do this work well; the productized engagement differs in shape. Fixed scope, fixed fee, the same audit checklist applied across deployments so we improve the audit faster than per-engagement learning would. Tradeoff: we don't customize the audit to your store's unique context the way a long-engagement consultant would.", }, { q: "Pricing?", a: "Fixed-fee per audit, scoped to store size and complexity. Discovery call covers scope.", }, ], }; ## What this is A productized consulting engagement — fixed-fee, fixed-scope, fixed-deliverable. The entry product for operators who want a clear assessment before committing to deeper work. Three components: - **Discovery sprint.** App-stack inventory, workflow audit, data-infrastructure review. Working with the operator's team. - **Analysis.** Prioritized findings with effort-and-impact scoring per recommendation. Bottlenecks identified, redundancies surfaced, opportunities ranked. - **Recommendation document.** Partner-readable summary, prioritized action plan, working session to walk through and Q&A. ## How it's built The audit checklist itself is the product. We maintain it across engagements — each new audit refines the checklist, every operator benefits from the previous operators' audit findings being incorporated into the methodology. ## What you get - The audit document. - The prioritized recommendation list with scoring. - The working session to walk through with your team. - Optional: hand-off to one of the other Shopify Suite products if the operator wants us to execute downstream. FAQ: - Q: Is this just a sales pitch for the other products? A: The audit is fixed-fee and standalone. The recommendation document is yours to execute however you want — internally, with another vendor, or with us. We're explicit on the engagement that the audit is the engagement; downstream work is optional. - Q: What do you actually look at during the audit? A: Current app stack (what's installed, what's actually used, what's redundant). Workflow inventory (manual processes, Flow workflows, custom integrations). Data infrastructure (what's tracked, what's analyzed, what's missing). Customer data quality. Inventory accuracy and forecasting maturity. Marketing-attribution infrastructure. Multi-store coordination if relevant. - Q: What does the deliverable look like? A: A document for the operator (5-10 pages, partner-readable) summarizing findings, plus a prioritized recommendation list (typically 10-20 items, each scored on effort and expected impact). Plus a working session with the operator to walk through the document. - Q: How do you compare to general Shopify consultants doing the same audit? A: Consultants do this work well; the productized engagement differs in shape. Fixed scope, fixed fee, the same audit checklist applied across deployments so we improve the audit faster than per-engagement learning would. Tradeoff: we don't customize the audit to your store's unique context the way a long-engagement consultant would. - Q: Pricing? A: Fixed-fee per audit, scoped to store size and complexity. Discovery call covers scope. --- ## Shopify Operations Workflow Automation URL: https://orientedplatforms.com/suites/shopify-ops-intelligence/shopify-operations-workflow-automation Suite: shopify-ops-intelligence Tier: Shopify-native operations Engagement: 6–10 week build · ongoing operation Buyer: Shopify operators · DTC ops leads · Fulfillment teams Problem: Shopify operators run a stack of point apps for cart recovery, fulfillment routing, refund workflows, and inventory rebalancing — each app handles its own piece, none of them see the bigger operational picture. Deliverable: An integrated operations-workflow layer — Shopify Flow for the standard triggers, custom orchestration where Flow's limits run out, and the cross-workflow coordination that the point-app stack misses. Related: multi-store-portfolio-intelligence, shopify-operations-audit , { q: "What does 'custom orchestration where Flow runs out' actually mean?", a: "Concrete examples. Cart recovery that's customer-segment-aware (different timing and offer for cluster A vs. cluster B). Fulfillment routing that considers carrier rates, customer location, and inventory position across multiple warehouses simultaneously. Return-fraud detection on serial returners with custom business rules. Multi-store inventory rebalancing for portfolio operators.", }, { q: "How does this fit with our existing app stack?", a: "It composes rather than replaces. Where existing apps work, we keep them. Where the apps create gaps or duplicated workflows, we replace selectively. The audit phase identifies what to keep and what to consolidate.", }, { q: "What's the typical operations-cost impact?", a: "Per-engagement varies. Common findings: 15–35% reduction in operations-staff time on routine workflows, 5–15% reduction in cart-abandonment loss, 2–8% reduction in fulfillment-cost-per-order. The engagement scopes baseline measurement.", }, { q: "Pricing?", a: "Scoped to workflow complexity. Discovery call covers the audit scope.", }, ], }; ## What this is A workflow-automation engagement for Shopify operators where the operations layer is the lever. Three components: - **Audit.** Map of current workflows (Shopify Flow, installed apps, manual processes), with friction-and-gap identification. - **Build.** Custom workflows where the stack has gaps. Native Shopify Flow where Flow is sufficient; custom orchestration where Flow's limits run out. - **Integration.** Workflows wired into the existing app stack rather than replacing it. Operator UI consistent with Shopify Admin. ## How it's built Shopify Flow as the default. Custom orchestration in Python / TypeScript with webhook-driven state machines for the multi-step workflows. Integration with the operator's existing app stack via Shopify's standard API patterns. ## What you get - The workflow audit document. - Custom workflows built where the stack has gaps. - Operator UI for workflow monitoring and override. - Documentation of which workflows are native (Flow / apps) vs. custom. - Ongoing iteration as new workflows are identified. FAQ: - Q: Why not just use Shopify Flow plus the standard app stack? A: Flow plus standard apps handles 80% of operations. The 20% that's not handled — cross-workflow coordination, custom logic that exceeds Flow's runtime, complex multi-step workflows that need state — is where this product lives. The engagement starts by auditing what's already working and building only what's missing. - Q: What does 'custom orchestration where Flow runs out' actually mean? A: Concrete examples. Cart recovery that's customer-segment-aware (different timing and offer for cluster A vs. cluster B). Fulfillment routing that considers carrier rates, customer location, and inventory position across multiple warehouses simultaneously. Return-fraud detection on serial returners with custom business rules. Multi-store inventory rebalancing for portfolio operators. - Q: How does this fit with our existing app stack? A: It composes rather than replaces. Where existing apps work, we keep them. Where the apps create gaps or duplicated workflows, we replace selectively. The audit phase identifies what to keep and what to consolidate. - Q: What's the typical operations-cost impact? A: Per-engagement varies. Common findings: 15–35% reduction in operations-staff time on routine workflows, 5–15% reduction in cart-abandonment loss, 2–8% reduction in fulfillment-cost-per-order. The engagement scopes baseline measurement. - Q: Pricing? A: Scoped to workflow complexity. Discovery call covers the audit scope. --- ## Site Selection Intelligence URL: https://orientedplatforms.com/suites/real-estate/site-selection-intelligence Suite: real-estate Tier: For RE investment teams Engagement: 8–12 week build · ongoing per-market refresh Buyer: Developers · RE-focused PE · REIT acquisitions Problem: Site selection is part data work, part instinct — developers and acquirers know roughly where to look, but the data layer that filters thousands of parcels down to the dozens worth visiting is built ad hoc per deal. Deliverable: A geospatial-and-economic data platform that fuses zoning, transit, demographic, employment, and permit-activity data — produces investment-scoring heatmaps at parcel and neighborhood granularity, configured to the fund's investment thesis. Related: property-valuation-engine , { q: "How is the scoring built?", a: "Per-fund thesis encoded as a scoring rubric — sector affinity (multifamily, industrial, retail), submarket characteristics, growth signal weighting. The rubric is auditable and versioned. Outputs are heatmaps at the right granularity (parcel, census tract, or neighborhood depending on the deal type) plus underlying scoring data.", }, { q: "Can it identify under-the-radar markets?", a: "The product surfaces markets where the leading-indicator signals (permit activity acceleration, employment-base shifting, demographic trajectory) suggest re-rating before it's visible in cap-rate compression. We're upfront that 'under-the-radar' is partly a function of what your fund already covers — the engine adds signal weight to markets you haven't traditionally looked at, not to markets nobody has looked at.", }, { q: "What about international markets?", a: "US is the primary coverage. UK, Canada, Australia supported where the public-data infrastructure permits. Other markets per-engagement, with explicit caveat about data depth.", }, { q: "Pricing?", a: "Scoped to market coverage and the depth of per-market data integration. Discovery call covers both.", }, ], }; ## What this is A geospatial intelligence platform for site selection at scale. Three layers: - **Data fusion.** Public and licensed data layers — zoning, transit, demographics, employment, permits, comparable transactions — joined at parcel and submarket granularity. - **Scoring.** Per-fund thesis encoded as a configurable rubric. Per-market calibration to reflect local-context patterns. - **Visualization.** Interactive heatmaps at multiple granularities. Drill-down from market to neighborhood to parcel. ## How it's built PostGIS as the spatial backbone, dbt for transformation logic, Mapbox or MapLibre for visualization. Per-jurisdiction permit-data ingestion is the labor-intensive piece — we maintain a corpus of jurisdiction adapters and add new jurisdictions per engagement. ## What you get - Per-fund scoring rubric, configured and versioned. - Interactive map UI with multi-granularity drill-down. - Per-jurisdiction permit-feed coverage in the fund's target markets. - Quarterly per-market refresh. - Export-able heatmaps for partner decks. FAQ: - Q: What data layers do you integrate? A: Zoning and entitlement (per-jurisdiction from public records), transit (GTFS feeds, walkability scoring), demographic trajectory (Census ACS plus higher-frequency American Community Survey-class panels), employment (BLS QCEW, regional commuter flow), permit activity (per-jurisdiction permit-application history as a leading indicator). Per-fund, the weighting is configured. - Q: How is the scoring built? A: Per-fund thesis encoded as a scoring rubric — sector affinity (multifamily, industrial, retail), submarket characteristics, growth signal weighting. The rubric is auditable and versioned. Outputs are heatmaps at the right granularity (parcel, census tract, or neighborhood depending on the deal type) plus underlying scoring data. - Q: Can it identify under-the-radar markets? A: The product surfaces markets where the leading-indicator signals (permit activity acceleration, employment-base shifting, demographic trajectory) suggest re-rating before it's visible in cap-rate compression. We're upfront that 'under-the-radar' is partly a function of what your fund already covers — the engine adds signal weight to markets you haven't traditionally looked at, not to markets nobody has looked at. - Q: What about international markets? A: US is the primary coverage. UK, Canada, Australia supported where the public-data infrastructure permits. Other markets per-engagement, with explicit caveat about data depth. - Q: Pricing? A: Scoped to market coverage and the depth of per-market data integration. Discovery call covers both. --- ## Startup Evaluation Engine URL: https://orientedplatforms.com/suites/venture-capital/startup-evaluation-engine Suite: venture-capital Tier: Deal pipeline Engagement: 1–2 week sprint per evaluation · packaged report Buyer: Partners · Principals · Investment committee Problem: Once a deal is in process, the principal-level evaluation work is a person-week per deal — financial model review, cap-table analysis, founder-and-team background, market-size triangulation, comparable-company benchmarking. Across a pipeline of even five active deals, that's the whole quarter gone. Deliverable: A packaged evaluation report per deal — automated financial-model review and cap-table analysis, founder-background research with structured outputs, market-size triangulation, comparable-company benchmarking. Delivered as a partner-readable document for the investment committee. Related: deal-sourcing-signal-platform, founder-network-intelligence , { q: "How accurate is the financial-model review?", a: "Standard model anomalies (math errors, internally inconsistent assumptions, circular references, suspicious revenue-growth assumptions relative to comparable companies) are caught reliably. Subtle modeling judgment (whether the founder's customer-cohort assumptions are realistic given their actual traction) gets surfaced for the partner to review with the founder.", }, { q: "What's in the founder-background research?", a: "Public-source profile (LinkedIn, GitHub, prior-company history, publications, conference talks), structured representation of who-they-worked-with, prior-company outcomes for any companies the founder has founded or been an early hire at. Where the partner asks for deeper screening, we route to the PE Suite's Diligence Red-Flag Engine for the sanctions and beneficial-ownership layer.", }, { q: "How long does this take per deal?", a: "Sprint runs 1–2 weeks from data-room access to packaged report. The partner can read the report and use it as the IC document baseline; the strategic framing and the founder-meeting impressions stay with the partner.", }, { q: "Pricing?", a: "Per-evaluation, scoped to depth requested. Discovery call covers the deal volume and the evaluation depth.", }, ], }; ## What this is A productized DD engagement per deal. Four sections in every report: - **Financial model review.** Math validation, internal consistency, anchored against comparable-company benchmarks for the key assumptions (growth rate, gross margin, sales efficiency, churn). - **Cap-table and dilution analysis.** Current cap table, anticipated dilution through the round and the next two, founder-employee ownership trajectory, option-pool sizing. - **Founder and team background.** Structured profile of the founders and key hires, prior-company history with outcomes, who-they-worked-with graph. - **Market and comparables.** Market-size triangulation across sources, comparable-company benchmarking on metrics relevant to the stage and sector. ## How it's built Excel and Google Sheets parsing for the financial model layer, document AI for cap-table extraction, public-source research stack for founder background (same infrastructure powering Founder Network Intelligence), comparable-data sourcing through the same data infrastructure feeding the Deal-Sourcing & Signal Platform. ## What you get - The packaged evaluation report — partner-readable, IC-document-ready. - The structured datasets behind the report (cap-table table, comparable-company table, founder-background structured profile). - A working session with the partners to walk findings before the partner meeting with the founders. FAQ: - Q: What's the technical-DD piece for software targets? A: For software companies that warrant code-level technical diligence, we route to the PE Suite's Technical DD Engine — that engagement is shaped specifically for the deeper code review. Most VC-stage evaluations don't need the full Technical DD scope; the Startup Evaluation Engine includes the lighter-touch technical posture review. - Q: How accurate is the financial-model review? A: Standard model anomalies (math errors, internally inconsistent assumptions, circular references, suspicious revenue-growth assumptions relative to comparable companies) are caught reliably. Subtle modeling judgment (whether the founder's customer-cohort assumptions are realistic given their actual traction) gets surfaced for the partner to review with the founder. - Q: What's in the founder-background research? A: Public-source profile (LinkedIn, GitHub, prior-company history, publications, conference talks), structured representation of who-they-worked-with, prior-company outcomes for any companies the founder has founded or been an early hire at. Where the partner asks for deeper screening, we route to the PE Suite's Diligence Red-Flag Engine for the sanctions and beneficial-ownership layer. - Q: How long does this take per deal? A: Sprint runs 1–2 weeks from data-room access to packaged report. The partner can read the report and use it as the IC document baseline; the strategic framing and the founder-meeting impressions stay with the partner. - Q: Pricing? A: Per-evaluation, scoped to depth requested. Discovery call covers the deal volume and the evaluation depth. --- ## Statement & Capital-Call Ingestion Engine URL: https://orientedplatforms.com/suites/family-office/statement-capital-call-ingestion-engine Suite: family-office Tier: Ingestion Engagement: 6–10 week build · year-round operation Buyer: Controllers · Operations directors · Junior accountants Problem: Family offices receive a constant stream of financial documents — monthly custodian statements, capital-call notices arriving with 10 days' notice, distribution notices, trade confirms from a dozen brokerages. The team enters them by hand, makes typos, misses calls. Deliverable: A document-AI pipeline that ingests the year-round financial document corpus — statements, capital-call notices, distribution notices, trade confirms — extracts the relevant fields, classifies the transaction, and posts to the ledger of record with confidence-graded review queue. Related: k-1-extraction-engine, invoice-bill-pay-engine, multi-entity-consolidation-platform , { q: "What document types are covered?", a: "At launch: monthly custodian statements (Schwab, Fidelity, Goldman, JP Morgan, BNY Mellon, Northern Trust, plus the standard private-bank formats), capital-call and distribution notices from PE / VC funds (per-GP layout), brokerage trade confirms, wire confirmations, fee invoices from advisors. New document types added as the FO encounters them.", }, { q: "How do you handle the capital-call deadline pressure?", a: "Capital-call notices get the priority lane — extraction within hours of arrival, the controller gets the structured notice with the deadline flagged and the wire instructions extracted. The pipeline reduces 'capital call sat in someone's inbox' incidents that are otherwise the worst-case error.", }, { q: "Does this replace a portfolio aggregator like Addepar?", a: "No. Addepar (or Eton or comparable) takes the cleaned, posted data and presents the wealth view. This pipeline gets the data INTO that system — handles the document-to-structured-data conversion that's otherwise manual or partially-automated. They're complementary; many of our deployments feed an Addepar instance downstream.", }, { q: "Pricing?", a: "Scoped to document volume and the breadth of formats encountered. Discovery call covers both.", }, ], }; ## What this is The year-round document pipeline for everything that isn't a K-1. Three layers: - **Multi-format ingestion.** Per-custodian, per-GP, per-broker templates registered into the pipeline. Email-attachment intake, SFTP for higher-volume sources, manual upload for one-offs. - **Extraction and classification.** Document type identified, relevant fields extracted, transaction classified (capital call, distribution, dividend, trade, fee, wire). Confidence scoring per field. - **Posting and notification.** Routing to the ledger with priority lanes for time-sensitive document types. Capital-call notices get fast-path handling with deadline flagging. ## How it's built LayoutLM-class extraction layered with format-specific templates. Classification head trained on labeled document corpus, extended per FO as new formats are encountered. Priority routing logic configurable per document type. Adapters into AtlasFive / Sage / QuickBooks / NetSuite / Addepar downstream. ## What you get - The ingestion-and-extraction pipeline, running year-round. - Per-format templates for the standard custodian, GP, and brokerage corpus. - Priority-routing logic for capital-call notices and other time-sensitive documents. - The review queue UI for the controller. - Ongoing template-library expansion as new formats arrive. FAQ: - Q: How is this different from K-1 Extraction? A: K-1s are one form, one annual cycle, very high stakes per document. The non-K-1 corpus is many formats (each custodian and GP has their own), arriving year-round, lower stakes per document but much higher volume. Different commercial shape: K-1 is a tax-season operation, this is year-round. - Q: What document types are covered? A: At launch: monthly custodian statements (Schwab, Fidelity, Goldman, JP Morgan, BNY Mellon, Northern Trust, plus the standard private-bank formats), capital-call and distribution notices from PE / VC funds (per-GP layout), brokerage trade confirms, wire confirmations, fee invoices from advisors. New document types added as the FO encounters them. - Q: How do you handle the capital-call deadline pressure? A: Capital-call notices get the priority lane — extraction within hours of arrival, the controller gets the structured notice with the deadline flagged and the wire instructions extracted. The pipeline reduces 'capital call sat in someone's inbox' incidents that are otherwise the worst-case error. - Q: Does this replace a portfolio aggregator like Addepar? A: No. Addepar (or Eton or comparable) takes the cleaned, posted data and presents the wealth view. This pipeline gets the data INTO that system — handles the document-to-structured-data conversion that's otherwise manual or partially-automated. They're complementary; many of our deployments feed an Addepar instance downstream. - Q: Pricing? A: Scoped to document volume and the breadth of formats encountered. Discovery call covers both. --- ## Subscription Economy Benchmarks API URL: https://orientedplatforms.com/suites/operations-algorithms/subscription-economy-benchmarks-api Suite: operations-algorithms Tier: Customer intelligence Engagement: API subscription · monthly benchmark refresh Buyer: Subscription product leads · Pricing teams · Strategy Problem: Subscription businesses operate without the cross-industry benchmarks that public-company businesses have always had. What's the median churn rate for video-streaming subscribers in their seventh month? What share of consumers carry multiple subscriptions in a given category? Each subscription business answers these from its own data, with its own blind spots. Deliverable: An API and dashboard with anonymized aggregate subscription benchmarks across categories — sourced from SubMagician's consumer base, presented as aggregate cohort metrics with explicit privacy boundaries and use restrictions. Related: customer-clustering-ltv-engine, real-time-personalization-api , { q: "What's the data flywheel that makes this valuable over time?", a: "SubMagician's consumer base includes employees of OP's business clients — when those employees use the consumer app, their aggregate patterns become benchmarks the business clients can use. The overlap is structural: more SubMagician adoption means richer benchmarks aligned to the segments enterprise clients actually want to understand.", }, { q: "What categories are covered?", a: "Media (streaming, audio, news), software (consumer SaaS, productivity, security), retail subscriptions (boxes, food, pet, beauty), services (gym, education, dating, transportation). Category breadth scales with consumer-base size; new categories added as the data depth justifies.", }, { q: "How granular are the benchmarks?", a: "Cohort-level, not individual. Typical benchmarks: median retention curve per category, share of consumers with N subscriptions in a category, cross-category subscription affinity, seasonal patterns. Granularity bounded by privacy preservation.", }, { q: "Pricing?", a: "Tiered by query volume and category breadth. Discovery call covers both.", }, ], }; ## What this is A benchmarking layer built on top of SubMagician's consumer subscription tracker — for the subscription businesses that operate without cross-industry visibility. Three layers: - **Data privacy preservation.** Aggregate-only data delivery, k-anonymity-class enforcement, no individual-level leakage. Documented in the privacy architecture. - **Category-level benchmarks.** Retention curves, multi-subscription patterns, cross-category affinity, seasonality, per category. - **API delivery.** Programmatic access for engineering integration, plus a web dashboard for strategy-team analysis. ## How it's built Aggregate query layer over the SubMagician consumer dataset with differential-privacy-class protection where the category and query call for it. API in FastAPI; dashboard in a React UI. Compliance architecture documented per use case (US, EU, UK separately). ## What you get - API access with documented privacy boundary. - Dashboard for the strategy team. - Per-category benchmark coverage with documented sample size and confidence. - Monthly benchmark refresh. - The privacy architecture documentation for your compliance team. FAQ: - Q: Where does the data come from and how is privacy handled? A: Data is sourced from SubMagician's consumer subscription tracker — users who have consented to anonymized aggregate use of their subscription patterns as part of the SubMagician terms of service. The benchmarks are aggregate cohort metrics; no individual-level data leaves the consumer side. The use restrictions are documented in the API terms. - Q: What's the data flywheel that makes this valuable over time? A: SubMagician's consumer base includes employees of OP's business clients — when those employees use the consumer app, their aggregate patterns become benchmarks the business clients can use. The overlap is structural: more SubMagician adoption means richer benchmarks aligned to the segments enterprise clients actually want to understand. - Q: What categories are covered? A: Media (streaming, audio, news), software (consumer SaaS, productivity, security), retail subscriptions (boxes, food, pet, beauty), services (gym, education, dating, transportation). Category breadth scales with consumer-base size; new categories added as the data depth justifies. - Q: How granular are the benchmarks? A: Cohort-level, not individual. Typical benchmarks: median retention curve per category, share of consumers with N subscriptions in a category, cross-category subscription affinity, seasonal patterns. Granularity bounded by privacy preservation. - Q: Pricing? A: Tiered by query volume and category breadth. Discovery call covers both. --- ## Technical Due Diligence Engine URL: https://orientedplatforms.com/suites/private-equity/technical-dd-engine Suite: private-equity Tier: Pre-deal Engagement: 1–3 week sprint per target · packaged report Buyer: Deal teams · Operating partners · GP principals Problem: Buying a software company means buying its codebase. Most diligence shops read the financials and the contracts; few can read the code itself and tell you what shipping that codebase on day 30 of ownership actually looks like. Deliverable: A code- and architecture-level diligence report — red/yellow/green risk heatmap across modules, dependency analysis, test-coverage and CI/CD posture, security vulnerability surface, and the operating-partner-readable summary of what the next twelve months of platform work will cost. Related: deal-sourcing-engine, diligence-red-flag-engine , { q: "What languages and stacks do you cover?", a: "Python, TypeScript / JavaScript, Go, Java, Ruby, PHP, and the major framework variants of each. Mobile (Swift / Kotlin) on request. Where the target has an unusual stack (e.g., Erlang for a comms platform), we bring in specialist help and document where in the sprint that happens.", }, { q: "How do you handle code-access logistics during diligence?", a: "Read-only data-room access is the default. Source code stays in the target's environment; we work inside it. NDA and access logging are standard. The output report references file paths and module names without exposing the code itself — it's reviewable by partners who don't have access.", }, { q: "What's in the report?", a: "Six sections. (1) Architecture summary — what the system is and how it's structured. (2) Risk heatmap — modules graded R/Y/G with the reasoning. (3) Dependency analysis — third-party libraries, license obligations, end-of-life risk. (4) Test, CI, deploy posture. (5) Security surface — known vulnerabilities, configuration gaps, sensitive-data handling. (6) Twelve-month platform-work estimate, scoped to what the operating partner needs to plan.", }, { q: "Pricing?", a: "Per-target, scoped to codebase size and language complexity. Discovery call covers both.", }, ], }; ## What this is A diligence engagement built around a single deliverable: an engineering-shop-quality assessment of the target's codebase, packaged for the deal team and operating partner who have to act on it. The sprint runs against a fixed checklist so the deal team can compare across targets. The checklist evolves with the fund's experience — once an operating partner has read a few reports, they tell us what they wished was emphasized more, and the next version of the checklist incorporates it. ## How it's built Static analysis tooling (SonarQube-class) baseline, layered with manual review where the static signal is shallow. Dependency scanning (Snyk / OWASP-class). Architecture review by engineers who've shipped systems in the target's stack, not by analysts running scripts. The 60% of the work that's automatable is automated; the 40% that requires judgment is judgment-bearing. ## What you get - The six-section report (architecture · risk heatmap · dependencies · CI/deploy · security · twelve-month estimate). - A partner-readable summary — three pages, no jargon. - The risk heatmap as a structured dataset (rows: modules, columns: risk dimensions) so the operating partner can fold it into the post-close hundred-day plan. - A reading session with the deal team to walk through the findings before close. FAQ: - Q: How is this different from a CTO consultant doing the same review? A: Consultants do this work well. The engagement is shaped differently — a one-to-three-week sprint, a packaged report, the same diligence checklist applied across deals so the deal team can compare targets on a common axis. The consultant model produces a great report for one deal; this is built to scale across the deal pipeline. - Q: What languages and stacks do you cover? A: Python, TypeScript / JavaScript, Go, Java, Ruby, PHP, and the major framework variants of each. Mobile (Swift / Kotlin) on request. Where the target has an unusual stack (e.g., Erlang for a comms platform), we bring in specialist help and document where in the sprint that happens. - Q: How do you handle code-access logistics during diligence? A: Read-only data-room access is the default. Source code stays in the target's environment; we work inside it. NDA and access logging are standard. The output report references file paths and module names without exposing the code itself — it's reviewable by partners who don't have access. - Q: What's in the report? A: Six sections. (1) Architecture summary — what the system is and how it's structured. (2) Risk heatmap — modules graded R/Y/G with the reasoning. (3) Dependency analysis — third-party libraries, license obligations, end-of-life risk. (4) Test, CI, deploy posture. (5) Security surface — known vulnerabilities, configuration gaps, sensitive-data handling. (6) Twelve-month platform-work estimate, scoped to what the operating partner needs to plan. - Q: Pricing? A: Per-target, scoped to codebase size and language complexity. Discovery call covers both. --- ## Tenant Intelligence Engine URL: https://orientedplatforms.com/suites/real-estate/tenant-intelligence-engine Suite: real-estate Tier: For RE operators Engagement: 6–10 week build · ongoing operation Buyer: Multifamily operators · Property managers · Leasing teams Problem: Tenant lifecycle decisions — which leads to chase, which renewals to push hard, which complaining tenants are about to leave — are made on instinct or rough rules. The data that would inform them (payment history, support-ticket patterns, neighborhood signals, lease terms) is collected but not analyzed. Deliverable: A classification layer over tenant data — predicts churn probability on existing tenants, scores incoming leads, recommends retention actions tied to predicted risk drivers. Related: dynamic-rental-pricing-engine , { q: "What data does it use?", a: "Lease terms (length, current vs. market rent, concession history), payment history, support-ticket and maintenance-request patterns, tenure, demographic indicators where the property tracks them (employment stability proxies, household composition). All operator-owned data; we don't pull external personal data on tenants.", }, { q: "What does the lead-scoring half look like?", a: "Incoming leads (tour requests, application submissions) get a score representing expected lifetime value — composite of likely-to-convert, likely-to-sign-long-lease, likely-to-renew. Surfaces high-value leads for prioritization by the leasing team.", }, { q: "How do you handle fair-housing compliance?", a: "Carefully. The model excludes protected-class proxy variables (we audit feature importance against the standard protected-class list). The retention-action recommendations are surface-level (timing, communication tone, concession-magnitude options), not personal-treatment differences. We document the fair-housing audit per engagement.", }, { q: "Pricing?", a: "Scoped to portfolio size and integration depth. Discovery call covers both.", }, ], }; ## What this is A tenant-lifecycle classification platform. Two outputs: - **Churn prediction.** Per-tenant 60-day and 180-day non-renewal probability. Probability-banded so the operator acts on confidence levels. - **Lead scoring.** Per-lead expected-lifetime-value score. Surfaces priority leads for the leasing team's attention. Plus a recommendation layer that ties predicted risk drivers to action options (timing of renewal outreach, concession-magnitude tradeoffs, retention communication patterns). ## How it's built LightGBM with monotonic constraints (for interpretability — operators need to defend decisions), feature engineering on the operator's tenant-and-payment data, fair-housing audit of feature importance against protected-class proxies. Integration into the property-management system for surface (AppFolio, Yardi, ResMan). ## What you get - Per-tenant churn probability with banding. - Per-lead lifetime-value scoring. - Retention-action recommendation layer. - Fair-housing audit documentation. - Quarterly model refresh. FAQ: - Q: What's the churn-prediction accuracy? A: On the standard multifamily population, the 60-day churn prediction typically has AUC around 0.82–0.88, with the high-risk decile being meaningfully predictive of actual non-renewal. The product surfaces probability bands, not point predictions — the operator acts on bands, not single-tenant scores. - Q: What data does it use? A: Lease terms (length, current vs. market rent, concession history), payment history, support-ticket and maintenance-request patterns, tenure, demographic indicators where the property tracks them (employment stability proxies, household composition). All operator-owned data; we don't pull external personal data on tenants. - Q: What does the lead-scoring half look like? A: Incoming leads (tour requests, application submissions) get a score representing expected lifetime value — composite of likely-to-convert, likely-to-sign-long-lease, likely-to-renew. Surfaces high-value leads for prioritization by the leasing team. - Q: How do you handle fair-housing compliance? A: Carefully. The model excludes protected-class proxy variables (we audit feature importance against the standard protected-class list). The retention-action recommendations are surface-level (timing, communication tone, concession-magnitude options), not personal-treatment differences. We document the fair-housing audit per engagement. - Q: Pricing? A: Scoped to portfolio size and integration depth. Discovery call covers both. --- ## Trade-Credit & Supply-Chain Score URL: https://orientedplatforms.com/suites/hedge-fund/trade-credit-supply-chain-score Suite: hedge-fund Tier: Alpha layer Engagement: Subscription · monthly score updates · API + SFTP delivery Buyer: L/S equity PMs · Fundamentals analysts Problem: Vendor payment behavior and supply-chain health predict equity returns — companies that hold large trade-credit balances while paying invoices on time outperform their indices. The data is scattered across vendor systems and never assembled at fund scale. Deliverable: A monthly score and supporting attribution data on every covered public company — vendor payment cadence, trade-credit balance trajectory, supplier-concentration risk, supply-chain network deltas. Delivered via API and SFTP. Related: alternative-data-signal-engine, consumer-spending-foot-traffic-dashboard , { q: "What's the universe?", a: "US large- and mid-cap public companies — roughly 2,000 names. Coverage expansion to European mid-cap and select Asian names is on the roadmap.", }, { q: "How is this different from credit-rating data?", a: "Credit ratings are about default risk. This is about operating behavior — does the company pay vendors on time, and is the balance behavior trending in a way that correlates with future operating performance. The published research suggests these signals are orthogonal to the rating-driven signals most funds already trade.", }, { q: "What's the historical depth for backtesting?", a: "Five years of monthly history at launch, extending as the underlying data series ages. Point-in-time correct — vendor and balance data reflect what was knowable at each historical month-end, not retroactive corrections.", }, { q: "Pricing?", a: "Tiered against universe scope and delivery cadence. Discovery call covers both.", }, ], }; ## What this is A ready-made score for funds that want trade-credit and supply-chain intelligence layered onto existing fundamental or factor strategies, without owning the data infrastructure. Three dimensions per company per month: - **Vendor payment cadence.** Aggregated days-payable-outstanding signal across the company's vendor base — sourced and normalized so funds can compare across sectors. - **Trade-credit balance trajectory.** Balance trend over the trailing twelve months, classified for the "high-balance, on-time-paying" pattern published research has flagged as alpha-generating. - **Supplier-concentration risk.** Concentration of revenue on critical suppliers; concentration of supplier dependence in critical geographies; delta-over-time on both. ## How it's built The score is built on top of the Alternative Data Signal Engine pipeline — the custom build serves the score, the score serves the funds that don't need or want the build. Vendor payment data sourced from third-party aggregators; supply-chain network data from shipping manifests and corporate disclosures. Point-in-time aligned at month-end. ## What you get - Monthly score per covered company. - Attribution data — the underlying vendor and supplier deltas the score moved on. - Five years of point-in-time historical data for backtesting. - API and SFTP delivery. - A monthly methodology note when the score-generating model shifts. FAQ: - Q: Why ready-made instead of custom build? A: The dataset is shared. Funds buying this aren't trying to source a unique trade-credit feed; they want the score and the attribution, alongside whatever else they already trade on. Subscription is the right commercial shape for a shared dataset. - Q: What's the universe? A: US large- and mid-cap public companies — roughly 2,000 names. Coverage expansion to European mid-cap and select Asian names is on the roadmap. - Q: How is this different from credit-rating data? A: Credit ratings are about default risk. This is about operating behavior — does the company pay vendors on time, and is the balance behavior trending in a way that correlates with future operating performance. The published research suggests these signals are orthogonal to the rating-driven signals most funds already trade. - Q: What's the historical depth for backtesting? A: Five years of monthly history at launch, extending as the underlying data series ages. Point-in-time correct — vendor and balance data reflect what was knowable at each historical month-end, not retroactive corrections. - Q: Pricing? A: Tiered against universe scope and delivery cadence. Discovery call covers both. --- ## Workforce Scheduling Engine URL: https://orientedplatforms.com/suites/operations-algorithms/workforce-scheduling-engine Suite: operations-algorithms Tier: Operations research Engagement: 8–12 week build · ongoing operation Buyer: Operations managers · HR ops · Store managers · Practice managers Problem: Workforce schedules at most multi-location operations are built weekly in spreadsheets by managers who balance staff availability, labor-law constraints, demand forecasts, and skill requirements by hand — producing schedules that are workable but rarely optimal and almost never auditable. Deliverable: A workforce-scheduling optimizer that produces shift assignments against the business's constraints (skills, availability, labor law, demand forecasts) — runs weekly or daily depending on the cadence, with manager-side UI for review and override. Related: logistics-routing-optimizer, production-resource-planner, demand-forecasting-inventory-engine , { q: "What labor-law constraints are encoded?", a: "Per-jurisdiction. Predictable-scheduling laws (e.g., NYC, San Francisco, Seattle, Oregon), overtime thresholds (federal and state), required-break scheduling, minor-employment restrictions. The constraint library compounds across engagements; new jurisdictions are added as needed.", }, { q: "How does it integrate with demand forecasting?", a: "Where the business deploys the Demand Forecasting & Inventory Engine for retail/hospitality demand, the scheduling engine consumes the forecast directly. Where the business has demand forecasting elsewhere, integration is via API or scheduled feed.", }, { q: "What's the manager-side experience?", a: "The engine produces a draft schedule. Manager UI shows the schedule with the constraint-satisfaction reasoning surfaced — why each shift was assigned this way. Manager edits trigger re-optimization for the downstream cells. Schedules are publish-ready when the manager finalizes.", }, { q: "Pricing?", a: "Scoped to location count, employee count, and constraint complexity. Discovery call covers all three.", }, ], }; ## What this is A workforce-scheduling engagement built around classical OR for the assignment problem. Three layers: - **Constraint formulation.** Per-business constraints (skills, availability windows, max-hours, break requirements, jurisdiction-specific labor law) expressed in the optimization model. - **Solver.** OR-Tools constraint programming for most cases, mixed-integer programming where the problem warrants it. Multi-objective optimization (cost vs. coverage vs. fairness) where the business cares about more than one dimension. - **Operational integration.** Weekly or daily schedule generation, manager UI, integration with the business's HR or time-tracking system for publish-and-clock-in. ## How it's built OR-Tools CP-SAT solver as the workhorse, with mixed-integer formulations via Gurobi or CBC where the problem structure justifies. Python orchestration for the per-cycle problem formulation and post-processing. Manager UI as a lightweight React app or integration into the existing scheduling SaaS where the API permits. ## What you get - The formulated constraint model. - The solver deployment. - Weekly or daily schedule generation pipeline. - Manager UI for review and override. - Per-jurisdiction labor-law constraint library, documented. FAQ: - Q: Doesn't every workforce SaaS (WhenIWork, Deputy, 7shifts) do this? A: Those handle the transactional layer (shift-trading, time clock, communication) well. The optimization layer in those products is typically rule-based with limited constraint handling. For multi-location operations with complex skill-and-availability matching, real labor-law constraints (predictable scheduling laws, overtime thresholds, break requirements), and demand-aligned staffing, dedicated optimization captures structure the SaaS misses. - Q: What labor-law constraints are encoded? A: Per-jurisdiction. Predictable-scheduling laws (e.g., NYC, San Francisco, Seattle, Oregon), overtime thresholds (federal and state), required-break scheduling, minor-employment restrictions. The constraint library compounds across engagements; new jurisdictions are added as needed. - Q: How does it integrate with demand forecasting? A: Where the business deploys the Demand Forecasting & Inventory Engine for retail/hospitality demand, the scheduling engine consumes the forecast directly. Where the business has demand forecasting elsewhere, integration is via API or scheduled feed. - Q: What's the manager-side experience? A: The engine produces a draft schedule. Manager UI shows the schedule with the constraint-satisfaction reasoning surfaced — why each shift was assigned this way. Manager edits trigger re-optimization for the downstream cells. Schedules are publish-ready when the manager finalizes. - Q: Pricing? A: Scoped to location count, employee count, and constraint complexity. Discovery call covers all three. --- # Writing — full posts ## The Stack Evolution URL: https://orientedplatforms.com/writing/stack-evolution Date: 2026-06-11 Author: Bogdan Tags: architecture, django, next.js, asgi, celery, websockets Summary: Six packs from sync baseline to specialized infra — each one triggered by a specific pain point, never by chasing newness. Django + Next.js on a real stack progression. import { PackHero, StackPlate, StackTier, StackRow, StackProtocol, Trigger, EssayClose, TOC, } from "../../app/components/writing"; There are two recurring failure modes in stack progression. The first is jumping ahead of the pain — adopting WebSockets when SSE would have done, or specialized infra when Postgres still had headroom. The second is staying too long on a pack that's no longer fit — workers thrashing, queues backing up, polling clients hammering endpoints that should have streamed. This essay is the map of when to make each jump. Django + DRF on the back, Next.js 16 on the front. Six packs, each one triggered by a specific pain point — never by chasing newness. **Stay on the lowest pack that solves the actual problem.** The contract is simple: client sends, server thinks, server replies, connection closes. Every framework feature is built around this loop — middleware, serializers, the ORM, all of it. Beautiful while it lasts. Most CRUD apps never need to leave this pack. Slow work moves out of the request path. The view dispatches a Celery task, returns a job id, and the frontend **polls** until status is *done*. Beat handles scheduled work — nightly digests, hourly cleanups, periodic syncs. This is the workhorse setup for most SaaS. It will get you very far. **Two new powers.** First, *async views*: a worker that hits `await httpx.get(...)` sets the request aside and serves others until the response arrives. One worker juggles hundreds of concurrent slow I/O calls. Second, *streaming responses*: yield SSE events as a Celery job progresses. The frontend opens one `EventSource` and receives "20% · 50% · done" pushes. The poll loop dies. Same Django, same DRF — the protocol it speaks just changes from WSGI to ASGI underneath. Channels extends Django past request/response. Consumer classes route WebSocket connections like URL routes; the *channel layer* (Redis) lets any process — another web worker, a Celery task, a management command — push a message into a specific socket or a group of them. Daphne or Uvicorn — pick one. Daphne is Channels-native; Uvicorn is faster on plain HTTP. Both work. The composition doesn't change much — the *multiplicity* does. Same components, more of them, with seams between them you can scale independently. The two seams that matter most: **queue priority split** (so a slow ML job can't starve a fast email job) and **Redis split** (Celery's traffic profile and Channels' traffic profile are nothing alike — sharing one Redis is asking for noisy-neighbor pain). None of these are mandatory. Each appears when a specific workload outgrows the general-purpose stack. The art is *not adopting them prematurely* — every new piece of infra is a new operational surface. The discipline carries across the whole evolution: each pack is a response to a real pain, never a response to wanting newer tools. --- ## For operations that already exist. URL: https://orientedplatforms.com/writing/operations-that-already-exist Date: 2026-04-26 Author: Bogdan Tags: positioning, engineering Summary: Why Oriented Platforms is for businesses that already have data, infrastructure, and stakes — not idea-stage MVPs. There's a tension at the front of every services business that takes data-intensive work seriously: the people who *most* want to hire you for software are often the ones who don't yet have an operation. They have an idea. The work to get from idea to operation is enormous, and only some of it is engineering. We've been on the wrong side of that bargain enough times to draw a clear line. ## What "already exists" means An operation already exists when there is *something* in production beyond the website itself: actual customers, actual data, actual money moving, actual stakes. The shape varies — a hedge fund running a strategy, a real-estate firm pricing properties, an ISP installing fiber, a content business analyzing engagement. The detail varies. The presence of stakes does not. When stakes already exist, the engineering question is sharply scoped: *how do we make this thing more correct, more resilient, more intelligent, more automated?* When stakes don't yet exist, the engineering question gets blurred with product, business, distribution, validation. The answer involves software, but the bottleneck rarely is. ## What this means in practice We work with operations that already exist. The list of things this includes is broad: - Hedge funds adding alt-data and quant intelligence layers. - Prediction-markets shops adding rigorous quant. - Real-estate firms adding underwriting and valuation models. - ISPs adding computer-vision QA at the field-installation step. - Premium consumer apps where the data complexity is real (collection management, sports analysis, financial automation). What unites them isn't the industry — it's that **the operation is already running, and the work is to make it data-intelligent**. This isn't a moral position. It's a question of fit. The clients we serve well are the ones whose problem we can actually solve. If you're at the idea stage and looking for a co-founder or a first build, that's fine — there are great people for that. We're not them. ## How to know if we're a fit Roughly: you have an operation that involves data. The data is yours, or you have access to it. You have a sense of what *good* looks like — not necessarily a fully-specified solution, but a clear picture of the decision the system is supposed to support. And you have stakes — money on the line, customers depending on it, a real cost to getting it wrong. If that's you, [book a call](https://cal.com/bgdnandrew/30min?user=bgdnandrew). The booking form has a few scope-shaping questions that make the first conversation efficient. If it's not — that's also useful information; we'll happily say so. --- ## ML in production: the gap between a trained model and a thing customers depend on. URL: https://orientedplatforms.com/writing/ml-in-production Date: 2026-04-23 Author: Bogdan Tags: ml, production, engineering Summary: Training a good model is one thing; running it as a system real customers depend on is another, and the gap is mostly the unglamorous engineering that keeps it shipped — idempotency, queue discipline, observability, schema evolution, and deploys that don't drop users. There's a phrase that gets used loosely: *"the model is in production."* In a notebook on a researcher's laptop, the model returns a prediction when called, and the prediction looks reasonable, and the F1 is good. In a serving framework, the model returns a prediction when called over HTTP, and the latency is fine when one person hits it, and the team is pleased. Both of these are sometimes called *"in production."* Neither of them is. A model is in production when its outputs cause effects on the operation. When a customer's invoice changes because of it. When a trade gets sized differently because of it. When a technician gets dispatched or not because of it. When a piece of content gets shown or hidden because of it. When the model goes down or goes wrong, *something measurable changes for someone who didn't ask for it to change*. Every additional thing that's true about a system in that sense — multiple users, real load, retries, deploys, schema drift, on-call — adds engineering to the model's surroundings. By the time the model is running for a real operation, the engineering surroundings are most of the work, and the model itself is a relatively small part of the software you ship. Almost all of the failure modes that make ML in production hard are not modeling failures. They are systems-engineering failures with a model sitting in the middle of them. This is the unfashionable thing to say in a moment when shipping something is easier than ever. Code generation has compressed the time from idea to "it runs." It has not compressed the time from "it runs" to "it stays running for the customers who are paying for it." The asymmetry between those two milestones is roughly where Oriented Platforms operates. What follows is a partial list of the surroundings. None of it is the model. ## Async correctness Most production ML inference is not synchronous request-response. It is a job that gets enqueued, processed, and whose result gets delivered somewhere else — to a database, to another service, to a downstream model in a chain, to an email. The transition from *"the model returns a prediction"* to *"the prediction reaches the place where it matters"* is its own engineering surface, and most of it has nothing to do with the model. The first question that matters: where does the response go when the model takes thirty seconds, and the user has already navigated away? The second: what happens when two requests for the same input arrive within a second of each other — does the model run twice? The third: if the downstream system is briefly down, does the prediction get dropped, queued, or retried indefinitely? These are the questions that get hand-waved in a notebook and that determine whether the system is correct in practice. The default behavior of *"call function, get result"* is wrong for a system that has to survive partial failures, and replacing it with the right behavior is half the engineering work of getting an ML system into production. ## Idempotency Networks fail. Workers crash. Deploys interrupt jobs mid-processing. Every distributed system has retries somewhere — at the load balancer, at the queue, at the client, at the orchestrator. If retries reach a handler that isn't idempotent, the side effects compound. Predictions get logged twice. Customer-visible counters get incremented twice. Bills get charged twice. The fix is well-understood and almost never the first thing built. Every inference job carries an idempotency key — usually a hash of the inputs plus a request ID — and every side effect is gated on the key not having been seen before. The implementation is some combination of a dedup table, a `SELECT ... FOR UPDATE`, an upsert, or a message-broker feature. The shape varies; the discipline does not. Idempotency is the thing you don't notice when it's working and that destroys customer trust the first time it isn't. *"Why did I get billed three times for one prediction"* is unforgivable in a way that *"the prediction was slightly wrong"* is not. ## Queue saturation under burst Arrival rate is never constant. The number of requests per second the system has to handle right now is not the average; it is the burst. Black Friday hits a retail-adjacent system. A backfill of historical data hits an analytics pipeline. A viral moment hits a recommendation system. A market move hits a trading-adjacent system. If the queue grows faster than the workers drain it, latency goes to infinity. The first symptom is *"requests are slower than usual."* The second is *"alerts are firing for stuck jobs."* The third is *"the system is functionally down."* These all look the same from the outside — the system is unresponsive — and the cause is invisible without queue-depth metrics. The defenses are unglamorous and well-known: backpressure (refuse new work when the queue is too full), autoscaling (add workers under load), load shedding (drop low-priority work to keep the high-priority work flowing), priority queues (hot tenants vs. backfills), and circuit breakers (stop calling downstream services that are themselves saturated). The design choices are operation-specific. The need for them is not. ## Observability You cannot fix what you cannot see. ML systems in production have at least three observability layers, and most teams build only the first one before something else forces them to build the others. - **System performance.** Latency, error rate, queue depth, worker utilization, retry counts. Standard SRE metrics with the model as a black box. This is what tells you the system is up. - **Model performance.** Are the predictions actually right? You almost never have ground truth at inference time, but you usually have it a day or a week later — when the click happens, when the trade settles, when the technician confirms. The pipeline that pulls in delayed labels and computes accuracy/AUC/whatever-matters over a rolling window is the thing that catches a model that has quietly gotten worse. - **Data drift.** The input distribution moves. The model was trained on the world as it was; the world isn't that anymore. Drift detection is unsexy statistics — KL divergence, PSI, a feature-by-feature distribution check — running continuously against the training distribution. When drift trips a threshold, the on-call doesn't fire a page; the model team gets a ticket. Without all three, the failure mode is invariably the same: a customer notices the model is wrong before the team does. That's a credibility hit it takes months to recover from. ## Schema evolution The model was trained on the input shape that existed at training time. The input shape is going to change. A new column gets added upstream. A previously-required field becomes optional. An enum gets a new value the model has never seen. The product team renames a feature. If the model receives an unexpected shape and silently coerces it — fills with zero, drops the field, NaN-propagates — the predictions degrade in a way that is invisible until someone goes looking. *"The model is performing worse"* is a vague enough complaint that it can survive a quarter without a root cause. The defenses again: schema validation at the inference boundary (reject inputs that don't match the contract), versioned schemas (the model declares which schema it expects, and the contract is enforced), and a shadow path for the new schema (run new inputs through the new schema's model in shadow mode, compare results, switch over only when the comparison is good). A model trained on schema v3 should not silently accept schema v4 inputs. It should refuse, or be replaced. ## Deploys without dropping users A model in production is a binary artifact — weights, sometimes a tokenizer or feature transformer, a few config parameters — but the deploy is more than file replacement. There are in-flight requests on the old model when the new one rolls out. There are queued jobs that were enqueued under v1 and will be processed under v2 if you're not careful. There is a window where v1 and v2 are both serving, and they need to either disagree gracefully or not at all. The shapes that work: - **Shadow deployment.** v2 runs alongside v1 for a period; both produce predictions, only v1's are used, the comparison gets logged. After a confidence period, switch. - **Canary.** v2 takes a small fraction of traffic, the model performance metrics are watched closely, the fraction grows over hours or days, then 100%. - **Versioned predictions.** Every stored prediction carries the model version that produced it. When something looks weird in retrospect, you can attribute it to the right model. - **Rollback paths.** The previous model is one config flip away. *"Rolling back is a deploy"* is the failure mode you want to avoid. The design decisions vary by operation. The need to design them deliberately does not. *"Push to prod"* is not a deployment strategy for a model. ## What "shipped and stays shipped" looks like A model that's shipped and stays shipped has all of the above wired up before customers depend on it. It is not the model with the highest leaderboard score. It is the model with the most boring failure modes — the ones you've already prepared for. The gap between *"trained a model"* and *"shipped a model that customers depend on"* is the gap between a notebook and a system. The notebook part is usually the more enjoyable work. The system part is the work that determines whether the project ships value to anyone other than the team that built it. When clients ask us why an ML project is taking longer than they expected, the answer is usually some version of this: the modeling was the cheap part, and the work to get it shipped is the expensive part, and the work to keep it shipped is most of what we're doing here. That ratio is not a sign of a bad project. It is a sign of a serious one. The model is the smallest part. The discipline around it is most of what *"in production"* means. --- ## Connect → clean → model: data orchestration patterns we ship with. URL: https://orientedplatforms.com/writing/data-orchestration-patterns Date: 2026-04-20 Author: Bogdan Tags: data-orchestration, production, engineering Summary: Idempotent handlers, at-least-once delivery, dead-letter routing, back-pressure, schema evolution, and pipeline observability — the recurring patterns that show up in every data pipeline we ship into production. The orchestrator is downstream of these. Almost every data system we ship has the same shape underneath: *connect* (pull from somewhere), *clean* (validate, normalize, enrich), *model* (do the analytical or ML work), *publish* (write to wherever the result is consumed). Each arrow between those stages is a place where the system meets the network — and meets all the failure modes that come with it. The patterns below recur at every arrow. They are not the orchestrator. The orchestrator is what you point at the patterns to schedule them. Picking the right orchestrator is a real decision, but it's downstream of getting these right. Pick the wrong patterns and the orchestrator's retry feature turns into a duplication engine. Pick the right patterns and most orchestrators are interchangeable. This post is the conceptual half. The companion piece compares the orchestrators themselves at production scale. ## Idempotent handlers Re-running the same task with the same input produces the same effect on the world. That is what idempotent means here. It is the single most load-bearing property of a production data pipeline. The reason is that *every* pipeline retries. The retry might be in the orchestrator, in the queue, in the worker, in the network library, in the human operator manually clicking *"rerun."* You cannot prevent retries; you can only design for them. What idempotency looks like in practice depends on the side effect: - **Database writes.** Use upserts (`INSERT ... ON CONFLICT DO UPDATE`, `MERGE`, etc.) keyed on a deterministic ID derived from the input. Re-running the task overwrites the same row rather than inserting a duplicate. Where upserts aren't available, use a dedup table — record `(idempotency_key, completed_at)` and check before writing. - **Object storage writes.** Content-addressed paths. The output filename is `{deterministic_hash}.parquet`, not `{timestamp}-{random}.parquet`. Re-running writes to the same path; downstream consumers don't see a duplicate. - **External API calls.** An idempotency key passed in the request header (the modern API standard). The provider dedups on their side. Stripe, Square, and most modern payment APIs do this; non-payment APIs increasingly do too. - **Message publishing.** A deterministic message ID, plus a consumer that dedups on the ID. (See *at-least-once* below.) The discipline is to think about what the side effect is *before* writing the handler. If you can't articulate what the side effect is, you can't make it idempotent. The cost of getting this wrong is invisible during development and devastating in production. Duplicate financial entries. Double-counted analytics rows. Two emails sent to the same customer. Each one is the kind of bug that survives a quarter before someone notices, and then everyone notices at once. ## At-least-once delivery, and what it implies The default delivery semantics of every modern message queue — Kafka, RabbitMQ, SQS, NATS, Pub/Sub — is *at-least-once*. The queue guarantees that every message will be delivered to a consumer at least one time. It does not guarantee that every message will be delivered at most one time. Duplicates are part of the contract. *Exactly-once* delivery exists in some queues as a feature, but it is expensive (extra round-trips, broker-side state) and brittle in failure modes that span beyond the queue (a broker can be exactly-once internally and the consumer can still process the message twice if it crashes after acking). The conventional wisdom — and the one we ship with — is to assume at-least-once and combine it with idempotent consumers. The result is *effectively* exactly-once at the system level, without paying the broker-side cost. The pattern: - The producer writes a message with a deterministic message ID (derived from the source event, not from the producer's clock). - The consumer dedups on message ID — a small dedup table or, for high-throughput systems, a Bloom filter backed by a periodic compacted log. - Side effects within the consumer are idempotent (per the previous section), so even if dedup misses for some reason, the system stays correct. The two layers of defense are not redundant. Dedup catches the common case efficiently. Idempotency catches the case dedup misses (a stale dedup table, a failover that loses dedup state). Together they get you a system that survives broker hiccups, consumer crashes, and operator reruns without corrupting state. ## Dead-letter routing Sooner or later, a message fails to process and continues to fail on every retry. The data is malformed. The downstream is permanently down. The schema is incompatible. Whatever the reason, the message cannot succeed in its current form, and you have two bad options if you do nothing: it blocks the queue forever, or you start dropping it silently. Dead-letter routing is the third option. After N failed attempts, the message is moved to a *dead-letter queue* (DLQ) with full context — the original payload, the error, the stack trace, the attempt count, the timestamp. The main queue keeps flowing. The DLQ is monitored, and either a human or an automated remediation system handles the failures. Operational discipline: - Alarm on DLQ depth. Zero is the steady state; non-zero is a problem. - Triaging the DLQ is a real engineering task, not a low-priority chore. The patterns in the DLQ tell you something is broken. - Reprocessing from the DLQ is a first-class operation. Once the underlying issue is fixed (a producer schema change rolled back, a downstream service restored), DLQ messages get replayed — through the same idempotent handlers, so reprocessing is safe. Without a DLQ, you choose between a stuck queue and silent data loss. Both are operational disasters. With one, you get a triageable signal that something specific is wrong. ## Back-pressure and circuit breakers When downstream is slower than upstream — even briefly — the queue between them grows. If the queue grows faster than it drains, end-to-end latency goes to infinity, then alerts fire, then the system is functionally down. The cause is rarely visible without queue-depth instrumentation. Two patterns prevent the cascade: - **Back-pressure.** The queue has a bound. When it fills, producers either block (slowing themselves down) or shed (refusing low-priority work). The system as a whole degrades smoothly under overload rather than catastrophically. The right bound is one you can hit during normal bursts and recover from quickly — not infinity. - **Circuit breakers.** When downstream errors exceed a threshold, the consumer stops calling downstream entirely. Requests fail fast — usually returning a graceful default or an explicit "try later" response — until a periodic probe shows the downstream is healthy again. The breaker prevents a degraded downstream from turning every consumer into a slow consumer. Both are well-supported in mature service meshes and HTTP client libraries (Hystrix and its descendants, the standard Go and Rust patterns, Linkerd / Istio at the mesh layer). The choice is not whether to use them but where. Every dependency that *can* be slow should be wrapped. ## Schema evolution The producer's payload shape changes. The consumer was built for the old shape. If the consumer crashes on the new shape, you have an outage. If the consumer silently coerces the new shape, you have wrong data forever. The patterns we use: - **A schema registry.** The producer registers the schema of every message type. Consumers fetch and cache. The registry enforces a compatibility rule on every change. - **Compatibility rules.** *Backward compatibility* means new consumers can read old messages. *Forward compatibility* means old consumers can read new messages. *Full compatibility* is both. For most pipelines we want forward compatibility — the producer can roll out a schema change and consumers don't break, even if they're slow to upgrade. - **Versioned messages.** Every message carries a `schema_version` field. Consumers can branch on it for backward-incompatible changes that can't be avoided. - **Validation at the boundary.** The consumer validates the incoming message against the schema *before* doing anything else. Invalid messages go to the DLQ with a clear error, not into the handler where they cause cryptic downstream failures. The discipline applies inside the system as well as at the edges. Database schemas evolve too; the same compatibility rules apply, with online migrations and dual-writes as the deploy pattern. ## Pipeline observability Three layers, each catching a different class of failure. - **Per-task metrics.** Success rate, failure rate, duration, retry count, last successful run. Standard SRE metrics, scoped per pipeline task. This is what tells you a task is failing. - **Pipeline-level metrics.** End-to-end latency (when did the source event happen vs. when did the result land), throughput (messages per minute), lag (how far behind real-time is the pipeline). This is what tells you the pipeline as a whole is healthy or stuck. A pipeline can have every task green and still be hours behind because of a backlog. - **Data-quality metrics.** Row counts per partition, null rates per column, distribution of key fields, referential integrity counts. This is what tells you the *data* is right — that the pipeline is not silently producing garbage. Most pipelines fail this check long before they fail the per-task check. Without all three, the failure mode is the same: a downstream consumer notices something is wrong before the pipeline team does. With all three, the team has a chance of catching it first. ## The orchestrator is the thinnest layer Pick Airflow, Prefect, Kestra, Dagster, Argo, Temporal — they all give you scheduling, retries, dependency graphs, and a UI. They differ in dynamism, in how they handle data passing, in their concurrency models, in their operational ergonomics. Those differences matter, and they're worth thinking through. (The companion post does that comparison in detail.) But the orchestrator does not give you idempotency. It does not give you schema discipline. It does not give you data-quality observability. Those have to be in the handler — in the code your tasks actually execute. A pipeline is a chain of handlers connected by an orchestrator. The handlers are the load-bearing piece. Get the patterns above right at the handler level, and the orchestrator is mostly a scheduling concern. Get them wrong, and no orchestrator will save you. --- # Work — approach pages ## QuantSandbox: integrated quant research, in production. URL: https://orientedplatforms.com/work/quantsandbox Date: 2026-04-26 Author: Bogdan Tags: quant, production, case-study Summary: Statistical methods, portfolio optimization, options pricing, and a walk-forward backtest engine — exposed for the financially-literate user as one application rather than seven scripts. Quant research, the way most analysts and PMs do it day-to-day, is fragmented. You pull market data in one notebook, fit a GARCH model in another, run portfolio optimization in a third, price options in a fourth, and string together a backtest by hand. The work is real; the workflow is brittle. Tabs proliferate, results stop reconciling, and the feedback loop from idea to validated strategy takes weeks longer than it should. [`quantsandbox.orientedplatforms.com`](https://quantsandbox.orientedplatforms.com) is the alternative we've shipped: one integrated application that consolidates the research-to-validation loop into a single session. ## The shape of the application Eleven research modules, organized around the phases of a quant workflow rather than around the underlying libraries: - **Market data** — price charts, technical indicators, correlation matrices, custom universes. - **Portfolio optimization** — Markowitz mean-variance, Black-Litterman, risk parity. Each method exposes its actual decision points (covariance estimation, view construction, risk budgets) rather than hiding them behind a one-click solver. - **Risk analytics** — VaR, CVaR, Sharpe / Sortino, drawdown analysis, tail-risk metrics. Computed against the portfolios the user has actually constructed, not against canned demos. - **Options pricing** — Black-Scholes, the Greeks, implied-volatility surfaces, binomial / lattice methods, Monte Carlo. The implied-vol surface in particular is the kind of artifact that's easy to generate *badly*; the calibration knobs are exposed. - **Time-series analysis** — ARIMA, GARCH, cointegration tests, stationarity diagnostics, autocorrelation. The methods you actually need before throwing a model at price data. - **Strategy workshop and backtest studio** — see *The backtest engine* below. - **Futures terminal** — futures-specific workflows for the quant subset that lives there. Plus modules covering factor analysis, pairs trading and hedging diagnostics, and the cross-cutting statistical-testing surface. The point isn't the count. It's that one user, with one session and one mental model, can move from raw market data through hypothesis and modeling to a backtested strategy without changing tools — and without losing context every time they switch. ## Methods exposed The library underneath is intentionally opinionated about *what gets exposed*. Around thirty quantitative statistical tests are accessible inside the app (stationarity, cointegration, normality, autocorrelation, regime change, distribution-fit, and so on) — not because users always need them, but because skipping them is the failure mode that produces spurious results. For portfolio construction: | Method | When it earns its keep | | --- | --- | | **Markowitz mean-variance** | When the user has views on returns and a stable covariance estimate. | | **Black-Litterman** | When you want to blend market-implied views with your own priors. | | **Risk parity** | When return forecasts are noisy enough that equalizing risk contribution outperforms guessing. | For options: - Black-Scholes for European pricing baselines. - Binomial / lattice methods for American exercise. - Monte Carlo for path-dependent or exotic structures. - Implied-volatility surface construction with explicit smile / term-structure handling. - The Greeks (Δ, Γ, Θ, Vega, Rho) on any structure the user prices. For risk and validation: historical, parametric, and Monte Carlo VaR; CVaR; Sharpe and Sortino; max drawdown and drawdown duration; tail-risk indicators. ## The backtest engine The piece that takes the longest to build correctly, and the one most quant tools handle worst. QuantSandbox uses an **event-driven simulation**: for each strategy under test, the engine processes a stream of market events in chronological order, and the strategy reacts to each one as it would in production. No look-ahead. No vectorized batch tricks that accidentally use Friday's close to compute Monday's signal. On top of that: - **Walk-forward validation.** Fit the strategy on a rolling window, evaluate on the next out-of-sample window, advance. Repeat across the full history. The result is a series of out-of-sample evaluations rather than a single in-sample fit — which is the only way to estimate how a strategy will degrade in live conditions. - **Execution cost modeling.** Slippage, commissions, market impact priced realistically. Backtests that ignore these consistently overstate returns; backtests that include them are usually the moment a "promising" strategy stops being promising. - **Pre-built strategy templates** — momentum, mean reversion, pairs, factor, an options overlay, and a buy-and-hold benchmark — each editable and serving as a starting point rather than a black box. The metrics surface (total return, Sharpe, max drawdown, win rate, exposure profile) reads at a glance and reconciles against the underlying trade log. The two should always agree; the user can verify they do. ## Asset class coverage Equities (demonstrated against FAANG and broader US universes by default), futures contracts, and options. Strategies can compose across these — an equity portfolio with options overlays, a pairs trade hedged with futures — inside a single workspace. ## Who QuantSandbox is for The financially-literate user who would otherwise run this analysis across seven tools and lose half their time to plumbing. Concretely: quant researchers, factor PMs, students of systematic strategies, and engineers evaluating or building quant systems for their own desks. It is **not** a retail-broker dashboard, not a black-box *"AI picks stocks"* gimmick, and not a closed platform. The methods are exposed. The decision points are visible. The results reconcile. ## Why we built it QuantSandbox started as the in-house tool we wanted: somewhere to evaluate methods quickly without rewriting the same scaffolding — data loaders, statistical tests, backtest harness — for every new project. Once it became real software, putting it online for any financially-literate user to access made more sense than keeping it private. It is the canonical example of the kind of work Oriented Platforms ships: data and intelligence, integrated and operationalized, for users with stakes. [Use it →](https://quantsandbox.orientedplatforms.com) --- ## Intelligence layers for hedge funds running existing strategies. URL: https://orientedplatforms.com/work/hedge-fund-quant-alt-data-layer Date: 2026-04-22 Author: Bogdan Tags: hedge-fund, alt-data, quant, case-study Summary: Alt-data ingestion with point-in-time correctness, feature libraries that don't leak look-ahead, signals an existing strategy can absorb, and attribution that survives the next risk-committee review. Anonymized engagement pattern. The brief, in shape: a fund is running a strategy. The strategy has been good for some number of years, but the marginal information advantage is shrinking. They want an intelligence layer — alt-data ingested cleanly, transformed into features and signals their existing process can absorb, with attribution that holds up under scrutiny. The work is not to replace the strategy. It is also not to *"build a fund."* It is to make the existing operation more data-intelligent without compromising the part of it that already works. This is anonymized — no client names, no specific datasets, no PnL figures — but the engagement pattern is consistent enough across the work we've done that the architecture below describes the actual thing rather than a stylized caricature. ## What's already there, what isn't The fund typically has: - A reliable market-data layer (vendor-fed, plus internal cleansing). - A strategy stack — some mix of Python, kdb, C++ — that produces positions on whatever cadence the strategy runs at. - A research environment where PMs and quants iterate. - Risk and compliance already in place. What they don't have, typically, is a clean alt-data pipeline. Vendor data lands as files, the schema drifts, the timestamps are ambiguous, the entity mapping is wrong, and *"ingestion"* is whatever the most recent intern wrote. Point-in-time correctness is an aspiration rather than a guarantee. And there's no way to merge alt-data-derived signals into the existing strategy without contaminating its evaluation history. That's the surface area. ## Alt-data ingestion: the unglamorous foundation The single most common failure mode in alt-data integration is leakage from delivery time vs. observation time. A vendor sends Tuesday's data on Wednesday morning. The data is *"as of Tuesday"* but you didn't have it Tuesday. A naive backfill stamps Tuesday's row with Tuesday's date, and a year later your backtest looks magnificent because it's using information that wasn't available at decision time. What we build instead: an ingestion layer that records, per row, both the *observation timestamp* (when the underlying event happened) and the *availability timestamp* (when the data became queryable in the fund's system). Every downstream feature, signal, and backtest pulls *as-of* the availability timestamp. Look-ahead bias becomes structurally impossible rather than contractually forbidden. Concretely: - Schema-validated landing tables with explicit `observed_at` and `available_at` columns. - Idempotent loaders, so re-ingesting a vendor's correction doesn't double-count. - Entity resolution against the fund's existing instrument universe — vendor tickers, Bloomberg tickers, and internal IDs do not agree, and this is where most pipelines silently drop rows. - Versioned schemas, so a vendor's mid-quarter format change doesn't corrupt the historical record. Nothing about this is glamorous. It is the difference between an alt-data layer that survives an audit and one that doesn't. ## Feature engineering, point-in-time Above the ingestion layer sits a feature library: quantities derived from the alt-data that map onto the strategy's existing decision surface. Sentiment indices, supply-chain indicators, behavioral aggregates, event flags — whatever the dataset surfaces and the strategy can absorb. Each feature carries: - A definition — the actual transformation, in code, source-controlled. - A point-in-time evaluation function that takes a date `d` and returns the feature value as it would have been computable using *only* data available at `d`. - Tests against a small set of historical dates with known correct values, run on every change. The point-in-time function is the load-bearing piece. It is what lets the same feature library serve both research backtests and live signal generation, with no diverging implementation between the two — the bug class that kills more strategies than any other. ## Signal generation, with the strategy team in the loop The intelligence layer outputs signals — usually scalar or low-dimensional — that the existing strategy can incorporate as inputs. The strategy team decides how to weight them, whether to use them at all, and how to combine them with their existing alpha. This boundary is deliberate. The fund's strategy team owns the strategy. We own the input quality and the feature/signal infrastructure. Crossing the line — building the strategy *for* them — is how engagements go bad. They know things about the strategy we will never know, and we know things about the data plumbing they have no reason to want to know. ## Attribution Once the new signals are in the strategy, the fund needs to know what they're contributing. Not just total PnL, which is contaminated by everything else, but the *marginal contribution* of the new signal stream relative to a counterfactual where it isn't used. Walk-forward attribution — running the strategy with and without the new signals over rolling windows, under the same execution model and the same constraints — is the cleanest method. The output is a time series of marginal contribution that survives the next risk-committee review. The same machinery makes turning a signal off easy. If a feature stops earning its keep, it gets shelved without ceremony. ## What ships vs. what stays theirs The fund keeps the strategy, the research environment, the PMs, the risk system. We ship: - The ingestion pipeline — their infrastructure, their accounts, their cloud, their secrets. - The point-in-time feature library — theirs to extend. - The signal generation layer — theirs to retune. - A handover document and operational runbook, so their team runs it without us. The integration is async-first; we work alongside their team rather than on top of them. ## The pattern Every hedge-fund engagement we've done in this space has the same shape: existing operation, marginal information advantage shrinking, alt-data and intelligence layers as the lever. The work is in the boring parts — point-in-time correctness, schema discipline, attribution that holds up — not the glamorous parts. The strategy stays the strategy. The operation gets sharper. --- ## Computer-vision QA for field-installation operations. URL: https://orientedplatforms.com/work/field-operations-cv-qa Date: 2026-04-18 Author: Bogdan Tags: computer-vision, field-operations, production, case-study Summary: On-device CV models that run in the technician's hand, paired with large-scale registration databases, integrated into the existing field workflow rather than bolted on top of it. Anonymized engagement pattern. The brief, in shape: a field-operations business — utilities, telecom, energy, last-mile networks — runs thousands of installations or repairs per week. Technicians do the work in trucks, on poles, in basements, in attics. Each job has a spec: parts to install, tolerances to meet, photos to capture as evidence. Quality assurance is the bottleneck. Without computer vision, the QA loop is one of two things. Either nobody reviews most photos, and bad installs slip into the field — with the cost paid later in callbacks, leaks, outages, refunds — or a back-office team reviews photos hours or days later, by which point the technician is two jobs away and the rework is expensive. The intervention is a CV layer that runs *in the technician's hand*, gives feedback before they leave the site, and registers every photo against the right install in a database that survives the audit a year later. This is anonymized — the underlying engagements are NDA — but the pattern is consistent. ## What CV in the field actually means The system has four jobs, in order of operational importance: 1. Catch the obvious failures before the technician leaves. *"This photo is too dark to verify the connection."* *"The serial-number label is not in frame."* *"This appears to be a 12mm fitting; the spec calls for 15mm."* 2. Reduce the back-office QA load. Anything the model is confident is correct doesn't need a human reviewing it. Anything ambiguous gets routed to a human with the model's reasoning attached. 3. Register every photo with its full operational context — install ID, customer, step in the workflow, GPS, timestamp, model version that judged it — so the audit trail is real. 4. Surface patterns. Which technicians are getting flagged the most? Which install steps are the highest-failure? Which equipment lots are showing anomalies? Each of these has a different engineering shape. The first two are model-and-inference. The third is data plumbing. The fourth is analytics on top of the photo log. ## Training data, the long pole The single largest cost in the project is labeled training data. Field photos are noisy: bad lighting, motion blur, weird angles, partially-obscured parts, snow, dust, technician fingers in frame. *"This object is a coupling"* is easy in a clean studio shot and brutal in a real one. What we build: - A labeling pipeline that prioritizes edge cases — the ambiguous photos that would be hardest for the model — so labeler time goes where the model is weakest. - A workflow that lets the field-ops business's own subject-matter experts label, with calibration tasks so we know which labelers agree with the spec and which don't. - Active learning: as the model improves, low-confidence photos get re-routed back into the labeling queue, so the dataset converges on the model's actual failure modes rather than on whatever the first batch happened to contain. Versioned datasets, versioned label schemas, versioned model artifacts. Every prediction in production traces back to the dataset version it was trained on. ## Model architecture, on-device The model has to run on the technicians' hardware — a mix of mid-tier Android phones, ruggedized handhelds, and the occasional ageing iPad — without a network connection. Cloud inference is not an option for the live path; the work happens in basements and on rural roads. We typically end up with a two-stage shape: - A small object-detection model (YOLO-family or comparable lightweight detector) that locates the relevant parts of the photo. - A classifier or regression head on each detection that answers the QA question — right part / wrong part, in spec / out of spec, label readable / not readable. Quantized to int8, packaged through ONNX Runtime or the platform-native equivalent (Core ML on iOS, TFLite on Android), the inference budget is small enough to give feedback in a second or two on a five-year-old phone. The model itself is a few tens of megabytes; updates ship through the field-ops app's existing release pipeline, with version tracking so we know exactly which model rendered each verdict. ## Registration against a large database Every photo gets associated with the install record, the customer, the workflow step, GPS, timestamp, technician ID, equipment serial numbers where readable, and the model version + confidence that produced its verdict. This metadata is the difference between *"the system caught a defect"* and *"we can prove, six months later, exactly which install, which technician, and which part was involved."* The database is operational, not analytical. It serves the live workflow first — the technician's app needs the install's photo history fast — and the analytics queries run off a derived warehouse, so heavy reporting doesn't impact live response times. ## Field-tech workflow integration This is the part most CV-in-the-field projects get wrong. Technicians have thirty seconds per photo, not ten minutes. The CV layer cannot be slow, condescending, or wrong-feeling. If it cries wolf on legitimate work, technicians stop trusting it within a shift, and within a week they're tapping past every prompt. What we do instead: - Default to silence. The CV layer only intervenes when it has high confidence something is wrong. - When it does intervene, it shows the technician *exactly what it saw* — the bounding box, the inference, a brief phrase — so the technician can either correct it (retake the photo) or override it, with the override reason captured for back-office review. - Overrides are first-class citizens. If a technician overrides the model and is right, that's a labeled training example. If the model is overridden too often in the wrong direction, the model gets retrained. The field-ops business's existing app and existing workflow are the host. We integrate; we don't replace. ## The pattern Every field-CV engagement has the same shape: an existing operation that runs at scale, a QA bottleneck that hurts both customer experience and unit economics, and a CV layer that intervenes in the technician's hand rather than in some back-office screen. The model itself is one of the cheaper components. The expensive parts are the training-data pipeline, the database registration, and the workflow integration. The technicians keep doing the work. The work just gets a real-time second pair of eyes that doesn't sleep. --- # Notes ## Airflow vs. Prefect vs. Kestra at production scale. URL: https://orientedplatforms.com/notes/airflow-prefect-kestra-at-production-scale Date: 2026-04-19 Author: Bogdan Tags: data-orchestration, airflow, prefect, kestra, comparison Summary: Three orchestrators we've shipped with, the operational shapes each fits, and the production gotchas that don't show up in benchmarks. Companion to the data-orchestration-patterns post. The companion post argued that the orchestrator is the thinnest layer of a data pipeline — the patterns under it (idempotency, dead-letter routing, back-pressure, schema discipline, observability) matter more than the tool that schedules them. This note is the orchestrator comparison itself. The three we ship with most often: **Airflow**, **Prefect**, **Kestra**. The aim is not a feature matrix. It's an honest read of what each one is good at, where each one strains, and how to pick between them when the patterns are already in place. ## At a glance ## Airflow — the default for a reason The default isn't a derogation. Airflow has the largest ecosystem of any orchestrator, every major cloud offers a managed version (MWAA, Cloud Composer, Astronomer's offering wrapping vanilla Airflow), the operator catalog covers nearly every system you might want to talk to, and there's a decade of accumulated production experience in the public corpus. The job postings agree. Where it earns its keep: existing infrastructure where Airflow is already running, batch-heavy ETL with stable cadences (hourly, daily, weekly), and teams whose mental model already speaks DAG / operator / sensor. Where it strains: the scheduler is the historical bottleneck. Airflow 2.x improved this dramatically and 3.x continues to; even so, scheduler latency, executor choice (Celery vs. Kubernetes vs. local), and metadata-database load are real production concerns at high task volume. Dynamic DAG construction works but is awkward — the pattern was bolted onto a static-DAG world. The operator/sensor model encourages a coding style where business logic leaks into Airflow primitives, which makes the pipelines hard to test outside Airflow. The honest read: if you're greenfield and Python-native, you probably don't need Airflow. If you're integrating into a stack that already has it, fighting it is expensive and rarely justified. ## Prefect — Pythonic by design Prefect's value proposition is a much cleaner Python surface. Flows are functions, tasks are functions, the orchestration is data flowing through Python rather than through XComs. Local development is straightforward — `prefect.run_local()` and your flow runs the same way it will in production. Dynamic flows, mapping, and conditional branches are first-class rather than retrofitted. Where it earns its keep: greenfield pipelines in Python, mixed batch/streaming workloads (the agent/work-pool model handles both), teams that read `def` more naturally than YAML, and projects that benefit from running the same flow code locally and in cloud. Where it strains: self-hosting Prefect Server is real work — the happy path is Prefect Cloud, and Cloud cost scales with run volume in a way that surprises teams that didn't price it in. The 2.x to 3.x transition (and the earlier 1.x to 2.x rewrite before it) means the public corpus is fragmented across versions, and answers from a year ago might be wrong now. The ecosystem is smaller than Airflow's; some integrations you'd reach for an Airflow operator for don't exist as Prefect blocks and you write them yourself. The honest read: if your team is Python-fluent and the pipeline is greenfield, Prefect is usually the more pleasant tool day-to-day. The operational tradeoffs (self-hosting effort, Cloud cost) are the questions to ask before committing. ## Kestra — declarative and event-driven Kestra is the newest of the three in the production space. The defining choice is YAML-first: pipelines are declarative documents, not Python code. Event-driven triggers are first-class — Kafka, webhooks, file drops, schedule, and a flow trigger model that lets one pipeline cleanly invoke another. The UI is the most complete of the three out of the box, particularly for non-engineer stakeholders who want to see what's running. Where it earns its keep: pipelines where triggers and integrations dominate (event-driven workloads, multi-system orchestration), teams that aren't all Python-fluent (analytics engineers, data engineers from a JVM background, ops staff who want to read the pipeline without reading code), and shops where YAML-as-source-of-truth is a desired property — easy to version, easy to review, easy to generate. Where it strains: the community is smaller, so plugin maturity for niche systems is uneven (the popular ones are excellent; the long tail is not). Breaking changes still happen on minor versions in ways that mature Airflow installs would not tolerate. The Pebble templating language is powerful but adds a second mental model on top of YAML, and complex flows can develop a feeling that a real programming language would have been simpler. The honest read: when the workload is event-shaped and integration-heavy, Kestra's design has fewer rough edges than the alternatives. When the workload is pure Python data processing, the YAML surface adds friction. ## At production scale: where the gotchas live For all three, the production failure modes are not "the tool doesn't work." They are operational details that benchmarks don't surface. - **Airflow.** Scheduler latency is real — under load, tasks that *should* start at `T` start at `T + 30s` or worse. Mitigations: scheduler HA (multiple scheduler processes), tuning `min_file_process_interval`, switching to the Kubernetes executor for spike workloads. The metadata DB is the second bottleneck; partitioning historical task instance rows or aggressively trimming history matters at high volume. Logs: pick a remote-log handler (S3, GCS, ELK) early — the local-disk default does not survive any real install. - **Prefect.** Concurrency limits are on flows *and* on tasks; misconfigured, you get either thundering herds or starvation. Work pools want to be carefully sized to the worker fleet. Prefect Cloud bills on flow runs and task runs both — high-cardinality task fan-out can balloon the bill. Self-hosted: the Postgres backing store wants to be tuned the same way Airflow's does. - **Kestra.** The internal storage backend (where flow state and intermediate data live) is the operational lever — local filesystem is a starter only, S3 / GCS / Azure Blob is the production answer. Plugin versions need to be pinned; auto-updates have bitten installs. Schema changes between minor versions are sometimes manual. ## The pick is downstream of the patterns If the patterns under the orchestrator are right — idempotent handlers, at-least-once + dedup, dead-letter routing, schema discipline, observability — all three of these work. The choice is operational, not architectural. Pick the one whose strengths match your operation, whose gotchas you can absorb, and whose ecosystem your team can navigate. If the patterns are wrong, no orchestrator saves you. Airflow's retries become a duplication engine. Prefect's mapping turns into a fan-out catastrophe. Kestra's triggers fire on events that should never have been emitted. Fix the patterns; then the orchestrator is a tool decision, not a bet. --- ## Comparing options-pricing libraries in Python. URL: https://orientedplatforms.com/notes/options-pricing-libraries-in-python Date: 2026-04-17 Author: Bogdan Tags: quant, python, options, comparison Summary: QuantLib for the heavy machinery, vollib for fast vanilla pricing, and a custom numpy/scipy stack for when control matters more than features. Code-side comparison from the QuantSandbox toolchain. If you're pricing options in Python, you have three reasonable shapes to choose between: a heavyweight library that covers everything ([QuantLib](https://www.quantlib.org/)), a lightweight library that covers vanilla pricing very well ([vollib / py_vollib](https://github.com/vollib/py_vollib)), or a custom stack on top of numpy / scipy / Cython for when control matters more than features. This is the comparison from inside the QuantSandbox toolchain. We use all three at different points; the choice depends on what's being priced and why. ## At a glance ## The same call price, three ways Closed-form Black-Scholes for a European call: spot 100, strike 100, 1y to expiry, 5% rate, 20% vol. **QuantLib:** ```python import QuantLib as ql today = ql.Date(26, 4, 2026) ql.Settings.instance().evaluationDate = today expiry = today + ql.Period(1, ql.Years) spot = ql.SimpleQuote(100.0) rate = ql.SimpleQuote(0.05) vol = ql.SimpleQuote(0.20) spot_h = ql.QuoteHandle(spot) rate_ts = ql.YieldTermStructureHandle( ql.FlatForward(today, ql.QuoteHandle(rate), ql.Actual365Fixed()) ) vol_ts = ql.BlackVolTermStructureHandle( ql.BlackConstantVol(today, ql.NullCalendar(), ql.QuoteHandle(vol), ql.Actual365Fixed()) ) process = ql.BlackScholesProcess(spot_h, rate_ts, vol_ts) engine = ql.AnalyticEuropeanEngine(process) payoff = ql.PlainVanillaPayoff(ql.Option.Call, 100.0) exercise = ql.EuropeanExercise(expiry) option = ql.VanillaOption(payoff, exercise) option.setPricingEngine(engine) print(option.NPV()) # ~10.45 ``` **vollib:** ```python from py_vollib.black_scholes import black_scholes price = black_scholes( flag="c", S=100, K=100, t=1.0, r=0.05, sigma=0.20 ) print(price) # ~10.45 ``` **Custom:** ```python import numpy as np from scipy.stats import norm def bs_call(S, K, t, r, sigma): d1 = (np.log(S / K) + (r + 0.5 * sigma**2) * t) / (sigma * np.sqrt(t)) d2 = d1 - sigma * np.sqrt(t) return S * norm.cdf(d1) - K * np.exp(-r * t) * norm.cdf(d2) print(bs_call(100, 100, 1.0, 0.05, 0.20)) # ~10.45 ``` The custom version is twelve lines shorter than the QuantLib version and runs faster than QuantLib for a single call (no Python-to-C++ marshalling). vollib's three-line version sits in the middle. Whether the brevity is worth what it gives up depends entirely on what you need next. ## When to reach for QuantLib The case for QuantLib is breadth. American options with discrete dividends. Bermudan options with a custom exercise schedule. Asian options. Barrier options with rebates. Forward-start, cliquet, look-back. Multi-asset. Bonds with embedded calls. Yield-curve construction with bootstrapping. Vol surface calibration to a market grid. SABR. Heston. Local volatility. If the pricing problem is anything beyond a vanilla European, QuantLib is the path of least resistance. Implementing American options correctly is an afternoon's work to get the algorithm wrong and a week's work to get it right; QuantLib has had it right for fifteen years. The cost is real. The Python bindings are SWIG-generated, which means the API has C++ texture all over it (`QuoteHandle(SimpleQuote(...))`, term structure handles, day count conventions explicit at every step). Documentation is mostly the C++ docs plus the example notebooks. The install is non-trivial — `pip install QuantLib-Python` works on most platforms now, but C++ build issues still happen. Date and calendar setup must be done early and consistently or pricing dates silently drift. When the workload is *building a vol surface, calibrating Heston, pricing a portfolio of exotics* — reach for QuantLib and accept the API. ## When to reach for vollib The case for vollib is speed and simplicity on the vanilla path. py_vollib wraps `py_lets_be_rational`, which is Peter Jäckel's "Let's Be Rational" implied-volatility solver in Cython. For Black-Scholes pricing, Greeks, and (especially) implied-volatility inversion, it is among the fastest options on Python. If the workload is *price a million vanilla options, compute Greeks across a grid, invert IV from a market chain* — vollib will do it in a tight loop faster than almost anything else, and the API is exactly as simple as it looks. The constraints are also exactly what they look like. No American options. No exotics. No calibration. No surface fitting. The moment the workload steps outside vanilla European, vollib stops being applicable. ## When to reach for a custom stack The case for custom is control. Numpy is excellent at grids — pricing a 1000×1000 grid of (strike × maturity) points with vanilla Black-Scholes is one vectorized expression and runs in milliseconds. A custom binomial tree implementation can be tuned for a specific use case (specific dividend handling, specific exercise rules) in a way the library versions cannot. A Monte Carlo with antithetic variates, control variates, and a specific variance-reduction scheme is straightforward to write directly and very tedious to extract from a general-purpose library. The cost: every line is yours to test and maintain. Every edge case (negative rates, near-zero vol, extremely-deep ITM, expiration handling) is yours to handle. The first three you'll catch; the fourth will bite you in production. When the workload is *a tight, specific computation that benefits from vectorization or specialization* — write it. When it's *anything where breadth or correctness across edge cases matters* — don't. ## A practical example: implied vol from a market chain Inverting IV across a chain of 500 options is the workload that surfaces the differences sharply. ```python # vollib — fast, vanilla, two lines from py_vollib.black_scholes.implied_volatility import implied_volatility ivs = [ implied_volatility(price, S, K, t, r, flag) for price, K, flag in chain ] ``` vollib does this in tens of milliseconds on a normal machine. QuantLib does it correctly but the per-call SWIG overhead and the term-structure setup add up. A custom Newton-Raphson loop is teachable but not as well-conditioned as `let_be_rational` for deep ITM / OTM where the BS price is numerically flat. For implied vol on vanilla chains, vollib is the right answer. The QuantSandbox IV-surface module uses vollib for the inversion step, then hands the surface to QuantLib for parametric fitting (SVI, SABR) and to a custom layer for the visualization grid. That's not a contrived example — it's the actual stack. Each library does the part it's good at. None of them does the whole thing. ## The pick is per-problem The honest answer to *"which options-pricing library should I use"* is: it depends on what you're pricing. Vanilla and IV inversion at scale: vollib. Anything beyond vanilla, or any work involving calibration / multi-asset / fixed income: QuantLib. Specific high-throughput grids or workload-specific optimization: custom. Most production quant systems we've shipped end up using two of these together — vollib for the hot vanilla path, QuantLib for the breadth, occasionally custom code where one of them doesn't fit. Mixing is fine. Picking one and forcing every problem through it is the failure mode. --- # Contact Book a 30-minute call: https://cal.com/bgdnandrew/30min?user=bgdnandrew Subscribe to the writing feed: https://orientedplatforms.com/writing/rss.xml