Skip to main content
FromNine
Menu

AI & data

Figures your board, your analysts and your AI can all rely on.

We engineer data platforms in which each dataset has a named owner, a written contract and measured quality. Finance, operations and AI teams then work from one set of trusted figures instead of three.

For Malaysian organisations whose figures sit in several systems and companies, and whose personal data must follow Malaysia’s amended data protection law.

Arrange a discussionEnterprise knowledge
Data & Analytics: the four layersFour layers, read downwards: reporting and AI use the data; owned data products with contracts supply it; lakehouse layers clean and align it; and governance with lineage covers every layer.01Reporting and AI consumers02Owned data products03Lakehouse zones04Governance and lineage
  1. 01A named owner, a written contract and automated tests behind every data product
  2. 02Purpose and retention rules of the Personal Data Protection Act 2010 (Act 709) applied as platform settings, not kept in a policy binder
  3. 03KPI definitions signed jointly by the business and IT, used everywhere

01 Common problems

Data problems most organisations recognise

When an AI project disappoints, the cause usually sits in the data underneath it.

  1. 01

    Finance, operations and the board quote different numbers

    Each team computes revenue or volumes its own way. Management meetings open with an hour of reconciliation before any decision is taken.

  2. 02

    Errors return because no one owns the dataset

    Someone downstream spots a mistake, patches it in a spreadsheet, and the same mistake reappears in next month’s extract.

  3. 03

    Your data scientists mostly search for data

    Each new use case opens with access requests, one-off extracts and cleaning, all of which the next team repeats from scratch.

  4. 04

    Scanned archives are useless to AI

    Poorly recognised scans, duplicate files and missing metadata. Search over such an archive returns clutter rather than answers.

02 Scope of the service

What the service covers

  1. 01 Foundations for reporting and AI

    A lakehouse organised in zones, from data as received to aligned data to data ready for use. Each data product states its content, its freshness and the person who answers for it.

    Activities

    • Platform blueprint and storage format decisions
    • Modelling conventions for each zone
    • Data products designed around written contracts
    • Batch loads and change data capture from source systems

    What you would receive

    • A lakehouse platform described entirely in code
    • Initial data products serving real users
    • A contract template with a review routine

  2. 02 Quality, lineage and master data

    Automated quality tests in every zone, lineage traced from source field to report, and master and reference data for the entities your organisation depends on: customers, students, products and assets.

    Activities

    • Quality rules with thresholds that raise alerts
    • Lineage captured down to individual columns
    • Rules deciding which duplicate record wins
    • Maintenance of reference data

    What you would receive

    • A quality dashboard for every data product
    • Lineage that analysts can query
    • Single trusted records for the priority entities

  3. 03 Governance the platform enforces

    Catalogue, classification and access policies applied by the platform itself. Personal data is tagged with the purposes notified to data subjects, so the Personal Data Protection Act 2010 (Act 709), the PDPA, is respected through settings: access follows purpose, and records are deleted when the retention period ends. For EU group companies, the GDPR rules are encoded the same way.

    Activities

    • A classification scheme and tagging of datasets
    • Access policies based on attributes and purpose
    • Automated retention and deletion
    • Sharing agreements enforced by technical controls

    What you would receive

    • A catalogue filled automatically by the platform
    • Access policies written as code
    • A retention schedule that runs by itself

  4. 04 Documents and scans prepared for AI

    Cleaner text recognition, fuller metadata, fewer duplicates and an orderly archive give document intelligence and search something worth retrieving.

    Activities

    • An inventory of content with sampled quality checks
    • Improved text recognition and layout extraction
    • Detection of near-identical files
    • Enrichment and classification of metadata

    What you would receive

    • A cleaned and enriched content store
    • A report on content quality
    • Rules for any content added later

  5. 05 Reporting that replaces the spreadsheet

    One semantic layer carries the KPI definitions agreed between business and IT. Self-service stays within guardrails, and analytics can sit inside the SaaS products and portals you offer customers.

    Activities

    • Workshops to define each KPI
    • Semantic model plus a layer of shared metrics
    • Certified datasets and limits on self-service
    • Analytics embedded in products used by customers

    What you would receive

    • KPI glossary listing who owns each entry
    • A certified semantic model
    • Dashboards that make the monthly spreadsheet unnecessary

  6. 06 Streaming for decisions that cannot wait

    Change data capture and event streams for figures that are needed within minutes rather than after the overnight load: stock positions, case status, signs of fraud.

    Activities

    • Latency needs agreed for each use case
    • Change data capture from operational databases
    • Stream processing and materialised views
    • A design for replay and back-filling

    What you would receive

    • Streaming pipelines running in production
    • Operational views with freshness targets
    • A documented replay procedure

