Ecological informatics turns observations about organisms and environments into information that people can interpret, combine, test and reuse. It connects ecological questions with data structures, metadata, computing and models. Its central challenge is preserving what a measurement means while that measurement moves from a field notebook or sensor into a database, map, analysis and decision.
The gold standard is a result whose meaning and history remain inspectable: what was sampled, where and when, with which method, what was changed, and which conclusions the evidence supports. A large database or accurate-looking prediction is insufficient on its own. This guide develops that standard through original hypothetical examples, including a broken database join, unequal survey effort, missing sensor readings and a model that fails when moved to another wetland.
Start with The Gold Standard for the wider collection, Education: learning that transfers into life for the learning approach, and the How X Works hub for connections across subjects. The Ecology root explains the living relationships that give these data their purpose.
Choose your ecological informatics route
Follow ecological evidence from field observation to reusable data, tested models and defensible decisions.
Route 1 · Chapters 1–3: Define questions, records and metadata
Route 2 · Chapters 4–6: Preserve effort, units and identity
Route 3 · Chapters 7–9: Check resolution, quality and provenance
Route 4 · Chapters 10–11: Validate models and alerts
Route 5 · Chapters 12–14: Transfer, share and practise
Chapter index
Define questions, records and metadata · Chapters 1–3
Preserve effort, units and identity · Chapters 4–6
Check resolution, quality and provenance · Chapters 7–9
Validate models and alerts · Chapters 10–11
Transfer, share and practise · Chapters 12–14
Imagine a team monitoring six ponds. Fieldworkers record frog calls, technicians download water-temperature measurements, and volunteers upload photographs. A dashboard reports that frog records have doubled. The immediate ecological question is whether frog populations or site use changed. The immediate information question is whether the records are comparable. Both questions matter, but they require different evidence.
If recording duration also doubled, the increase might reflect greater listening effort. If the same audio file was processed twice, part of the increase might be duplication. If a new classifier recognises a previously missed call, the observation process changed. Ecological informatics makes these possibilities visible before the graph becomes a claim about nature.
Specify the quantity before designing the table
Write the intended result in a sentence: “Estimate the proportion of these ponds used by the target species during comparable breeding-season survey windows.” That is a different target from total calls, number of distinct animals, breeding success or regional abundance. No column called count can safely stand for all five.
The information system should preserve the distinctions the question needs. For site use, that includes pond identity, survey occasions, successful and unsuccessful listening, the observation method, and evidence supporting identification. For individual survival, it would also require a defensible link between observations of the same animal. A convenient file format cannot create an identity that was never observed.
Ecoinformatics is another name commonly used for ecological informatics. Its work overlaps biodiversity informatics, environmental data management, statistics and computer science. This guide concentrates on the complete ecological evidence pathway rather than treating any particular software package as the subject. Some projects need sophisticated databases; a small, carefully designed spreadsheet can be appropriate for others.
The practical first test is simple. Give a colleague one result and ask them to explain its numerator, denominator, time window and sampling unit. If those answers require guessing, improve the question and data description before increasing the number of records. Otherwise automation will multiply an ambiguity that should have been resolved at the start.
A pond is not a survey visit, and a survey visit is not an animal. These distinctions should remain visible in the data model. One site can have many visits; one visit can produce several taxon observations; one observation can have supporting photographs or measurements. The relationships are often one-to-many rather than one-to-one.
For the hypothetical project, keep a sites table with one row per pond and a visits table with one row per listening session. Each visit stores its site identifier, date, duration, protocol and completion status. An observations table links recorded taxa and quantities to the visit. A separate measurement table can hold temperature readings and their timestamps without repeatedly copying every frog record.
Darwin Core's term definitions provide shared vocabulary for biodiversity information, including eventID and occurrenceID. These identifiers concern different things. An event identifier connects information about an event; an occurrence identifier identifies an occurrence rather than merely the digital row describing it. Use the definitions deliberately when mapping local columns to shared terms.
A join can manufacture apparent evidence
Suppose visit V1 has three frog-observation rows and four temperature readings. Joining both tables directly on visitID produces every matching combination: 3 × 4 = 12 rows. If the three frog quantities were 2, 1 and 3, their original sum was 6. Summing the joined quantity column now gives 24 because every observation appears four times.
Nothing changed in the pond. The database operation changed the number of representations. A neat output table and a successful query do not reveal the error automatically.
Repair it by choosing the required relationship first. If each visit needs one summary temperature, calculate that summary in the temperature table and then join its single row to the visit. If time-specific matching is required, define the time window and matching rule explicitly. Keep observations and raw sensor readings available separately.
Check unique identifiers, expected row counts and unmatched keys before and after joins. A visit identifier that accidentally repeats across two projects can create another false match. Namespace identifiers or otherwise establish their uniqueness across the combined dataset. These checks protect ecological meaning, not merely database tidiness.
Metadata describes data well enough for another person or program to use it appropriately. A filename such as final_pond_data.csv does little of that work. A useful description explains the study purpose, sampling coverage, methods, variables, units, missing-value conventions, identifiers, limitations and responsibility for the data.
Ecological Metadata Language provides a structured way to describe ecological resources. Its modules can describe dataset entities, attributes, methods, project context and access arrangements. An important distinction in its documentation is between a prescribed protocol and the methods actually performed. A project can follow a protocol imperfectly; its record should describe that reality.
The dictionary must describe the stored values
Consider three columns: temp, duration and status. Their names look understandable until a second analyst asks whether temperature is air or water temperature, whether duration is minutes or seconds, and whether status means the visit was completed or the species was detected. The dictionary should resolve each question without requiring a conversation with the original recorder.
For a local column called water_temperature_c, specify the measurement location, instrument, degrees Celsius, time relationship to the biological survey, and valid missing-value representation. For listening_minutes, say whether it excludes interruptions. For visit_status, define every category, including partially completed visits. Do not make a blank cell silently carry three meanings.
Suppose the protocol calls for ten minutes of listening, but rain interrupts a visit after four minutes. Store planned and actual effort separately. Replacing four with ten to make the file match the protocol erases information needed to interpret non-detection. The same principle applies when a sensor is moved, a laboratory method changes or an identification is revised.
Metadata is easiest to maintain while these decisions are being made. A short dictionary written before collection exposes missing design choices. A review after collection tests whether the dictionary matches the actual file. Ask a colleague to reconstruct one visit using only the package; their unanswered questions identify the next useful improvement.
A zero is a measurement or classification with a defined meaning. It is not a universal replacement for an empty cell. For the pond project, distinguish a completed survey with no target calls, a cancelled survey, a recording lost before analysis, and a recording that was analysed but could not support identification. These outcomes have different implications.
GBIF's survey and monitoring guide, version 1.0.2 dated 24 September 2025, explains how survey design, event structure, scope and effort can be represented for shared biodiversity data. Its discussion of absences is especially relevant: a missing occurrence row needs survey context before it can support a non-detection interpretation.
Work the denominator explicitly
Team A records 18 target calls during six completed ten-minute sessions. Team B records 24 during twelve comparable ten-minute sessions. A's observed rate is 18 ÷ 60 = 0.30 calls per minute. B's is 24 ÷ 120 = 0.20 calls per minute. B has more recorded calls but a lower rate per minute under the stated comparison.
Neither calculation estimates frog abundance without additional assumptions. One animal may call repeatedly, weather may affect calling, and nearby microphones may record the same event. The arithmetic fixes one denominator problem; it does not solve every observation problem. State that limitation beside the result.
Now suppose four of B's scheduled sessions failed and produced no usable recording. If 24 calls came from eight completed sessions, the observed rate becomes 24 ÷ 80 = 0.30. Treating failed sessions as observed zeros would incorrectly retain 120 minutes of effective listening. Preserve scheduled effort and usable effort so readers can see both operational coverage and biological evidence.
Repeated visits can support more explicit models of imperfect detection. The specialist guide to dynamic occupancy, colonisation, extinction and detection explains that next step. Before using such a model, ensure the data distinguish visit failure from a valid non-detection and preserve the site and season definitions the model assumes.
Two values can share a unit and still measure different things. A water sample from the surface at midday is not automatically comparable with a depth-averaged daily measurement. Harmonisation therefore needs two checks: numerical conversion and scientific compatibility.
For example, 2.4 milligrams per litre equals 2,400 micrograms per litre. Combining the number 2.4 with values recorded in micrograms per litre without conversion creates a thousandfold error. Store the original value and unit, the converted value and unit, and the rule used. Do not overwrite the only recoverable record of what the instrument reported.
The next question is whether both laboratories measured the same substance on the same basis. A concentration reported as mass of an element may differ from concentration reported as mass of a compound containing it. Correct conversion requires chemical meaning, not just a familiar unit label. If the basis is undocumented, flag the uncertainty and seek clarification rather than guessing.
DataONE's guidance on compatibility emphasises considering how datasets were produced before integrating them. A common set of column names makes files easier to combine; it does not establish that their methods are interchangeable.
An original calibration case
Suppose a temperature sensor consistently reads 0.8°C above a trusted reference over the range tested. Its recorded value of 27.6°C would become 26.8°C under a simple offset correction. Label this as a corrected estimate, retain 27.6°C as the raw value, and record the calibration evidence and applicable range.
Do not extrapolate that correction automatically to another sensor, a later period after damage, or a temperature range that was never checked. A constant offset is a model of error. It may be useful without being universally true.
A practical repair is to maintain a methods table with start and end dates for instrument deployments and processing versions. Then each record can be associated with the applicable method. A sudden ecological trend aligned with an instrument replacement deserves investigation before being interpreted as environmental change.
Taxon names enable data integration, but a text match is only the beginning. Records may use synonyms, outdated classifications, abbreviated names, uncertain identifications or names applied differently by different sources. An automatic matching service can organise this work, but a confident-looking match can still represent the wrong biological interpretation.
Keep the original recorded name alongside the interpreted name, the taxonomic reference used, its version or retrieval date, the matching outcome and any identification qualification. A specimen identified only to genus should not acquire a species label because that species happens to be common locally. Preserve the distinction between an observation and a later inference about it.
A taxonomic split changes the comparison
Imagine that an older survey recorded 40 observations under hypothetical Species A. A later classification separates that name into A1 and A2. Recent surveys report 25 A1 observations and 15 A2 observations. It is tempting to describe A1 as having declined from 40 to 25. That comparison assigns every older record to A1 without evidence.
If old specimens or diagnostic images allow re-identification, document the new decisions and retain their connection to the original records. If they do not, compare at the combined A1–A2 group where scientifically defensible, or report that the finer comparison cannot be made. The older records have not become worthless; their usable taxonomic resolution is different.
Another common trap occurs when two names are synonyms. Counting both as separate species inflates observed richness. Conversely, merging genuinely distinct taxa reduces it. Review the mapping table before calculating diversity, and check whether ambiguous matches disproportionately affect particular years or habitats.
The specialist article on sample coverage, rarefaction and richness comparisons develops fair comparisons after the observation units and taxonomic rules are coherent. No diversity formula can repair a naming system that silently changes the things being counted.
For a student exercise, build a tiny fictional name table containing an exact match, a synonym, an unresolved genus and a split. Explain the treatment of each. The objective is to make the interpretation visible, including the cases where a precise answer is unavailable.
A coordinate is a representation of location, not proof of exact position. A date can describe a moment, an interval or a partly known historical period. Combining records requires attention to these meanings, particularly when environmental layers have finer resolution than the observations they are assigned to.
DataONE's geospatial guidance identifies scale, projection, datum and resolution as relevant integration properties. Converting coordinate formats is not the same as resolving positional uncertainty. Adding decimal places to an approximate locality makes its printed representation more precise without adding information.
A point can be too uncertain for a fine map
Suppose a frog observation has a location uncertainty radius of 200 metres and an analyst assigns it to a ten-metre habitat pixel. Under a simple circular representation, the uncertainty area is π × 200² ≈ 125,664 square metres. That is about 1,257 ten-by-ten-metre pixel areas. The record cannot support a confident claim about one particular pixel merely because a coordinate was supplied.
The appropriate response depends on the question. Use a coarser habitat summary, examine the distribution of possible habitats within the uncertainty region, exclude the record from a fine-scale analysis with a stated reason, or seek better location evidence. Do not invent a more exact point.
Temporal matching creates a parallel issue. A photograph from an unspecified day in July cannot always be assigned meaningfully to the temperature measured at noon on 1 July. A monthly environmental average may be a defensible exposure summary for some questions, while a short-lived event requires much more exact timing.
For automatic sensors, retain time-zone and clock information. In Singapore, a reading at 01:00 on 2 October corresponds to 17:00 UTC on 1 October. Grouping one file by local dates and another by UTC dates can shift observations between daily summaries. Decide which day definition answers the ecological question, convert deliberately, and retain the original timestamps for checking.
When a map or time series looks unexpectedly sharp, inspect its resolution assumptions. A smooth surface may be an interpolation product; it is not a direct observation at every displayed location.
Quality control asks whether records conform to explicit expectations and whether apparent problems can be explained. Some checks are mechanical: required identifiers exist, dates parse, units are recognised, and references point to real records. Others require ecological judgment: a large value might be an instrument error or the unusual event the study was intended to detect.
Separate invalid, suspicious and valid-but-unusual records. An impossible latitude can fail a validation rule. An unusually high temperature may deserve review against neighbouring readings, instrument logs and field notes. Automatically deleting every extreme value risks removing heatwaves, floods or disturbance responses from the evidence.
GBIF's current data-quality recommendations distinguish minimum indexing requirements from richer information that improves usefulness. Passing an ingestion check means the data meet that check. It does not establish suitability for every ecological analysis.
Missingness can move the answer
Suppose a sensor should record one value on each of ten days. Eight available values are 20°C, and the sensor fails on two unusually hot days. The available-data mean is 20°C. If an independent reference showed that the missing days were both 30°C, the complete ten-day mean would be (8 × 20 + 2 × 30) ÷ 10 = 22°C.
The two-degree difference arises because the missing days differ systematically from the observed ones. Filling both gaps with the observed mean would preserve 20°C and conceal the problem. In a real project, the true missing values are usually unknown; this example uses known hypothetical values to expose the mechanism.
If plausible missing-day values range from 25°C to 35°C, the corresponding ten-day mean ranges from 21°C to 23°C. That is a sensitivity range under stated assumptions, not a confidence interval. It helps show whether an interpretation depends on how gaps are handled.
DataONE's missing-value guidance supports explicit, consistent missing-value conventions. Extend that discipline by keeping a reason where available: equipment failure, unsampled period, inaccessible site or withheld value. Repair the cause when possible, and report the remaining effect on the ecological conclusion.
A reproducible analysis connects identifiable inputs to recorded transformations and outputs. Begin with a preserved raw-data copy, then create derived versions through documented steps. Record the exact data release, query or download used, the transformation rules, the software environment and relevant model settings. A live website can change after an analysis is completed.
DataONE's workflow documentation guidance addresses recording processing steps. The W3C PROV-O recommendation provides a more formal vocabulary linking entities, activities and responsible agents. A small project can implement the same underlying idea in a readable log without building a sophisticated provenance system.
Follow one result backwards
Suppose a report states that 84 of 120 usable visits contained a target detection. The result is 84 ÷ 120 = 0.70, or 70%. Its provenance should identify the visit table, the target definition, the usable-visit filter, the detection rule and the calculation. If 150 visits were originally scheduled, readers should also be able to discover why 30 did not enter the denominator.
The processing log might show ten cancellations, twelve damaged recordings and eight visits outside the prespecified season. Those categories explain the accounting but do not automatically remove bias. If the excluded visits mainly came from flooded ponds, the retained sample may describe a different set of conditions. Reproducibility lets another person inspect that choice; ecological reasoning determines whether the choice is justified.
Use stable version labels rather than continually replacing a file called final. A checksum can detect changes to file bytes, but it cannot prove that the measurements were correct. Similarly, saving a random seed can help reproduce a stochastic calculation without establishing that its model is appropriate.
A useful handover test is to ask someone to regenerate one figure from the archived package without instructions delivered verbally. Record every missing dependency they discover. Fixing those gaps creates a concrete improvement: the result becomes less dependent on one person's memory and more available for correction, extension and future comparison.
A model can predict held-out records well while failing at a new site. The reason may be dependence between training and test observations. Nearby records share conditions; repeated observations share sites; images may share individuals or recording sessions. Randomly splitting rows can leave near-duplicates or closely related observations on both sides.
Roberts and colleagues' research on structured cross-validation examines spatial, temporal, hierarchical and phylogenetic dependence. It explains why validation splits should reflect the prediction problem, while also recognising that blocking can create extrapolation. A more demanding split is not automatically the correct one; the intended use determines what must be held out.
Compare two distinct prediction tasks
Imagine 600 recordings from six ponds. A model is intended for a seventh pond, so the relevant question concerns transfer to an unobserved site. A random recording split might give a mean absolute error of 0.8 units, while holding out entire ponds gives 2.1 units. These are invented results illustrating two different evaluation tasks, not performance claims about a real model.
The difference is 1.3 units, and the blocked error is 2.625 times the random-split error. That discrepancy should prompt investigation of site-specific information, environmental coverage and leakage. It does not identify a single cause by itself. If the operational task instead concerns a new recording at a well-monitored existing pond, a different validation design may be appropriate.
Fit preprocessing steps using training data within each validation split. For example, information from the test set should not determine imputation values, feature selection or tuning decisions. Otherwise the supposedly unseen observations have already influenced the procedure being evaluated.
For a future-season forecast, preserve temporal order and test on later periods. For new geographical regions, examine whether test environments lie outside the training range. Report the target, split unit, metric, uncertainty and baseline comparison together. “High accuracy” alone hides the conditions under which the number was obtained.
Finally, prediction is not intervention evidence. A variable that helps predict frog calls may identify recording conditions rather than a cause of population change. Changing that variable need not produce the ecological outcome the model associates with it.
An ecological information system often ends in an alert: inspect a sensor, revisit a pond or investigate a possible disturbance. The useful output is a reasoned next action supported by evidence. A classifier score alone leaves out the reliability of the data, the frequency of the event and the consequences of mistakes.
Work a low-frequency event example
Assume 1,000 monitoring windows, of which 20 truly contain a specified event. A hypothetical detector has 90% sensitivity and 95% specificity under these conditions. It detects 18 of the 20 events and misses two. Of the 980 event-free windows, 5% produce false alerts: 49 windows. The system therefore generates 67 alerts, of which 18 are true.
The positive predictive value is 18 ÷ 67 ≈ 26.9%. This does not contradict the stated sensitivity or specificity. It shows how a relatively uncommon event can produce an alert queue dominated by false positives even when the two familiar performance percentages look strong.
Those assumptions may change across seasons, habitats or recording equipment. Recalculate using the operating context instead of treating the example's percentages as universal. Human review can improve an operational process, but it also has error rates and limited capacity that should be assessed.
A sensible design might route preliminary alerts to a reviewer who inspects the underlying recording, instrument status and recent context. A confirmed concern could trigger a targeted field visit. The escalation rules should reflect the action: checking a microphone and declaring a regional ecological collapse require very different evidence.
The existing specialist guide to early-warning indicators, false alarms and trigger confirmation develops ecological mechanisms and confirmation rules. The informatics contribution is to preserve the evidence reaching that decision: inputs, quality flags, model version, threshold, review outcome and subsequent correction.
If an alert is later found to be a sensor fault, keep the correction linked to the original alert. Erasing the false alarm prevents the team from learning how often the system fails and whether its review process is improving.
You inherit a dataset with 100 scheduled ten-minute listening sessions. Ten were cancelled; 90 produced usable recordings. The target was detected in 54 usable sessions. A colleague reports a 54% detection frequency and proposes applying the same pipeline to tidal wetlands surveyed for twenty minutes with a different microphone.
Before reading the answer, identify the correct descriptive denominator, two quantities that cannot yet be inferred, and three changes that require review. Then explain why a longer recording does not automatically make the two datasets comparable.
Answer and reasoning
The observed detection frequency among usable sessions is 54 ÷ 90 = 60%. The separate completion rate is 90 ÷ 100 = 90%. Reporting both preserves biological observations and operational coverage. The 54% value describes detections per scheduled session, but it should not be labelled detection frequency among completed surveys.
Neither 60% nor 54% directly estimates the proportion of occupied wetlands or the number of frogs. Imperfect detection, repeat observations, the definition of a site and the sampling design remain relevant. If cancellations were concentrated in adverse conditions, even the descriptive 60% may not represent all scheduled conditions.
The transfer review must examine recording duration, microphone characteristics and tidal conditions. It should also consider species composition, background sound, site boundaries, seasonal timing and the classifier's training coverage. Twenty minutes changes the opportunity for detection; tidal noise may change recognisability; a different microphone changes the signal available to the detector.
A useful bridge study could collect paired recordings under both protocols across relevant conditions, using a design that avoids treating dependent recordings as independent ecological samples. Review comparable raw evidence, detection outcomes and errors before deciding on a harmonisation rule. A universal multiplier should not be assumed from recording duration alone.
The transferable principle is to preserve the observation process. The implementation can change: new effort fields, new calibration records, revised quality checks and a validation split representing new wetlands. If those changes cannot be reconstructed, apparent ecological differences remain entangled with the change in measurement system.
Findable and reusable data need more than an upload button. They need understandable descriptions, persistent identifiers where appropriate, clear usage conditions and a maintained connection between data and documentation. The FAIR principles organise this work around findability, accessibility, interoperability and reusability. FAIR does not mean that every record must be openly downloadable; access arrangements can include authentication and authorisation.
Ecological data can include sensitive species locations, landholder information, identifiable volunteers or knowledge subject to community agreements. Decide what can be shared with the relevant custodians before release. Technical ability to copy a dataset does not determine the terms under which it should be used.
GBIF's guidance on sensitive occurrence data addresses balancing availability with the risk of harm. If locations are generalised, make the modification visible so downstream users do not treat the released coordinates as exact field positions. Preserve the authorised detailed version separately when appropriate.
A release package should survive a handover
For the pond project, prepare the data files, dictionary, methods description, quality explanations, processing instructions and usage conditions together. Include a readable account of known limitations: inaccessible ponds, uncertain taxa, microphone changes or seasons outside the intended scope. These are part of the scientific meaning of the package.
An update should explain whether it adds observations, corrects errors or changes interpretation. A taxonomic revision may alter a result without changing the underlying field evidence. A repaired timestamp may move observations between days. Record such changes so a later analyst can explain why two releases produce different outputs.
Responsibility also includes maintenance. Assign someone to receive correction reports and define what happens when a project ends. A dataset can remain valuable after its original software stops running if the raw data, open descriptions and transformation logic are preserved. Conversely, a polished dashboard can become unusable when the only person who knows its undocumented assumptions leaves.
The aim is a package that supports appropriate reuse, including a reader's decision that the data do not answer their question. That is a useful scientific outcome, because it prevents confident conclusions built on incompatible evidence.
Do I need to learn programming first?
No. Begin by designing a small table in which each row has an explicit meaning, each variable has a definition, and missing values have documented treatment. Programming becomes valuable when checks and transformations must be repeated reliably. The first capability is recognising what a computation should mean; software then helps carry it out consistently.
Is a larger dataset automatically better?
No. Additional observations help when they add relevant information under a suitable design. Thousands of repeated records from one accessible path may contribute less to a regional question than a smaller, well-designed survey spanning neglected habitats. Report geographical, seasonal and methodological coverage alongside record counts.
Can AI identify species or fill metadata gaps?
It can assist with bounded tasks when its outputs are evaluated against suitable evidence. Preserve original images, recordings and labels, mark inferred fields, and check performance in the relevant conditions. Do not let a generated explanation silently become a field observation. Unknown collection methods should remain unknown unless evidence resolves them.
What should I investigate when a result suddenly changes?
If counts jump after a table merge, inspect join multiplicity and identifiers. If a trend begins on an equipment-change date, inspect calibration and methods. If a distribution shifts after a taxonomic update, inspect name mappings. If accuracy falls at new sites, inspect transfer conditions and validation design. These are starting hypotheses, not automatic diagnoses.
A compact project that tests the whole chain
Create a fictional dataset of three ponds, four visits per pond and two target taxa. Include one cancelled visit, one ambiguous identification, unequal listening durations and two sensor readings per visit. Build a dictionary, calculate effort-aware summaries and deliberately attempt the unsafe join described in Chapter 2. Explain why its total is wrong, then repair it.
Next, change one assumption: remove the usable recording from the wettest visit or split one taxon into two unresolved names. Show which conclusions still hold and which become uncertain. Finally, give the files and instructions to another learner and ask them to reconstruct one reported number. This turns understanding into an observable capability.
Use Ecology to strengthen the biological question, the linked specialist articles to examine particular inference problems, and the primary documentation throughout this guide when implementing shared standards. Source documentation was checked on 27 October 2026; standards and service interfaces can change, so check the applicable documentation again before a real data release.
The gold standard of ecological informatics is evidence that keeps its meaning as it travels: from an observed event to a stored record, from a record to an analysis, and from an analysis to a decision that another person can inspect and improve.