Methodology and Evidence Levels

Why an evidence method is essential

An encyclopedia about human settlement on Mars necessarily combines very different levels of certainty. The mass of Mars, its gravity, the length of a sol and the Earth–Mars synodic period rest on robust observation and modelling. At the other end of the spectrum, an autonomous Martian city, a complete semiconductor supply chain or medicine for a population born at 0.38 g remain highly prospective. Between those extremes are technologies that have genuinely been tested, but not yet in the environment, duration or scale of a settlement.

If these categories are blurred, a page can become misleading without containing a single obviously false sentence. A process working on the ISS does not prove that it will work for ten years on Mars with locally manufactured spares. A propulsion test does not prove that a complete vehicle is mission-ready. A date announced by a company is not the same thing as a future event. The method exists to prevent those category errors.

The seven evidence statuses used by Delta-Sierra

1. MEASURED / OBSERVED. A value from an instrument, mission or primary publication, with date, conditions and uncertainty when they affect interpretation.
2. DEMONSTRATED / QUALIFIED. A function actually tested in a defined environment and at a defined scale. The test proves what was tested, no more.
3. STANDARD / PHYSICAL RELATION. An equation, constant, convention, standard or documented requirement used to structure a calculation or design decision.
4. IN DEVELOPMENT. A technology or system whose elements exist and are progressing, but whose final capability has not yet been acquired.
5. OBJECTIVE / DECLARATION. A date, capability, architecture or ambition announced by an organisation. It must be dated and attributed.
6. ENGINEERING EXTRAPOLATION. A reasoned application of known data to a future architecture, with assumptions, margins, dependencies and sensitivities exposed.
7. DELTA-SIERRA PROSPECTIVE SCENARIO. A pedagogical or prospective architecture used to explore consequences without presenting it as an official programme or demonstrated capability.

A number is not evidence until its boundary is named

A value such as “98% recycling” is unusable unless the reader knows what is being recycled, for how long, in which configuration, with which hardware and what happens to the remaining 2%. The same discipline applies to flow rate, thrust, dose, payload mass or availability. Each important number therefore needs its quantity, unit, system boundary and evidence status.

When Delta-Sierra derives a value, input data must be separated from assumptions. The operation should be reproducible, units should reduce correctly and the result should be translated back into ordinary language. Excessive numerical precision can never compensate for uncertain assumptions.

Example: technology demonstration versus operational system

Suppose a device produces oxygen from Martian carbon dioxide. The demonstration can prove that the physico-chemical chain works under the tested conditions. It does not yet prove that a human base can continuously produce all oxygen required for breathing and ascent, survive failures, store and transfer product, monitor purity and repair the plant with local means.

Moving from demonstrator to critical service adds questions about nominal and peak throughput, electrical demand, availability, contamination, wear, redundancy, spares, maintenance skills, time to consequence and degraded modes. The analysis should make that change of scale explicit rather than allowing a successful prototype to imply a ready-made settlement system.

Example: an announced date is not an achieved date

Space programmes evolve. An agency or company may publish a target for a launch, demonstration or landing and later move it as tests reveal new constraints. Delta-Sierra therefore uses language such as “the organisation targets”, “announces”, “no earlier than” or “is studying”, with a verification date. When a milestone actually occurs, its status changes and the page should change with it.

This also makes pages age better: a document that clearly separates historical fact from future target remains useful much longer than one written as though an industrial schedule were a certainty.

How to verify a source

The preferred hierarchy is mission data, technical documents, standards, institutional reports, peer-reviewed papers and original publications. Strong secondary sources can provide context, but they should not replace a primary source when a precise technical statement can be checked directly.

• Who produced the information, and for what purpose?
• What is the date or document version?
• Is the number a measurement, target, model or assumption?
• Does its domain of validity really match the Martian case?
• Does a comparison use the same system boundary on both sides?
• Has a newer source changed the programme status or value?

Images are never evidence by themselves

A photorealistic illustration can be excellent for understanding an architecture, but visual realism must never be confused with documentary status. A Delta-Sierra image should be identified as an illustration, conceptual visualisation or scenario when appropriate. A historical photograph should retain author, source, date and licensing information.

The same rule applies to diagrams: a diagram can summarize a functional chain, but the numbers and relationships it displays must remain verifiable in the surrounding text. Beauty should increase attention and understanding, not manufacture certainty.

The final rule: answer three questions

An important page should let readers answer three questions quickly: what do we know, how do we know it, and what are we assuming? If those answers cannot be found, the explanation is not finished. The method exists so newcomers can understand without being misled and technical readers can verify without guessing the status of every sentence.