Because the domain is undefined. Constraints, specifications, and requirements are missing. The model is not the problem. The missing domain requirements and specifications and boundaries are.

Cognitive bias, in all its forms. Closely followed by semantic traps. It fills gaps in domain definition, creates assumptions that become invisible, and drives projects into exploration spirals and un-deployable notebooks.

They distort the problem definition before any Data Science occurs. Semantic traps misalign meaning. Data traps misalign structure. Cognitive bias misaligns assumptions. Together, they create a domain that is undefined, inconsistent, and unengineered. Guaranteeing failure before development begins and long before an ML model is ever built.

Scope of work in a proposal does not capture these failure modes and never can. Proposals describe deliverables, not domain traps. They assume alignment, clarity, and constraint where none exist. This is why projects drift, expand, stall, and collapse into exploration spirals and un-deployable notebooks. The Nimmo Analytics structured workflow is designed to eliminate these failure modes by engineering the domain first.

Cognitive bias is the human tendency to fill domain gaps with assumptions. In mining data science, cognitive bias is the most common failure mode. It shapes the problem space before any engineering occurs.

A semantic trap is when domain terms are used inconsistently or assumed to mean the same thing across geology, geomet, and engineering. They create false alignment, hide contradictions, and cause models to encode the wrong logic.

Data traps are patterns that appear meaningful but are artifacts of sampling, blending, plant response, or operational noise. They create false confidence and lead models toward incorrect structure.

ML black-boxes fail because they ignore domain constraints. Opacity is not the issue. Missing workflow design and engineering is.

No.
We use black-boxes all the time from driving a car or using electronics. To us they are black-boxes. To the design engineers they are not. You shouldn't fear an ML black-box. Rely on the Data Science experts. What you should fear is what you don't have: the domain definition, constraints, and requirements (the boundaries) that make models work.

Signs include: repeated scope changes, stakeholder disagreement, endless exploratory analysis, poor deployment outcomes, inability to define success criteria.

Mostly yes.
The purpose of structured discovery is identifying them before development begins.

The structured workflow is based on the CRISP-DM process model and the Software Development Life Cycle (SDLC). It is strongly aligned with the 7 D's of SDLC but simplified to just 4 D's. The general process involves:

Each project is different and each structured workflow may also be slightly different but the overall flow is the same. Where thinking (1D+2D) always proceeds the doing (3D+4D). Where the domain definition is more important than the model.

Another structured process that is used is centered around asking questions:

Models only work when the domain is engineered. Without constraints, specifications, and acceptance criteria, the model encodes bias, traps, and assumptions instead of reality.

The Define and Design deliverables include: requirements definition and specifications documents. The content of these documents will vary project to project.

Requirements may include project definition, problem statement and definition, project goals, data requirements, project roadmap, risk register and contingencies, output requirements and format, delivery format (CLI or report), domain boundaries (scope), funcitonal requirements, non-functional requirements, success metrics, timeline, milestones, and project deliverables.

Specifications may include assumptions, data quality, evaluation metrics, acceptance tests and criteria, testing framework, data flows and step-by-step workflows, technical constraints, edge cases, model selection and rationale, open questions.

When all acceptance tests are complete and all other tests pass the product is considered ready for delivery. The Deliverables may include: project documentation, project artifacts, and the specified product. The product could be the project report, but may also include a command line interface (CLI) tool and or the model in the specified output format.

Sometimes the best outcome is identifying that additional data, revised requirements, or a different approach is needed before development. Other times a solution maybe identified early during data exploration and ML is not required.

The Nimmo Analytics can use an optional encoder-decoder workflow that allows raw data to stay on-site. Client data is encoded and transformed into a fully obfuscated internal representation (IR) on-site. Only the IR leaves the client environment. Nimmo Analytics works exclusively on the IR and never sees decoded data. Without the client-side decoder, the IR cannot be reverse-engineered.

The IR is a generative representation of engineered relationships, constraints, and structure, not raw operational data. It utilizes existing techniques to mask site specific data through data embedding, data encoding, data transformations, hashing techniques, and addition of noise. It is produced on-site by the encoder and cannot be reverse-engineered without the on-site decoder. The IR is a facsimile of the data that retains the statistical properties and data relationships needed by machine learning (ML) without exposing site-specific features. It also includes generative models that allow constructing synthetic data for ML without leaking sensitive information.

As we know, ML models can be trained using raw data or synthetic data and the model is equally as good either way. We exploit this feature to ensure security of the data.

No.
The encoding and decoding process can be done using simple command line tools (CLI). The tools are designed to generate the internal representation and store as accessible text files (JSON). The tools do not connect to the web. They do not transfer any data or information to an external server. No API or subscriptions is required.

Yes.
Once the data is encoded into the internal representation (IR) any of the Nimmo Analytics existing workflows can be used on the IR. If the data changes then a new IR is built and the existing workflow that was previously built can be used as is. Unless the project requirements and specifications change. If these change then the existing workflow will need updating.

I can work either directly with the raw data or use a process that encodes your data into an internal representation (IR). The required data or outputs from the encoding process will be identified during the project discovery (requirements and specifications) phase. If using the IR encoding for data security, then the encoded information will be required.

Yes.
Any tabular data can be included in the study.