Skip to main content
FromNine
Menu

AI & data

Data your management and your AI can depend on.

We build data platforms in which each dataset has an accountable owner, a written contract and measured quality. Finance, operations, the board pack and AI models then work from one reconciled set of figures.

For Indian groups that need one trusted view of data held across business units, plants, subsidiaries in Europe and older systems.

Share your requirementsEnterprise knowledge
Data & Analytics: the four layersFour layers drawn one behind the other. Top: reporting and AI that use the data. Second: data products, each with an owner and a contract. Third: lakehouse layers that clean and align the data. Bottom: governance covering everything above.01Reporting and AI use02Owned data products03Lakehouse layers04Governance and lineage
  1. 01Each data product has a named owner, a contract and automated quality checks
  2. 02Purpose tags and retention rules applied by the platform, in line with the DPDP Act
  3. 03A single set of KPI definitions approved jointly by business and IT

01 Challenges

Data problems most enterprises recognise

Many disappointing AI initiatives are, on closer inspection, unresolved data work.

  1. 01

    Finance and operations report different figures

    Each function computes sales, collections or backlog in its own way. Review meetings open with reconciliation rather than decisions.

  2. 02

    Data without an owner never gets corrected

    Mistakes surface in a report, are patched in Excel and reappear at the next month-end close.

  3. 03

    Data scientists spend their weeks hunting for data

    Each use case begins with access requests, extracts and cleaning, and the next team repeats the same effort.

  4. 04

    Scanned archives that AI cannot use

    Poor OCR, duplicate files and missing metadata. Search over such content returns mostly noise.

02 Scope of work

Scope of the practice

  1. 01 Data foundations for reporting and AI

    A lakehouse modelled in stages, from data as received to aligned data to data ready for use, and data products that declare their content, their freshness and the person accountable for them.

    Scope of work

    • Platform design and choice of storage formats
    • Modelling conventions for each stage
    • Design of data products and their contracts
    • Batch loads and change data capture

    Deliverables

    • Lakehouse platform defined as code
    • First data products running in production
    • Contract template and a review procedure

  2. 02 Quality, lineage and master data

    Automated checks at each stage, lineage from the source table to the report, and master and reference data for the entities that matter to you: customers, vendors, products, plants and assets.

    Scope of work

    • Quality rules with thresholds and alerts
    • Lineage recorded down to column level
    • Matching and survivorship rules for master data
    • Management of reference data

    Deliverables

    • Quality dashboard for each data product
    • Lineage that can be queried
    • Golden records for the priority entities

  3. 03 Governance applied by the platform

    Catalogue, classification and access policies that the platform enforces automatically. Personal data carries the purpose stated in the notice given to the Data Principal under the DPDP Act, retention follows that purpose, and data from EU users is handled under the GDPR.

    Scope of work

    • Classification scheme and tags
    • Access policies based on attributes
    • Automated retention and erasure
    • Data sharing agreements backed by technical controls

    Deliverables

    • Catalogue filled directly from the platform
    • Access policies written as code
    • Retention schedule running in production

  4. 04 Documents and scans prepared for AI

    Better OCR, richer metadata, removal of duplicates and archive clean-up, so that document intelligence and search start from material that is worth retrieving.

    Scope of work

    • Content inventory with quality sampling
    • Improvements to OCR and layout extraction
    • Detection of near-duplicates
    • Metadata enrichment and classification

    Deliverables

    • Cleaned and enriched document store
    • Report on content quality
    • Rules for content added in future

  5. 05 Reporting and BI that staff open daily

    A semantic layer holding KPI definitions agreed by business and IT, self-service within guardrails, and analytics embedded inside SaaS products and customer portals.

    Scope of work

    • Workshops to define KPIs
    • Semantic model and metrics layer
    • Guardrails and certified datasets for self-service
    • Embedded analytics for customer-facing products

    Deliverables

    • KPI glossary with owners
    • Certified semantic model
    • Dashboards that retire the Excel trackers

  6. 06 Streaming where decisions are urgent

    Change data capture and event streams for cases that cannot wait for the overnight batch: inventory levels, dispatch status, collections and fraud signals.

    Scope of work

    • Latency needs set per use case
    • CDC from transactional databases
    • Stream processing and materialised views
    • Design for replay and backfill

    Deliverables

    • Streaming pipelines in production
    • Operational views with freshness targets
    • Documented replay procedure

03 Architecture

Reference architecture (illustrative)

Records from ERP, core and plant systems and from documents pass through ingestion into a staged lakehouse: first exactly as received, then aligned and quality-checked, then published as data products with an owner and a contract. No consumer reads the raw stage.

Data products feed the semantic layer and BI on one path, and AI retrieval, model features and data APIs for other systems on others. Governance runs beneath the whole platform and is enforced by it, not by a policy PDF.

Illustrative example

  1. Sources and ingestion

    • ERP, core and plant systems
    • Documents after OCR
    • Batch loads and CDC

  2. Lakehouse

    • Raw stage
    • Aligned stage
    • Quality checks and lineage
    • Master and reference data
    • Data products and contracts

  3. Use

    • Semantic layer and BI
    • AI retrieval and features
    • Data APIs for sharing

  4. Governance

    • Governance: catalogue, classes, access, purpose tags, retention
Lakehouse stages feeding owned data products

An illustration only; not drawn from any client system.

Read the diagram as text

The primary path leads from transactional systems through ingestion by batch and change data capture, into a raw stage, an aligned stage and data products, and on to a semantic layer with governed BI.

Documents also enter through ingestion once OCR and enrichment are done. Quality checks and lineage cover the raw and aligned stages. Master and reference data flow into the data products. The data products also supply AI retrieval and model features, and data APIs for sharing.

