Sources & Methodology

Expert Reports & Methodology

The English knowledge base follows the reviewed German V1 methodology. It does not treat links as evidence by themselves. Technical propositions are connected to sources, versions, examination steps, counter-hypotheses and explicit statement boundaries so that a knowledgeable reader can reconstruct how a conclusion was reached.

Source hierarchy

External factual propositions are supported, where possible, by the source that is closest to the proposition being examined. A Git function is therefore normally supported by Git documentation; a technical standard by the relevant standards source; a protocol property by the applicable specification; and an empirical limitation by suitable scientific evidence. The following hierarchy is a search priority rather than a universal ranking of evidential weight.

• Official or normative primary sources: published legal sources, standards information or documents from competent bodies where they are required for the technical question.
• Technical primary sources: specifications, manufacturer or maintainer documentation, protocol documentation and original documentation of the technologies used.
• Scientific original work: particularly for empirical limits, error rates and the transferability of technical procedures.
• High-quality specialist literature: for context and deeper explanation where an original source does not support the concrete proposition more directly.
• Own published specialist literature: books and professional articles may deepen methods and technical reasoning but do not replace independent evidence for external facts.
• Own expert analysis: the actual technical synthesis arises from the examination question, the available evidence and the documented examination methods.

Unpublished working material

Unpublished manuscripts, drafts, teaching materials and other internal working papers may be used to structure technical questions or develop examination logic. They are not presented as published literature, peer-reviewed work or an independent external source. Where a public factual proposition requires external support, the proposition is traced back to the relevant primary, standards, manufacturer, scientific or other appropriate specialist source.

Source matrix and scientific audit

For each reviewable core proposition, the methodology records which source supports which part of the proposition. A source matrix can contain the proposition or examination question, document title and publisher, relevant section, version or publication status, review date, source type, applicability to the concrete subject and remaining uncertainty. A reachable URL demonstrates only that a source is reachable; content, status and relevance are reviewed separately.

The audit also records counter-hypotheses, missing records, possible conflicts of interest and whether essential examination steps can be reproduced. Project-specific evidence is kept separate from the public source register. A specification can explain how a function is defined, and a study can describe limitations under its experimental conditions, but only the documented technical finding concerns the concrete system under examination. Publication status, version and review date are therefore kept distinct.

Working logic: from diagnosis to expert synthesis

A methodological influence is Nicolai Andler's structured problem-solving approach, including diagnosis, objective definition, analysis and decision-related reasoning. For technical expert work, that structure is selected, condensed and adapted as follows: diagnosis records the technical uncertainty, available material and contradictions; objective definition turns the issue into testable technical questions and statement boundaries; analysis selects methods, examines artefacts, documents findings and tests alternative explanations; expert synthesis brings the findings back to the question, states assumptions and uncertainty, and defines the reach of the conclusion.

From the technical question to the final statement

1. Technical question: what is to be clarified technically?
2. Subject of examination: which system, version, data or documents are actually examined?
3. Examination basis: which records, data, logs and technical artefacts are available?
4. Reference: which documented requirement, specification or comparison basis is used?
5. Method: which procedures are used to investigate the question?
6. Finding: what was observed, measured or documented?
7. Interpretation: what technical meaning can the finding have?
8. Assessment: what professional conclusion is supported against the disclosed reference?
9. Statement boundary: what conclusion is not supported by the available data?

Before detailed examination, working hypotheses and plausible counter-hypotheses are stated where useful. The examiner asks which finding would support the preferred explanation and which would weaken it. This is a practical control against confirmation bias. Missing data, detection limits, measurement uncertainty and possible counter-evidence are part of the result. Where the output depends on a sample, threshold, tool or configuration, sensitivity and robustness are considered. Data states, versions and steps are documented so that a technically qualified person can follow the reasoning.

Finding, interpretation, assessment and statement boundary

A technical finding first describes what was established. Interpretation explains the possible technical meaning of that finding. Assessment identifies the criterion and the assumptions under which the finding supports a professional conclusion. The statement boundary identifies what the evidence does not establish. Keeping these four levels separate prevents observations, assumptions and conclusions from being merged silently.

Technical evidence is not an approval decision

A passed test, measured value, successful build, reproduced function or other technical result establishes the documented technical fact under the stated examination conditions. It does not automatically establish a release approval, deployment recommendation, legal permissibility or complete system suitability. Such decisions require their own criteria, responsibilities and, where applicable, additional professional or legal review.

Version and time context

Technical statements often apply only to a particular state. Where relevant, the examination therefore records the software version, commit or release, data state, configuration and examination date. Sources whose content can change are associated with a review date where that affects the proposition. The number of links is not a quality measure: what matters is whether a concrete source actually supports the concrete technical proposition, whether the version and scope fit the question, and whether counter-evidence and transfer limits remain visible.

Clean-room principle

Third-party websites and competitors can indicate topics or search intent but are not used as text sources for these articles. Wording, tables, figures, characteristic structures and third-party case narratives are not copied. The presentation is developed from primary sources, appropriate specialist sources, the author's own published literature and independent technical analysis. Confidential engagement, customer, quotation and repository data are not used as public examples, metadata or downloads. Anonymisation alone does not replace a separate publication clearance.

Downloads and backlinks

Working templates and checklists are published only after provenance, rights, technical currency, file version, accessibility and confidentiality have been reviewed. A download page must describe its scope and limitations and link back to the relevant technical article; the article must in turn refer to the currently valid template. Until those controls have been completed, working templates remain internal.

Examples and case scenarios

Examples are classified explicitly. Constructed examples are not presented as real client engagements, court appointments or actually achieved case outcomes. This preserves the distinction between explanatory material and case-specific evidence.

Updating the knowledge base

Currency is reviewed especially where technical specifications, standards information, manufacturer documentation or regulatory context may have changed. A modification date is changed only when substantive content actually changes; a routine review without a substantive change is not represented as a new version of the article.

Documentation standard for each article

• technical question and subject of examination;
• relevant records, artefacts or data;
• version and time context;
• possible examination methods and disclosed reference criteria;
• technical findings and professional interpretation;
• counter-hypotheses, uncertainty and statement boundaries;
• sources, source status and review date where relevant;
• explicit separation from legal evaluation.

Methodological origin of the working logic and control questions

One methodological influence is Nicolai Andler, Tools für Projektmanagement, Workshops und Consulting – Kompendium der wichtigsten Techniken und Methoden, 6th revised and expanded edition, Publicis, Erlangen, 2015, ISBN 978-3-89578-453-8. The structured problem-solving cycle and selected control questions provide a general methodological stimulus. Where such questions are used here, they are selected, condensed and reformulated for technical expert contexts rather than presented as original inventions.

The technical evidence and assessment logic is kept separate. It includes identifying the subject and system state, source and data provenance, reproducible measurement, technical findings, counter-hypotheses and counter-evidence, professional interpretation and assessment, detection limits and the documented statement boundary. This technical synthesis is not attributed to Andler. The decision-related stage of a general problem-solving cycle is likewise not equated with the organisational, commercial or legal decision of the client or court. The technical expert provides a reasoned technical basis; the competent body makes any further decision.

Further reading

• Findings, Interpretation and Assessment
• Testing Counter-Hypotheses and Alternative Explanations
• Defining Reference Standards and Technical Assessment Criteria
• All Expert Reports & Methodology articles

Technical expert reporting and examination methodology

The strength of a technical conclusion depends on a defined question, identifiable evidence, a disclosed method and an explicit statement boundary.

Expert Report Documentation