Skip to main content
FromNine
Menu

AI & data

Numbers your AI and your board can both trust.

We set up data platforms in which each dataset has a named owner, an agreed contract and a measured level of quality, so reporting, day-to-day operations and AI work from one reliable source.

For Irish organisations, and Irish operations of international groups, that need one dependable view of data held in many systems.

Talk to us about your projectExplore enterprise knowledge
Data & Analytics: the four layersA stack of four layers. At the top, reporting and AI that use the data; beneath them, data products with owners and contracts; then the lakehouse layers that clean and align the data; and governance running underneath the whole stack.01Reporting and AI02Owned data products03Lakehouse zones04Governance and lineage
  1. 01Each data product has a named owner, a contract and automatic quality checks
  2. 02Purpose limits and retention periods applied by the platform, not just listed in a catalogue
  3. 03KPI definitions agreed once and signed by both the business and IT

01 Problems

Data problems you will recognise

When an AI project falls short, the cause is usually the data underneath it.

  1. 01

    Every report gives a different figure

    Finance, operations and the board each count turnover or open cases in their own way, so meetings begin with arguing over the number rather than acting on it.

  2. 02

    Data without an owner never gets fixed

    Mistakes surface further down the line, get patched in a spreadsheet, and turn up again the following month.

  3. 03

    Your AI team is mostly hunting for data

    Each new use case opens with weeks spent requesting access, exporting and cleaning, and the team after them will do it all over again.

  4. 04

    AI cannot make sense of the archive

    Scans with weak OCR, copies of copies and no metadata. Search across that content mostly brings back clutter.

02 Delivery ledger

What you get from us

  1. 01 The data groundwork for analytics and AI

    Lakehouse designs modelled in zones, from data as it lands to aligned data to data ready for use, and data products that state their contents, their freshness and who is accountable for them.

    What we do

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

    What you receive

    • Lakehouse platform set up in code
    • First data products live
    • Contract template and a review routine

  2. 02 Data quality, lineage and master data

    Quality checks that run automatically in each zone, lineage traced from the source system to the report, and master and reference data for the things you manage: residents, customers, products and assets.

    What we do

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

    What you receive

    • Quality dashboard for each data product
    • Lineage you can search
    • Golden records for the key entities

  3. 03 Governance the platform enforces

    Catalogue, classification and access rules that the platform applies by itself. Purpose limits and retention under the GDPR and the Data Protection Act 2018 are built in, and sharing respects the Data Governance Act wherever it is relevant.

    What we do

    • Classification scheme and tags
    • Access rules based on attributes
    • Automated retention and deletion
    • Sharing agreements backed by technical controls

    What you receive

    • Catalogue filled from the platform itself
    • Access rules held as code
    • Retention schedule that actually runs

  4. 04 Documents and archives prepared for AI

    Better OCR, richer metadata, duplicate removal and archive tidy-up, so that document intelligence and search begin with content worth finding.

    What we do

    • Inventory of content and sample checks on quality
    • Improved OCR and layout extraction
    • Spotting near-identical documents
    • Adding metadata and classifying content

    What you receive

    • Tidied content store with richer metadata
    • Report on content quality
    • Rules for every new document from here on

  5. 05 Reporting and BI that gets used

    A semantic layer holding KPI definitions that the business and IT have agreed, self-service within guardrails, and analytics built into SaaS products and portals.

    What we do

    • Workshops to agree KPI definitions
    • Semantic model and metrics layer
    • Guardrails for self-service and certified datasets
    • Analytics embedded in products your customers use

    What you receive

    • KPI glossary, each entry with an owner
    • Certified semantic model
    • Dashboards in place of spreadsheets

  6. 06 Real-time data for operations

    Change data capture and event streams for decisions that cannot be left until the overnight load: stock on hand, the status of a case, signs of fraud.

    What we do

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

    What you receive

    • Streaming pipelines live
    • Operational views with freshness targets
    • Procedure for replaying data

03 Architecture

Reference architecture, for illustration

Records from business systems and documents are loaded into a lakehouse in zones: first exactly as received, next aligned and checked for quality, and last as data products that carry an owner and a contract. No consumer reads from the first zone.

Data products then feed several routes: one into the semantic layer and BI, others into AI retrieval and features, and into data APIs for other systems. Governance lies beneath everything, and the platform applies it, rather than a policy document on a shared drive.

Illustrative example

  1. Sources and loading

    • Business systems
    • Documents after OCR and enrichment
    • Batch loads and change capture

  2. Lakehouse

    • Landing zone
    • Aligned zone
    • Quality checks and lineage
    • Master and reference data
    • Data products under contract

  3. Use

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

  4. Governance

    • Governance: catalogue, classification, access rules, retention
From lakehouse zones to owned data products

An illustration, not a client’s system.

Read the diagram as text

The main path starts at business systems, passes through loading by batch and change data capture, then a landing zone, an aligned zone and data products, and ends at a semantic layer with governed BI.

Documents enter the same loading step once OCR and enrichment are done. Quality checks and lineage cover the landing and aligned zones. Master and reference data flow into the data products, which also supply AI retrieval and features and data APIs for sharing.

A governance band, holding the catalogue, classification, access rules and retention, runs across the platform.

04 Considerations and limits