03 Architecture

A reference architecture, for illustration

Operational systems and documents are loaded into a lakehouse with three zones: data exactly as received, then data aligned and quality-tested, then data products that carry an owner and a contract. No consumer reads the first zone.

Data products feed the semantic layer and its dashboards on one side, and AI retrieval, model features and data APIs on the other. Governance sits beneath everything, enforced by the platform rather than described in a policy manual.

Illustrative example

  1. Sources and loading

    • Operational systems
    • Documents after text recognition
    • Batch loads and change capture

  2. Lakehouse

    • Raw zone
    • Aligned zone
    • Quality tests and lineage
    • Master and reference data
    • Data products under contract

  3. Use

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

  4. Governance

    • Governance: catalogue, classification, access by purpose, retention
Lakehouse zones feeding owned data products

For illustration only; this is not a system built for a client.

Read the diagram as text

Data flows from operational systems into ingestion by batch and change data capture, then into a raw zone, an aligned zone and the data products, and from there into a semantic layer serving governed dashboards.

Documents enter ingestion after text recognition and enrichment. Quality tests and lineage watch the raw and aligned zones. Master and reference data feed the data products, which also serve AI retrieval and features, and data APIs for sharing.

Across the bottom of the platform runs governance: catalogue, classification, access policies and retention.

04 Trade-offs and limits

Trade-offs we plan for

  • Owners first, tools second

    What we do about it

    Every data product receives two owners: someone in the business who decides what the figures mean, and someone technical who keeps them flowing. We help you describe both roles and the contract that binds producers to consumers.

    Limits and prerequisites

    Software cannot appoint owners. If nobody accepts the role, quality issues come back, however good the platform is.

  • Purpose and retention under the PDPA

    What we do about it

    Personal data carries tags for the purposes it may be used for, and access and retention follow those tags without manual steps. Since 1 June 2025, under the Commissioner’s guidance, a data controller must appoint a data protection officer (DPO) when it processes personal data of more than 20,000 data subjects, sensitive personal data including financial information of more than 10,000 data subjects, or carries out regular and systematic monitoring. The platform gives that DPO the records to work from.

    Limits and prerequisites

    Which purposes are lawful, and whether a DPO is required, is for your DPO and counsel to decide. We build what they decide; the decision is not ours.

  • AI sets its own bar for data

    What we do about it

    For AI work we measure the properties retrieval and models depend on: coverage, freshness, duplication and how well text was extracted.

    Limits and prerequisites

    Certain archives cost more to repair than they are worth. A sampled assessment shows this, and occasionally the sensible choice is to exclude them.

05 Working method

Our working method

The first data products that matter shape the platform; the platform does not come first and wait for them.

  1. 01

    Begin with decisions

    Choose two or three decisions or AI use cases, list the data behind them and name who owns it.

    ResultOwned backlog of data products

  2. 02

    Lay the foundation they need

    Platform, loading, tests and governance, built only as far as those first products require.

    ResultFirst data products in production

  3. 03

    Add one product at a time

    New products reuse what exists; the catalogue and KPI glossary expand with each one.

    ResultProduct roadmap and usage figures

06 Human oversight

Where decisions stay with people

