Formulating a Precise Technical Expert Question for IT Matters

A useful expert question does not pre-empt the legal evaluation. It identifies the technical object, time or version, reference criterion and requested finding so that the examination can be performed and later reviewed.

Updated: 22 October 2026 Author: Mathias Ellmann Status: published

Courts & Law Firms

A useful expert question does not pre-empt the legal evaluation. It identifies the technical object, time or version, reference criterion and requested finding so that the examination can be performed and later reviewed.

Short answer

Ask for a technical determination rather than a legal conclusion. Delimit the system and period, state the technical reference where a comparison is required, split complex questions into examinable steps and build the evidence boundary into the wording.

The technically best question is not the broadest one, but the one whose answer can be supported by the available evidence and method. Questions of breach, responsibility and legal consequence remain separate.

1. Ask for a finding rather than a pre-decided evaluation

A question such as whether a contractor breached a contract is not a purely technical expert question. A technical question can ask whether a defined release satisfies an identified technical requirement or whether behaviour is reproducible under specified conditions.

Avoid undefined terms such as error-free, secure or state of the art unless the relevant technical benchmark is specified. Otherwise the requested comparison remains ambiguous.

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

2. Delimit object and time period

Software and cloud systems change. Identify the relevant system state, repository, application, environment or period and state whether the question concerns one event, a recurring pattern or general behaviour.

For historical questions, identify the sources from which the prior state can be reconstructed. If the historical state is not preserved, examinability can itself be limited.

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

3. Name the technical reference criterion

Where a deviation is to be assessed, identify the reference: requirement, specification, test case, manufacturer documentation or defined comparison state.

Selecting the legally controlling standard is not automatically a technical task. The expert can technically compare the observed state against a reference expressly provided for the examination.

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

4. Split multi-part questions into examination steps

Separate state, reproduction, cause, scope and comparison where appropriate. First determine whether the symptom is reproducible, then whether a technical cause can be isolated, and finally whether the finding appears in other versions.

Different sub-questions require different evidence. A missing source for one step should not make the boundaries of the remaining technical questions invisible.

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

5. Build statement limits into the question

Phrases such as “within the repository states provided” or “under the documented test conditions” prevent a bounded evidence set from being treated as universal.

This is especially important for provenance and authorship-related technical analyses. Similarity or repository evidence can support technical relationships without excluding every possible external influence not contained in the evidence.

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

6. Use a robust formulation pattern

A common structure combines object, time, criterion and requested finding: what state existed for the identified system at the relevant time, and how does that state compare with the stated technical reference?

For provenance or history, replace the requirements comparison with a reconstruction question: which versioned or logged artefacts support a technical relationship, and which alternative explanations remain compatible with the preserved data?

The examination separates preserved material, directly observed technical findings, reconstruction and professional inference. Missing historical states or provenance are reported as limitations rather than filled by assumption. A technical expert finding does not decide procedural admissibility, legal responsibility, burden of proof or the court’s evaluation of evidence; those questions remain outside the technical conclusion.

Depth: formulate for technical examinability rather than a pre-judged conclusion

A strong question names object, state, period and observation criterion

Questions become technically testable when they identify the relevant system or artefact, the time or version, the condition to compare and the observable evidence that would support or contradict the proposition.

Exclusions are part of a defensible question

The scope should also state what is not being decided—for example legal liability, intent or a business judgment. Clear exclusions reduce the risk that a technical finding is later treated as a conclusion outside the expert domain.

Methodological separation: The technical finding records what was observed for the documented object, state and conditions. Interpretation explains possible technical meaning; assessment must disclose its criteria and assumptions. The statement boundary identifies what the available evidence does not support. Temporal proximity, a matching label or one successful reproduction must not be treated as automatic proof of a specific cause or a general system property.

Examination checklist

  • Does the question request a technical determination?
  • Are object and relevant time or version delimited?
  • Is the technical reference criterion explicit where needed?
  • Are complex questions split into examinable steps?
  • Is the evidence basis visible in the wording?
  • Are universal or legal conclusions avoided?
  • Can the answer be documented reproducibly?

Constructed example

Instead of asking whether a supplier “delivered defective software,” a question asks whether version 4.2, under the documented test configuration, produces an export structure that differs from a named technical specification and, if so, which reproducible differences are observed. The legal consequence of any deviation remains outside the technical answer.

The example is entirely constructed and does not describe a real engagement, client matter or historical case.

Sources and technical basis

  • Official legal sourceGerman Code of Civil Procedure (ZPO), § 403. Official text relevant to identifying the points to be examined by an expert. Open source.
  • Official legal sourceGerman Code of Civil Procedure (ZPO), § 404a. Official text on judicial direction of expert activity and the factual basis of the examination. Open source.
  • Official legal sourceGerman Code of Civil Procedure (ZPO), § 407a. Official text on further duties of an expert, including clarification of doubts concerning scope. Open source.
  • Methodological basisSources & Methodology documents source hierarchy, counter-hypothesis control and statement boundaries for the English knowledge base.

Further reading

Critical review and methodological limitation

Question wording can predetermine an answer if it embeds disputed assumptions or legal conclusions. A technical formulation should expose the assumptions and make the object, criterion and evidence boundary reviewable.

Where an assignment remains ambiguous, clarifying scope is methodologically stronger than silently expanding it. The resulting technical answer should remain aligned with the defined sub-question and the evidence actually examined.

Author's technical literature and publications

The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.

Mathias Ellmann, IT expert

Technical Expertise for Courts & Law Firms

Neutral technical examination of software, IT projects, data and AI questions in court and legal contexts.

Explore this assessment service
Deutsch