What to weigh up, and where the limits are

  • Owners come before tools

    How we handle it

    Every data product has two owners: someone in the business who settles what it means, and someone technical who keeps it working. We help you describe both roles and the agreement between the teams that supply data and the teams that use it.

    Limits and dependencies

    No platform can create ownership. If nobody is given the role, the quality issues will come back, whichever tools you buy.

  • Purpose limits, applied day to day

    How we handle it

    Personal data carries tags for the purposes it may be used for, and access and retention follow those tags without manual work.

    Limits and dependencies

    Deciding which purposes are lawful falls to your data protection officer and your legal advisers, with the DPC’s guidance in view. We build what they decide.

  • AI sets a different quality bar

    How we handle it

    For AI use cases we measure what search and models depend on: how complete the content is, how current, how much is duplicated and how well the text was extracted.

    Limits and dependencies

    Not every archive deserves the effort. A check on a sample will show it, and leaving an archive out is sometimes the sensible call.

05 How we work

How we work

The platform grows out of the first data products that count, not the reverse.

  1. 01

    Start from decisions

    Choose a small number of decisions or AI use cases, list the data they depend on, and name the owners.

    OutputBacklog of data products, each with an owner

  2. 02

    Lay the base around them

    Platform, loading, quality checks and governance, only as much as those first products need.

    OutputFirst data products live

  3. 03

    Expand one product at a time

    Each further product reuses the base, and the catalogue and KPI glossary grow alongside.

    OutputProduct roadmap and usage figures

06 Human control

Where your people keep control

The platform moves and checks the data automatically. Meaning, access and purpose are decided by people.

  • Definitions change with owner approval

    The meaning of a KPI or data product changes only once its business owner agrees, and each version is kept.

  • Data owners grant access

    The owner decides who may use which data and for what; the platform enforces that and records each grant.

  • A failed check halts publication

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

07 Technologies

Technology we use

Platforms
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Open lakehouse with Apache Iceberg or Delta Lake
Pipelines
  • dbt
  • Apache Spark
  • Kafka and Debezium
  • Native cloud orchestration
Governance
  • Unity Catalog and Purview
  • Open-source data catalogues
  • Frameworks for data quality
  • Access control driven by policy
Analytics
  • Power BI
  • Semantic and metrics layers
  • Analytics inside products
  • SAP analytics (where already in place)

A technology on this list reflects hands-on engineering work. It does not mean the vendor partners with us or endorses us.

08 Example

An example, for illustration

Illustrative example

VAT reporting data prepared for a large corporate ahead of November 2028

01The situation
A large corporate expects to issue domestic B2B e-invoices and report the data to Revenue from November 2028. Customer master data, VAT codes and product data sit in three ERP instances and do not agree with each other.
02What we would put in place
Aligned data products for customers, products and VAT treatment, with quality rules that block invoice data failing EN 16931 checks and a reconciliation view for the tax team.
03Where staff decide
The head of tax approves VAT code mappings and rule changes; data owners in each business unit correct the records the checks reject.
04How we would judge it
Share of invoice lines passing validation, open master data errors per week, and time spent on the monthly VAT reconciliation.

09 Sector lens

By sector

  • Healthcare & Life Sciences

    Batch and quality data across pharma and medtech sites, and research data used only for its stated purpose, pseudonymised and with every access logged.

  • Manufacturing & Industry

    Master data for products and equipment, linked with quality and production records for planning, traceability and AI.

  • Public Service & Government

    Data drawn from the record that is the official source, reused rather than requested twice, and reports that county councils, State agencies and auditors can follow back to it.

Ireland

Irish data rules, and the VAT data to come

Personal data in Ireland falls under the GDPR and the Data Protection Act 2018, with the Data Protection Commission as supervisor. The EU Data Act adds rights for users over data from connected products and services. Many Irish operations belong to groups whose retention and purpose rules were written elsewhere, and the two sets of rules do not always line up.

Revenue’s published VAT modernisation timeline adds a new data flow: under that plan, large corporates issue EN 16931 e-invoices for domestic B2B sales from 1 November 2028 and report the data to Revenue. That reporting is only as good as the master data and VAT codes behind it.

We write data contracts that fix the permitted location, purpose and retention period for the data, so the platform applies the right rule without keeping separate copies.

Data and analytics: your questions

Should we go for a data mesh?

Take the parts that work: data products with owners and contracts. Handing everything to domain teams makes sense in big organisations whose domains are already mature. Elsewhere, one central platform team, with business domains owning their own products, usually gets you further.

How do we know our data is fit for AI?

Run a brief check on samples from the sources a use case relies on: completeness, quality, who may access it and on what legal basis. Expect the verdict “in part”, together with a ranked list of what to repair first. Our AI engineering teams work from the same check.

We have a data warehouse already. Must we start over?

Seldom. If your warehouse feeds reports people trust, keep it. In most cases we add lakehouse capacity for documents and large volumes beside it, and we move only what cost or technical limits force us to move.

How is data shared with partners or other public bodies?

As data products published through governed APIs, with a written agreement, purpose limits and full logging. If the Data Governance Act or the Data Act applies to the exchange, we build the technical controls it calls for.

Which decision can your data not support today?

We will follow that question back to the source systems and set out what a first data product would involve.

Talk to us about your projectExplore document intelligence