A datum is a recorded value, such as a category, date or reading. It becomes useful information when we know what it represents and which question it serves. ‘Do readings differ between zones of a model?’ requires zone, reading and conditions, not participant names. The question guides what to collect and omit. Many numbers without provenance can prevent comparison even when the table looks extensive. Define the observation and recorded features beforehand.

A sample is the collection of observations we use. Its results describe those cases, not automatically the entire school. Distinguish supplied teaching data from actual measurements. The task can use the classroom sample or twenty collected readings, five in each fictional zone A, B, C and D, with their origin recorded. For micro:bit light, the scale remains 0–255 rather than lux. Keeping orientation and procedure comparable helps investigate zones without confusing their effects with other simultaneous changes.

A table organizes observations in rows and features in columns. Each column needs a name and stable meaning. Zone is a grouping category; reading is a comparable quantity within its scale; id identifies a record. A numerical code is not necessarily a magnitude: summing identifiers does not describe light. A short dictionary explains each column, permitted values and its scale or unit. Another person can then understand the table without an oral explanation.

Checking quality means finding inconsistencies, duplicates and missing values without altering data to obtain a desired result. Do not automatically replace a missing reading with zero: zero is a value that could change the mean. Nor should an unusual value be deleted merely because it differs. Check for transcription error or different conditions and document the decision. In Sheets verify numeric recognition and consistent scales. Preserve the original sample and record changes. A tidy table helps analysis, but appearance does not guarantee the observations answer the question.

The arithmetic mean summarizes a series with a value obtained by adding its quantities and dividing by the number of observations used. It allows comparisons between groups, but does not by itself describe how their data varies. Two series can have the same mean and contain very different individual values. Keeping the table lets us examine minima, maxima and distribution to interpret that summary. The mean is useful when we know which observations it comes from and which question the comparison should answer.

In Google Sheets, PROMEDIO or AVERAGE calculates this value according to the language settings. The formula works with cells in the selected range, so we need to check which cells it includes and whether their readings are recognized as numbers. Text can be excluded from the calculation. The task calls for five values per zone; reviewing the range and checking one group through manual addition and division verifies that the result matches the data we intended to summarize.

A bar or column chart presents the comparison between categories visually. If each bar represents a mean per zone, the title must explain this and the axes must identify categories and numerical scale. For micro:bit light, we retain reading 0–255. Because lengths are being compared, starting at zero helps avoid exaggerating differences. Stating whether the data is supplied or measured and adding a written explanation completes the representation. The chart compares the sample studied; it neither establishes uninvestigated causes nor turns those cases into a description of the whole school.

For the light alert we wrote a comparison and responses. A machine-learning classifier adjusts a model using examples associated with classes. At an introductory level, training means adjusting that relationship; prediction means producing a response for an input. We do not manually write every visual feature it should use. This supports exploring tasks difficult to express through one comparison, but makes it essential to investigate supplied examples and possible clues associated with labels.

A class is a category defined for the task, such as an object type. Its meaning must be clear before gathering images. If an object combines features of both classes, agree whether it belongs to one or stays outside the experiment. Showing a label does not give the model human understanding. It may rely on shape, background, orientation or other regularities. In Teachable Machine choose two object classes and use authorized camera inputs or files without people. The goal is understanding the process and limits, not recognizing everything.

Training and testing answer different questions. Training examples adjust the model; test examples let us observe its later responses to images it did not use for that adjustment. Reserving them before training maintains this separation. Generalizing means responding to new cases within the defined task. Repeating a known photograph can hide difficulty doing so, even when it produces the expected label. Testing needs to supply information different from what already helped build the model.

In the project we prepare twenty different training images per class and ten new tests, five per class. Variety matters alongside quantity: nearly identical burst photographs repeat one situation and provide little independence. Varying captures, orientation and background for both classes avoids associating a clue with only one category. Files are identified by object and purpose, without people’s names. The actual class is established from the agreed definition before consulting the prediction.

Test errors can guide an improvement, but that revision changes the role of the information used. If we add a test image to training, it stops being new and cannot by itself demonstrate that the repair works on other cases. We need another reserved series, with five tests per class and comparable conditions. Recording the sets used for each version lets us learn from a failure and distinguish that learning from the later check. Separation depends on actual image content, not just folder names.

Evaluating a test requires actual class, prediction and comparison. A correct prediction matches the agreed definition. Calculate accuracy by dividing correct predictions by total tests and multiplying by one hundred. The denominator matters: seven correct out of ten differs from seven out of twenty. State conditions and tests per class too. A global result can hide a weaker category. Keeping errors guides improvement instead of displaying only favorable cases.

The result describes the tested sample; it does not guarantee a fixed percentage for every camera, classroom or object. Confidence bars or model scores are not truth certificates either. The model can be confidently wrong and assign a class to an object outside the intended categories. It need not say ‘I don’t know’ unless such behavior is designed. Checking requires a human-reviewed reference. If the first series has no errors, investigate a difficult condition without inventing failures or discarding tests that contradict a preferred conclusion.

An example set can contain imbalances or clues unrepresentative of the task. Here, bias means a data pattern favoring some situations while representing others poorly. Similar class counts help comparison but do not guarantee variety. Twenty near-identical photos may cover fewer situations than a collection planned around orientation and background changes. Investigate a clue with a hypothesis: perhaps background matters. A hypothesis is not a demonstrated cause; it needs a test changing that condition while holding others steady.

Connect improvement to the observed problem. If one class fails in an orientation, review its examples and add relevant variety without removing difficult test cases. Retrain and use another new series under comparable conditions. Changing camera, objects, background and lighting together creates several possible explanations. Record data and model changes, what remained constant and the results. Improvement may be partial or absent; explaining that with evidence teaches more than claiming success merely because images were added.

A model’s suitability depends on purpose and the consequences of error. A suggestion for sorting objects can be checked visually; an important decision about people would require safeguards this experience does not provide. Before recommending use, explain who benefits, who could be harmed and how responses are reviewed. Do not add names, faces or voices to make the demonstration more impressive. Authorized objects support the same training, testing and limitation concepts without unnecessary personal data.

Documentation combines question, table, chart, classes, separate sets, results and two limitations. Distinguish actions, observations and proposals. Browser-based training does not mean the whole tool works offline or every export is private. Saving or sharing a project can change where examples and files remain; use the school-prepared configuration. Keep only what its instructions require. The final product must make the procedure reviewable through data and records without requiring a public model or claiming certified reliability.