A governance band spans the platform, holding the catalogue, classification, access policies, purpose tags and retention.

04 Trade-offs and limits

Design trade-offs and limits

  • Owners come before tools

    How we address it

    Every data product has a business owner who defines its meaning and a technical owner who keeps it running. We help you describe both roles and the contract between the teams that produce and consume the data.

    Limits and prerequisites

    Software cannot appoint owners. If no one is made accountable, the same quality issues return regardless of the platform chosen.

  • Purpose limitation, applied in the platform

    How we address it

    Personal data is tagged with the purposes stated in the notice and consent, and access rights and retention periods follow those tags without manual steps.

    Limits and prerequisites

    Deciding which purposes are lawful under the DPDP Act or the GDPR belongs to your data protection officer and legal advisers. We put their decision into effect; we do not make it.

  • AI needs its own quality measures

    How we address it

    For AI use cases we check what search and models depend on: coverage, freshness, duplicates and how well text was extracted from scans.

    Limits and prerequisites

    Some archives do not justify the cost of repair. A sampled assessment shows this, and sometimes the sound decision is to exclude them.

05 Delivery steps

Delivery steps

The platform is shaped around the first data products that count, not built in advance of them.

  1. 01

    Start from decisions

    Select two or three management decisions or AI use cases, identify the data each requires and name the owners.

    OutcomeBacklog of data products with owners

  2. 02

    Lay only the foundations needed

    Platform, ingestion, quality checks and governance, sized to serve those first products well.

    OutcomeFirst data products in production

  3. 03

    Expand one product at a time

    Every new product reuses the foundation, and the catalogue and KPI glossary expand with it.

    OutcomeProduct roadmap and adoption figures

06 Approvals

Who approves what

The platform moves and checks data automatically. People decide what it means, who sees it and for which purpose.

  • Owners approve every definition

    A KPI or data product changes its meaning only after its business owner agrees, and each change is versioned.

  • Policy owners grant access

    Data owners decide who may use which data and for what purpose. The platform enforces the decision and logs each grant.

  • A failed check halts publication

    If a contract check fails, consumers are alerted and the owner chooses to publish, hold back or correct the data.

07 Technology

Technology we use

Platforms
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • An open lakehouse on Apache Iceberg or Delta Lake
Pipelines
  • dbt
  • Apache Spark
  • Kafka and Debezium
  • Orchestration native to your cloud
Governance
  • Unity Catalog and Purview
  • Open-source catalogues
  • Data quality frameworks
  • Policy-based access control
Analytics
  • Power BI
  • Semantic and metrics layers
  • Embedded analytics
  • SAP analytics where already in use

A product listed here reflects our engineering experience with it, not a partnership with or endorsement by its vendor.

08 Scenario

Illustrative scenario

Illustrative example

Plant quality KPIs for an auto component maker with EU customers

01Starting point
Each plant reports rejection rates, rework and on-time dispatch from its own MES and spreadsheets, using its own definitions. Management and the EU customers’ supplier quality teams compare figures that are not measured the same way.
02What we would set up
Aligned data products for each plant feeding one semantic layer, with KPI definitions agreed at group level, plant detail retained and batch traceability available for customer audits.
03Where an officer decides
Plant quality heads approve how their data is mapped; the group quality owner approves KPI definitions and any later change.
04How success would be measured
Days needed to close the monthly quality review, number of reconciliation corrections, and use of the certified dashboards by plant teams.

09 By industry

By industry

  • Healthcare & Life Sciences

    Patient, laboratory and research data at hospital groups and diagnostic chains, governed by purpose under the DPDP Act, with pseudonymisation and a log of every access.

  • Manufacturing & Industry

    Product, plant and quality data brought together for planning, batch traceability for EU customers and AI use at auto component and engineering goods makers.

  • Government & Public Sector

    Scheme and service data for departments and urban local bodies, where records received through API Setu stay distinct from data keyed in by officers and every figure traces back to its record.

India

Personal data under the DPDP Act, and beyond

Under the Digital Personal Data Protection Act, 2023, consent given by a Data Principal covers only the specified purpose set out in the notice. From May 2027 the Data Fiduciary duties in the DPDP Rules apply, including security safeguards, retention limits and breach intimation, and the Rules require personal data, related traffic data and logs to be kept for at least one year (rule 8(3)).

Data from European customers or subsidiaries remains under the GDPR, and the EU Data Act gives users rights over data from connected products. We design data products whose contracts state where data may be processed, for which purposes and for how long, so that the platform applies the right rule to each record without separate copies.

FAQs on data and analytics

Should we adopt a data mesh?

Adopt the parts that pay: data products with owners and contracts. Complete decentralisation suits very large groups whose business units already run capable data teams. Most enterprises are better served by a central platform team with ownership of each product in the business.

How do we know whether our data can support AI?

A brief assessment, on samples from the sources a use case needs, covers coverage, quality, permissions and the lawful ground for any personal data. The usual finding is “partly ready”, with a prioritised list of fixes. Our AI Engineering & GenAI practice works from the same assessment.

Must we replace our current data warehouse?

Seldom. A warehouse that already produces trusted MIS reports is worth keeping. We generally add lakehouse capacity for documents and high-volume data next to it, and migrate only where cost or technical limits make the case.

How is data shared with partners, group companies or regulators?

Through data products published over governed APIs, with agreements, purpose limits and logs in place. Where personal data leaves India, we follow the transfer position your counsel sets under the DPDP Act; where the EU Data Act applies to data from connected products, the technical controls are designed to match.

Tell us which decision today’s data cannot support

We will trace what that decision needs back to its sources and set out what a first data product would involve.

Share your requirementsDocument intelligence