DataAcuity — Product Specification

Status: Strategic direction confirmed. BI data flows to be defined. Classification: Public-safe: offering name + high-level positioning only. Internal: strategy, flows, pricing. Links: See AppInfo/_shared/CONFIDENTIAL-internal-narrative.md for internal strategic context. Memory: CLAUDE_SESSION_STATE.md → Active Work section.

What DataAcuity Is (Public-safe)

DataAcuity is The Geek Network's enterprise-facing data and business intelligence platform.

It provides organisations with structured, consented, ethically-sourced insights from one of the most data-rich ecosystems in Africa — built on a network where every user is compensated for their data, not extracted from.

The difference from traditional BI: the underlying data is:

• Consented at point of interaction (per-app consent, per-user control)
• Verified (identity anchored via SDPKT + TrustSeal)
• Multi-lingual and offline-capable (Aether by Circle mesh captures activity even without internet)
• Real-world (TagMe's social graph captures physical-world activity not available via web crawl)
• Pan-African and increasingly global

The Three-Path Strategy (Internal — do not publish)

Reference: AppInfo/_shared/CONFIDENTIAL-internal-narrative.md

Path A — Single enterprise data contract: REJECTED. Beholden to one business.

Path B — Industry reports: ✅ Chosen.

• Aggregated, anonymised sector reports sold to industries
• No single client dependency
• Compliant with 200+ territory laws by design (see AppInfo/_shared/aether-global-compliance.md in .claude-memory/)
• Example output: "South African consumer spend patterns by province, Q1 2026, anonymised cohort N=400,000"

Path C — Embedded Pro tier: ✅ Chosen.

• Premium data layer embedded within enterprise products
• API access to aggregated signals (not raw PII)
• SDK for embedding DataAcuity dashboards in partner platforms
• Pricing: subscription-based, tiered by API call volume / active seats

Path D — Wolverine Observability SaaS: ✅ Chosen.

• The Wolverine self-healing pipeline (already running at WolverineAPI:5014) becomes a standalone SaaS product
• Sell the AI-powered event sourcing + anomaly detection + auto-remediation as a product
• Target: mid-market engineering teams who can't afford enterprise observability tools
• Differentiator: built for high-churn, low-infrastructure African tech stacks

Data Sources (The Ecosystem Feeds DataAcuity)

All signals: consented via per-app consent UI. Users earn Qi for consenting. See AppInfo/Butler/QI_KARMA_ECONOMIC_MODEL.md.

BI Data Flows (TO BE DEFINED — open task)

This section is the core outstanding work. The user directive: "DataAcuity needs us to define the BI data flows."

Proposed flow architecture (draft — requires validation):

[App Layer] → [Event Bus / WolverineAPI:5014] → [DataAcuity Aggregation Layer]
                                                        ↓
                                           [Anonymisation + Cohort Builder]
                                                        ↓
                            ┌──────────────┬────────────┴──────────────┐
                            ↓              ↓                           ↓
                    [Industry Reports]  [Embedded Pro API]   [Wolverine SaaS Dashboard]
                    (PDF/dashboard)     (REST endpoints)      (Ops + anomaly UI)

Key questions to answer (next session):

1. What is the event schema emitted by each app to WolverineAPI?
2. How does the Anonymisation layer work — k-anonymity, differential privacy, or both?
3. What is the Cohort Builder logic — demographic segmentation rules?
4. What are the Pro API endpoints and their output schemas?
5. How does the Wolverine SaaS differ from the internal WolverineAPI — white-label or shared?
6. Where does the DataAcuity data warehouse live? PostgreSQL on .104/.105? Or separate?
7. What is the data retention policy per source?
8. How does per-territory compliance (GDPR, POPIA, CCPA, NDPR etc.) affect the flow?

Reference files that inform this:

• docs/WOLVERINE_HEALING_PIPELINE.md — internal Wolverine architecture
• AppInfo/_shared/aether-global-compliance.md in .claude-memory/ — territory compliance rules
• AppInfo/_shared/banking-compliance-rules.md in .claude-memory/ — financial data rules

Compliance by Design

DataAcuity must comply with laws of 200+ territories by design — not as an afterthought.

Key territory laws that affect data products:

• South Africa: POPIA (Protection of Personal Information Act)
• EU/Netherlands: GDPR
• Nigeria: NDPR (Nigeria Data Protection Regulation)
• Kenya: Data Protection Act 2019
• Japan: APPI (Act on the Protection of Personal Information)
• USA: CCPA (California), various state laws
• Brazil: LGPD
• India: DPDP Act 2023

Design rule: anonymised aggregated reports are the baseline. No raw PII leaves the network perimeter. Cohort minimum size = 1000 (below which data is suppressed).

Relationship to The Geek Network

DataAcuity is NOT a separate company. It is a B2B product surface of The Geek Network.

• Branded separately (DataAcuity, not "The Geek Network BI")
• But powered entirely by TGN infrastructure
• Revenue flows to the Bengu Group via the holding structure (see CONFIDENTIAL doc)
• Users of the ecosystem are never sold to. Their consented data earns them Qi. The aggregate insights are sold to third parties. This is the ethical framing: transparent, compensated, consented.

Public-safe messaging for thegeek.co.za /offerings/data-acuity

See AppInfo/TheGeek/TheGeek_Offerings_Pages.md for the actual page copy.

Key message: "Enterprise BI built on data that respects people. Every insight is consented. Every contributor is compensated."

Files to create in next session

• Define event schema per app (in AppInfo/DataAcuity/event-schemas/)
• Define anonymisation rules (AppInfo/DataAcuity/DataAcuity_Anonymisation.md)
• Define Pro API endpoint list (AppInfo/DataAcuity/DataAcuity_API_Spec.md)
• Define Wolverine SaaS product surface (AppInfo/DataAcuity/Wolverine_SaaS_Spec.md)
• Create AppInfo/DataAcuity-store/metadata.json if DataAcuity gets its own web property