Pipelines copy, transform and test data unattended. Meaning, access and purpose remain human decisions.

  • Definitions change only with approval

    A KPI or data product takes on a new meaning only after its business owner approves, and each change receives a version.

  • Owners grant access

    Who may read which data, and why, is the data owner’s call. The platform enforces that call and logs each grant it makes.

  • A failed check halts publication

    If a contract test fails, consumers are told at once, and the owner chooses to publish, hold back or correct.

07 Technology

Technology we use

Platforms
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Apache Iceberg or Delta Lake as an open lakehouse
Pipelines
  • dbt
  • Apache Spark
  • Kafka and Debezium
  • Orchestration services native to your cloud
Governance
  • Unity Catalog and Purview
  • Open-source catalogues
  • Frameworks for data quality testing
  • Access control driven by policy
Analytics
  • Power BI
  • Semantic and metrics layers
  • Analytics embedded in products
  • SAP analytics within existing landscapes

These names reflect hands-on engineering work. Their inclusion does not mean that a vendor partners with or endorses FromNine.

08 Scenario

An illustrative scenario

Illustrative example

A student data platform for a private university group

01Starting point
A private university group keeps student records in separate admission, finance and learning systems on each campus. Reports disagree, and nobody can say how long former students’ data is kept or for what purpose.
02What we would deliver
Aligned data products for applicants, students and alumni, each field tagged with the purpose notified under the PDPA and a retention period, feeding one semantic layer for group reporting.
03Decisions that stay with people
The registrar approves definitions and changes; the data protection officer approves purpose tags and retention periods before they take effect.
04How results would be tracked
Time to produce the semester report, records past their retention period still held, and use of certified dashboards.

09 By industry

By industry

  • Healthcare & Life Sciences

    Patient and research data in private hospital groups and pharmaceutical firms, handled as sensitive personal data with strict purpose rules, pseudonymisation and logged access.

  • Manufacturing & Industry

    Product and asset master data joined with quality and production records, ready for planning, traceability and AI on the factory floor.

  • Public Sector & Government

    Reporting for federal agencies and statutory bodies that auditors and policy officers can trace back to the source record.

Malaysia

Purpose, retention and the amended PDPA

Act A1727 amended the Personal Data Protection Act 2010 (Act 709), and its changes came into operation in three stages during 2025. Since 1 April 2025 the Act speaks of a data controller rather than a data user, and processors are bound by the Security Principle. Since 1 June 2025 qualifying controllers appoint a data protection officer and notify personal data breaches to the Personal Data Protection Commissioner, and data subjects may ask for their data to be ported to another controller where this is technically feasible.

A data platform makes these duties practical or painful. We put purpose, retention period and hosting location into each data product’s contract, so the platform applies them automatically. Where companies in your group sit in the EU, the GDPR and the Data Act are handled in the same contracts, without a second copy of the data.

Questions on data and analytics

Does our organisation need a data mesh?

You need its most useful idea: data products with owners and contracts. Full decentralisation suits large organisations whose domain teams are already mature. Most do better with one central platform team and data products owned by the business domains.

How ready is our data for AI?

A short assessment, based on samples from the sources a use case would read, gives the answer: coverage, quality, access rights and the purpose for which personal data was collected. Expect “partly”, along with a ranked list of fixes. Our AI engineering teams rely on the same assessment.

Our data warehouse works. Must we replace it?

Seldom. A warehouse that produces trusted reports is worth keeping. We usually add lakehouse capability for documents and large volumes, and migrate only where cost or technical limits make it worthwhile.

Can data be shared with partners or group companies?

Through data products offered over governed APIs, with agreements, purpose rules and logging in place. Transfers of personal data out of Malaysia follow section 129 of the PDPA, and where EU companies in your group fall under the Data Act or the Data Governance Act, we build the controls those acts call for.

Which decision does today’s data not support?

Starting from that decision, we will trace its data to the source systems and sketch the first data product it calls for.

Arrange a discussionDocument intelligence