D3Square
AI-ready data from day one of experiment design. Pull scattered computational and experimental records into one place — and turn them into decision-making assets.
- Collect AI-ready data starting from experiment design
- A virtual lab that captures everyday experimental runs by design
- Local LLM analysis — your data never leaves the building
- Inverse design and active learning suggest the next experiment
Stop postponing the data problem
- One place
- Unified experiments, simulations, literature
- AI-ready
- Model-trainable from the start
- On-prem
- Data sovereignty preserved
- Reverse
- From data to the next experiment
Research data is still scattered everywhere
Experimental results spread across spreadsheets, local drives, and email. Findings locked inside PDF tables and figures. The same property named three different ways by three different groups.
Fragmented data
Experimental records scattered across tools, formats, and individual team members.
Repeated experiments
The same conditions run again and again, because nothing guides the next one.
Disconnected analysis
Collection, modelling, and optimisation each live in a separate environment.
Knowledge locked in papers
Published results stay trapped in tables and figures nobody has time to transcribe.
Inconsistent terminology
Every group names the same property differently and writes its units its own way.
Precision tools for every stage
A three-stage pipeline — collect, preprocess, train — with a knowledge graph, inverse design, and a context-aware assistant running alongside it.
Literature extraction
Register a paper by PDF, DOI, or PubMed ID — or subscribe to a journal and let new articles arrive on their own. D3Square reads the full text, then renders table and figure pages as high-resolution images so a vision model can read the numbers a text parser silently mangles.
- Crossref and PubMed search, DOI import, scheduled journal feeds
- Summary, key findings, entities, relations, and table data
- Vision extraction at 200 DPI for tables, plots, and spectra
- Every value carries its source page for one-click verification
- Map extracted values straight into a data bucket column
Ontology
Two labs measure the same property and the data still will not merge — different names, different units. Ontology concepts pull those variants together, normalise units to SI, and quarantine out-of-spec values before they reach your training set.
- Concepts with synonyms, units, definitions, and hierarchy
- Unit parsing and SI conversion, recorded with QUDT identifiers
- New concepts and constraints go through review and approval
- OWL reasoning derives implied relations, each keeping its evidence
- TTL import/export and EMMO snapshot diffing for interoperability
Knowledge graph
The entities and relations pulled out of your literature land in a graph you can actually look at. Filter by type, follow a relation, hand the result to the assistant — or send the selection straight to a training bucket.
- Entities typed as material, property, method, journal, author, and more
- Filter by type, hide isolated nodes, expand by hops
- Ask the assistant and get answers grounded in the graph
- Export a graph selection to a data bucket for training
- Results respect data permissions — no access, no evidence
Data buckets
Upload experimental datasets and validate them automatically. Missing values, categorical encoding, and outlier detection are handled in a single preprocessing pipeline.
- Automated validation and error detection on upload
- Missing-value and outlier preprocessing
- Correlation analysis and visualisation
- Version control with history restoration
Model training
Train models straight from a bucket without writing code. Compare runs on R², MAE, and RMSE, then read what the model actually learned — the platform writes the interpretation out in plain language, cautions included.
- No-code training: GPR, XGBoost, linear models, deep learning
- Cross-validation and side-by-side comparison on R² · MAE · RMSE
- SHAP feature importance, with the top drivers called out
- Plain-language result report: summary, key findings, cautions
- Publish to the prediction tab, ready for prediction and inverse design
Inverse design
Define the target properties first and let published models work back to the composition and process conditions that meet them. Five steps — import a model, map its roles, set the design variables, search, run.
- Single and multi-objective runs on published models
- Genetic algorithm, Bayesian optimisation, grid and random search
- A Pareto front proposes the candidates worth making
- Constraint-bounded exploration of the design space
- Sessions, runs, and results kept per project
Active learning
Recommend the samples worth measuring next. Maximise information gain with the fewest experiments, cutting research cost and time.
- Expected Improvement and UCB acquisition strategies
- Thompson-sampling-based recommendation
- Iterative model refinement cycles
- Experimental cost kept to a minimum
AI assistant
The assistant knows which page you are on. On a training run it offers to compare performance; on the knowledge graph it answers from the graph; on the dashboard it tells you what moved. Ask it to do the work and it operates the platform for you.
- Page-context aware — proposes the next step for the screen you are on
- Hybrid retrieval: vector search over documents plus graph traversal
- Runs platform actions: buckets, training, models, inverse design, CAE, DOE
- Multilingual questions searched in both the original and translated form
- Answers scoped to what your account is allowed to see
Not a generic data tool. An R&D operating platform.
Experiments, inventory, literature, properties, and process conditions are handled in context — not as anonymous columns in a spreadsheet. The difference is not any single feature. It is the loop: data, knowledge, and models reinforcing one another.
End-to-end connection
Collection, analysis, learning, prediction, and inverse design are one platform, not five tools stitched together.
Built for materials R&D
Experiments, inventory, literature, properties, and process conditions are first-class objects with the right fields and units.
Explainable AI
Performance metrics, the variables that drove them, and the caveats worth knowing — written out in plain language.
Knowledge and models you reuse
Structured literature knowledge and trained models become the starting point for the next project instead of one-off artefacts.
Every research input, in one place
Lab setup, inventory, experiment design, and literature are captured in one connected workflow, then grouped into buckets the team can version, share, and train on.
Lab setup
Standardise locations, equipment, protocols, and analysis templates once, and every later record inherits that structure.
Inventory
Track quantity and history for raw materials, mixtures, and specimens.
Experiments
Design experiments as connected nodes, then record what actually happened against that design.
Literature
Gather papers, read them in place, and turn highlights into structured data.
Permission-scoped buckets
Data is shared on purpose. What a user cannot open is also excluded from graph queries and AI answers.
Versioned team assets
Buckets keep their history, so a dataset used for training can be restored and re-checked later.
API and LIMS integration
Connect the lab systems you already run, so collection keeps going without anyone re-typing it.
From data to a decision
Collection, training and inverse design are four segments of one loop rather than separate projects. The whole design is that each segment leaves its result in the shape the next one needs.
What "AI-ready" actually demands
What blocks model training is usually the shape of the data, not the amount of it. If each researcher names the same material differently, if equipment conditions go unrecorded, if failed runs are never written down, no volume of records will train anything. D3Square has you define materials, equipment, equipment variables and research templates first, so that recording an experiment is already recording a structured row. The disappearance of a cleanup step is a consequence of that, not a feature bolted on afterwards.
Training and validating predictive models
Accumulated data trains property-prediction models, and models are compared side by side on the same screen. What matters is not the point estimate but the uncertainty — knowing which composition ranges the model is unsure about is what tells you where an experiment is worth spending. Which variables drive the outcome surfaces along the way, so the model doubles as a summary of the phenomenon.
Inverse design — from target to composition
The usual calculation takes a composition and returns a property. Inverse design runs the other way: it takes a target property range as the constraint and searches for compositions and process conditions likely to satisfy it. Candidates come back ranked, each carrying how confident the model is about it.
Active learning — choosing the next experiment
When the number of experiments is limited, which one to run next for the most information gained is itself a calculable question. Active learning balances candidates that look good against candidates the model understands least, recommends the next experiment, and closes the loop as that result returns as data.
Why the data stays inside
The LLM used for analysis runs inside your organisation. On an on-premises deployment, the core of your R&D — compositions, process conditions, records of what failed — is never transmitted to an external cloud, and analysis and training proceed with data sovereignty intact.
How it meets the tools you already use
Nothing requires abandoning the spreadsheets, output files and literature notes a team already keeps. Mapping the fields of those existing records onto templates while defining the lab puts past and future data into one workspace with the same structure. Data not leaving with the person who produced it is why university groups use this for handover.
From lab bench to optimal design
Set the lab up once, and from the next cycle on the data accumulates and the models grow on their own.
-
01
Import literature
Bring in papers by PDF, DOI, or journal feed. Text, tables, and figures come out with their source pages attached.
-
02
Standardise
Match extracted terms to ontology concepts, normalise units to SI, and quarantine values that break the rules.
-
03
Collect data
Upload experimental datasets into buckets, with validation and preprocessing applied automatically.
-
04
Explore and analyse
Run correlation analysis, scatter plots, and distribution checks to understand the structure of what you have.
-
05
Train models
Compare several algorithms and pick the best predictive model for your target properties.
-
06
Deploy and predict
Publish validated models and use them to predict outcomes for new experimental conditions.
-
07
Optimise
Run multi-objective optimisation to find the design parameter combinations worth trying.
What changes once the platform is in place
| Area | Before | With D3Square |
|---|---|---|
| Data management | Files on personal PCs, spreadsheets, and disconnected systems. | Experiments, literature, and analysis records accumulating on one platform. |
| Use of literature | Insight leaves with the project — and with the person. | A knowledge graph structured by domain ontology, queryable by anyone. |
| Model training | Specialists write code in separate environments. | No-code training with a plain-language interpretation the whole team can read. |
| Finding candidates | Conditions found by running the experiment again, and again. | Target properties drive inverse design, which proposes the conditions. |
Where it is used
Korean government research institute
Alloy composition design — using D3Square for experimental data integration and inverse-design workflows.
Korean enterprise R&D
A secondary-battery materials team accumulating composition and process data, and grounding decisions in it.
Universities (multiple)
Various labs using D3Square for lab-level data asset-building and smoother handover between students.
Built for diverse research fields
- Materials science
- Chemical processes
- Manufacturing quality control
- Energy research
D3Square — frequently asked questions
What problem does D3Square solve?
Research data scattered across researchers and projects, and never reused. D3Square collects it in an AI-ready form from the experiment design stage onward, so model training and inverse design continue in the same place.
Can we bring in the experimental data we already have?
Define your materials, equipment, equipment variables and research templates once, and existing records accumulate in the same structure as new ones. Simulation results and literature data are unified into the same workspace.
Does sensitive R&D data leave our organisation?
Analysis runs on an LLM operated inside your organisation, so data is never sent to an external cloud. An on-premises deployment keeps data sovereignty intact.
How is it different from Materials Square?
Materials Square is where simulations run; D3Square is where experimental, computational and literature data accumulate and decide the next experiment. Results become assets in D3Square, and inverse design and active learning propose what to calculate next.
How do we get started?
Tell us the shape your data is in today and what your R&D is aiming at, and we will map out where to start collecting. Begin with a PoC consultation.
Data scattered everywhere becomes an asset when it comes together.
Tell us where your data lives today and what your R&D goal is. We will map out where to start collecting.