A simple story of BEACON FRAMEWORK
What is data quality → why it matters → why checking missing values is not enough → why BEACON uses dimensions → where the eight dimensions came from → why the mapping table is necessary → why eight rather than another number → how the 15 rules operationalise the dimensions → how this ultimately connects to ML.
The important methodological basis already established in your project is that the eight dimensions were synthesised from established data-quality literature/standards and PCF-specific requirements, then filtered using three BEACON criteria: measurability, rule definition and computability. The Feature–Dimension Mapping is explicitly intended to be the conceptual core connecting dataset attributes to rules and automated assessment.
I would not claim that "8 is the Goldilocks zone" or that eight is objectively the universally correct number for all domain datasets. Eight is the selected BEACON set because it provides the required coverage for this PCF dataset while satisfying the project's objective assessment criteria and avoiding dimensions that could not be operationalised reliably
Why Data Quality Matters in Product Carbon Footprint Data:
Understanding the BEACON Framework
An accessible introduction to why carbon data needs more than a simple missing-value check
Imagine making an important decision with unreliable information
Imagine that you are comparing two products because you want to understand their environmental impact.
Product A appears to have a carbon footprint of:
10 kg CO₂e
Product B appears to have:
10,000 kg CO₂e
It would be tempting to conclude that Product B is 1,000 times worse.
But before making that conclusion, we need to ask:
- Are the two products measured using the same basis?
- Are their weights comparable?
- Are the reporting boundaries the same?
- Was the carbon footprint calculated using a recognised method?
- Is the information complete?
- Are the values physically plausible?
- Can the reported figures be traced back to a source?
- Are some countries or industries over-represented?
- Are the descriptions clear enough to understand what the numbers actually represent?
This is the problem that data quality addresses.
For Product Carbon Footprint (PCF) data, this is particularly important because poor-quality information can affect not only reporting and sustainability decisions, but also any machine-learning model trained using that information.
The BEACON framework was developed to provide a systematic way of assessing these issues before PCF data is used for machine learning.
1. What does "data quality" actually mean?
Data quality does not simply mean:
"There are no empty cells."
A dataset can contain no missing values and still be unsuitable for analysis.
Consider four simple examples.
Example 1 — Missing information
Product weight = [missing]
The information is incomplete.
Example 2 — Impossible information
Product weight = -500 kg
The value exists, but it does not make physical sense.
Example 3 — Inconsistent information
One record says:
Country = USA
while another uses:
United States
The two may refer to the same country, but inconsistent representations can affect analysis.
Example 4 — Extreme but legitimate information
A 600-tonne wind turbine can have a very large total PCF.
That does not automatically mean the value is wrong.
This last example is particularly important.
A large PCF should be interpreted alongside the characteristics of the product, because:
[
PCF = Weight \times Carbon\ Intensity
]
Therefore:
A large number is not necessarily a poor-quality number.
This is why data quality requires several perspectives rather than one simple test.
2. Why do we need "dimensions"?
Think about a medical health check.
A doctor does not determine someone's health using only their weight.
Instead, they might consider:
- blood pressure,
- heart rate,
- temperature,
- blood tests,
- medical history,
- symptoms.
Each measure examines a different aspect of health.
Data quality works in a similar way.
A data-quality dimension represents a particular aspect of data health.
For example:
Completeness asks whether important information is present.
while:
Validity asks whether the information follows expected rules.
and:
Plausibility asks whether the values make sense in the real world.
These are different questions.
A dataset could therefore be:
100% complete
but still contain:
invalid values
or:
physically implausible values
or:
poorly documented information
This is why BEACON does not reduce data quality to a single missing-value check.
3. Where did BEACON's eight dimensions come from?
A natural question is:
"Did you just invent these eight dimensions?"
No.
But there is an important distinction.
The eight dimensions are not claimed as a new universal data-quality standard.
Instead, BEACON synthesises and adapts established data-quality concepts to the specific requirements of Product Carbon Footprint data.
The current BEACON methodology draws on established data-quality frameworks and standards including:
- Wang and Strong's data-quality framework;
- ISO/IEC 25012;
- ISO 8000;
- DAMA data-quality guidance;
- ISO 14067 for Product Carbon Footprints;
- the GHG Protocol Product Standard;
- and the Carbon Catalogue documentation.
This is important because different frameworks use different terminology and organise data quality differently.
Therefore, BEACON does not simply copy one existing framework.
It asks:
Which quality aspects are necessary for this particular PCF dataset, and which can actually be assessed objectively and automatically?
4. The three BEACON selection criteria
This is one of the strongest parts of your methodology.
A potential quality dimension was included in BEACON only when it satisfied three requirements.
1. Measurability
Can we actually measure the quality aspect?
For example:
How many values are missing?
can be measured.
2. Rule Definition
Can we define a clear rule?
For example:
Product weight must be greater than zero.
is a rule that can be tested.
3. Computability
Can the assessment be performed consistently using the BEACON software?
For example:
weight > 0
can be evaluated automatically.
These criteria make the framework more reproducible and reduce subjective judgement. The same three criteria are already established in your Feature–Dimension Mapping methodology.
5. So what are BEACON's eight dimensions?
The resulting BEACON dimensions are:
| Dimension | In simple terms |
|---|---|
| Completeness | Is the required information there? |
| Validity | Does the information follow the expected rules? |
| Consistency | Is information represented consistently? |
| Plausibility | Does it make sense in the real world? |
| Traceability | Can we understand where the information came from? |
| Timeliness | Is the information temporally appropriate? |
| Interpretability | Can a person understand what the information means? |
| Representativeness | Does the dataset adequately reflect the products, industries and regions it claims to represent? |
These definitions are consistent with the current BEACON methodology.
6. Why does each dimension matter?
1. Completeness
Imagine:
Product Weight = missing
You may not be able to properly interpret the PCF.
Completeness therefore asks:
Do we have the information needed to use the data?
2. Validity
Suppose:
Year = "banana"
or:
Weight = -50 kg
The value exists, but it does not satisfy the expected rules.
Validity asks:
Is the value structurally and logically acceptable?
3. Consistency
Suppose the same concept appears as:
USA
United States
US
or different records use incompatible representations.
Consistency asks:
Are similar pieces of information represented in a compatible way?
4. Plausibility
This is particularly important for PCF data.
Suppose we see:
PCF = 3,700,000 kg CO₂e
The number looks enormous.
But then we discover:
Product = large wind turbine
Weight = 600,000 kg
Carbon intensity ≈ 6.2 kg CO₂e/kg
The large PCF can be explained by the product's physical scale.
Therefore, plausibility is not simply:
"Is this number large?"
It is:
"Does this number make sense given the context and relationships between relevant variables?"
This insight became particularly important during the BEACON development and synthetic-data investigation.
5. Traceability
Imagine a company reports:
PCF = 2,500 kg CO₂e
but provides no information about how the number was obtained.
Can an analyst verify it?
Can another researcher reproduce it?
Traceability therefore asks:
Can the origin or methodology of the information be understood and checked?
For PCF reporting, this is particularly important because methodological information such as the reporting protocol and data source provides context for interpreting the footprint.
6. Timeliness
Carbon information can change over time.
Emission factors, technologies, manufacturing processes and reporting practices may change.
Timeliness therefore asks:
Is the temporal information appropriate for the intended use?
An important BEACON design decision is that the Carbon Catalogue is a historical/static dataset, so the freshness rule is retained in the rule library but is not meaningfully executed against the historical benchmark.
This is a good example of why not every possible quality check should automatically be applied to every dataset.
7. Interpretability
A number without context can be difficult to understand.
For example:
PCF = 500
What does 500 mean?
What product?
What functional unit?
What reporting boundary?
What methodology?
Interpretability therefore asks:
Can a human understand what the data represents?
8. Representativeness
Imagine a dataset contains products almost entirely from one country and one industry.
The dataset may be complete and internally consistent.
But can we confidently use it to represent a much broader population?
Representativeness asks:
Does the dataset provide adequate coverage of the products, industries and geographical contexts relevant to the analysis?
This is especially important for machine learning because a model can learn the characteristics of the data it receives.
7. Why not use 15 dimensions?
Another reasonable question is:
"If ISO has many characteristics, why did BEACON only use eight?"
The answer is not that eight is mathematically optimal.
Instead, BEACON uses eight because the framework is intended to provide sufficient coverage without introducing dimensions that cannot be meaningfully and reproducibly assessed for the Carbon Catalogue.
Some concepts from larger data-quality models overlap when operationalised for this dataset.
For example, several detailed technical characteristics can be represented through broader operational categories such as:
Validity
Consistency
Plausibility
rather than creating a separate BEACON dimension for every possible characteristic.
At the other extreme, using only a few broad dimensions could hide important PCF-specific concerns such as:
Traceability
Interpretability
Representativeness
Therefore, the selection was guided by:
Established research
+
PCF-specific requirements
+
Carbon Catalogue characteristics
+
Measurability
+
Rule definition
+
Computability
The resulting eight dimensions are therefore a purpose-built operational set, not a claim that all data-quality research should use exactly eight dimensions.
That distinction is important for your dissertation.
8. Why can't we just apply all eight dimensions to every column?
This leads to one of the most important ideas in BEACON:
Feature–Dimension Mapping
Consider:
Product Weight
It makes sense to ask:
Is it complete?
Is it valid?
Is it consistent?
Is it plausible?
But it makes much less sense to apply exactly the same questions to:
Product Name
For example, you can assess whether a product name is present and interpretable.
But asking whether a product name is "physically plausible" is meaningless.
Therefore:
Not every dimension applies to every feature.
BEACON explicitly maps each dataset feature to the dimensions that are relevant to it.
9. Why is the mapping table necessary?
The mapping table is not just documentation.
It is the bridge between the concept and the software.
Without the mapping, we have:
8 dimensions
and:
25 dataset features
but no systematic explanation of:
Which quality check applies to which feature?
The mapping solves this.
Conceptually:
Product Weight
↓
Completeness
Validity
Consistency
Plausibility
↓
Relevant validation rules
↓
Automated checks
while:
Product Name
↓
Completeness
Interpretability
↓
Relevant validation rules
↓
Automated checks
This makes BEACON's decisions transparent.
The current project documentation explicitly describes the mapping as the conceptual core connecting features, dimensions, validation rules, metrics and automated assessment.
10. From the mapping table to 15 rules
The mapping tells us:
What should be assessed?
The rules tell us:
How should it be assessed?
For example:
Feature
↓
Product Weight
↓
Plausibility
↓
Range Validation
↓
Is weight > 0?
Another example:
Feature
↓
PCF + Weight + Carbon Intensity
↓
Plausibility
↓
Cross-Field Validation
↓
Is PCF consistent with Weight × CI?
This is why BEACON does not contain 25 × 8 = 200 independent checks.
Instead, it uses reusable generic rule patterns.
The current methodology defines 15 rule patterns, of which 14 are executed for the historical Carbon Catalogue because R12 Freshness is not applicable in that context.
11. What are the 15 rules actually doing?
At a high level:
| Rule | What it asks |
|---|---|
| R01 Missing Value Check | Is required information present? |
| R02 Data Type Validation | Is the data stored in the expected form? |
| R03 Domain Validation | Are values within allowed domains? |
| R04 Controlled Vocabulary | Are categories represented consistently? |
| R05 Measurement Unit | Are units handled consistently? |
| R06 Range Validation | Are numerical values within reasonable ranges? |
| R07 Cross-Field Validation | Do related fields make sense together? |
| R08 Identifier Uniqueness | Are identifiers unique where required? |
| R09 Provenance Verification | Is supporting source/method information available? |
| R10 Metadata Availability | Is relevant metadata present? |
| R11 Date Validation | Are reporting dates valid? |
| R12 Freshness Assessment | Is the information sufficiently current? |
| R13 Documentation Check | Is descriptive information adequately documented? |
| R14 Category Coverage | Are relevant categories represented? |
| R15 Distribution Assessment | Is the dataset distribution sufficiently representative? |
These are generic rule patterns, not 15 completely independent algorithms. Each reusable validation function operates over the features identified by the Feature–Dimension Mapping.
12. Why does BEACON use rules instead of simply asking an analyst to inspect the data?
Because manual inspection is difficult to reproduce.
Imagine two researchers inspecting the same 866 records.
Researcher A might say:
"This looks suspicious."
Researcher B might say:
"This looks acceptable."
A rule-based framework attempts to make the decision process explicit.
For example:
IF Product Weight <= 0
THEN fail plausibility/validity check
or:
IF required field is missing
THEN fail completeness check
or:
IF PCF is inconsistent with related physical/carbon values
THEN flag for investigation
This makes the assessment:
- repeatable,
- auditable,
- explainable,
- automatable.
13. Does BEACON automatically "fix" everything?
No — and this is an important design principle.
Finding a problem and knowing the correct replacement value are two different things.
Suppose BEACON finds:
Country = "U.S.A."
and the controlled vocabulary uses:
United States
Standardisation may be straightforward.
But suppose BEACON finds:
PCF = 87,589 kg CO₂e
and determines that it is extreme.
It does not mean that BEACON should invent a new PCF value.
The correct action may be:
Investigate
or:
Flag for review
rather than:
Automatically change the number
This distinction protects the integrity of the original evidence.
14. This is particularly important for PCF data
During the BEACON development, an important issue emerged.
A large PCF value may initially appear suspicious.
For example:
600,000 kg product
+
6.2 kg CO₂e/kg
=
approximately 3.7 million kg CO₂e
The absolute PCF is very large.
But the value is explainable through the product's physical scale.
Therefore, BEACON should not simply say:
"Large PCF = bad."
Instead:
"Does the PCF make sense in relation to the relevant product and carbon characteristics?"
This is the role of domain-aware plausibility and cross-field validation.
15. What happens after all the rules run?
BEACON produces evidence at several levels.
Individual validation
↓
Rule score
↓
Dimension score
↓
Overall BEACON Quality Score
For example:
R06 Range Validation
↓
62.63%
R07 Cross-Field Validation
↓
84.99%
These are then aggregated into dimension-level scores and ultimately the overall score.
Your current implementation produces a Rule Evaluation Matrix, dimension scores, and an Issue Register.
16. Why have an overall score if the individual rules are more informative?
The overall score provides a summary.
Imagine a manager wants a quick answer:
"How strong is this dataset overall?"
A single score is useful.
But an overall score alone is insufficient for diagnosis.
Therefore BEACON deliberately provides both:
Overall score
+
Dimension scores
+
Rule scores
+
Issue-level evidence
Think of it like a medical check-up again.
You might receive:
Overall health assessment: Good
but the doctor still tells you:
Blood pressure needs attention.
The summary and the detailed diagnosis serve different purposes.
17. Why is the mapping table so important to the whole architecture?
Because it creates a chain of accountability:
Research literature
↓
Quality dimension
↓
BEACON feature
↓
Feature–Dimension Mapping
↓
Validation rule
↓
Metric
↓
Python implementation
↓
Evidence
↓
Quality score
Every important decision can therefore be traced backwards.
For example, an examiner can ask:
"Why did you assess Product Weight for plausibility?"
You can answer:
Product Weight
↓
Physical characteristic
↓
Plausibility applicable
↓
Range rule
↓
Physical/empirical threshold
↓
Automated validation
That is far stronger than saying:
"We thought it would be useful."
18. Why eight dimensions rather than five?
With only five broad dimensions, some PCF-specific concerns could become hidden.
For example:
Traceability
could disappear inside a broad "quality" category.
Likewise:
Representativeness
is important when a dataset is used for machine learning across industries and countries.
BEACON therefore keeps these concepts visible because they have different practical implications.
19. Why not twelve?
The opposite problem is fragmentation.
If every subtle characteristic became its own dimension, the framework could become:
harder to implement
harder to explain
harder to score
harder to maintain
and potentially contain overlapping concepts.
BEACON therefore groups related quality concerns where they can be assessed through a common operational concept.
Again, the important claim is not:
"Eight is universally optimal."
The defensible claim is:
"Eight dimensions provided the selected operational coverage required for the Carbon Catalogue while meeting the predefined measurability, rule-definition and computability criteria."
That is the wording I would use in your dissertation.
20. What does this mean for machine learning?
This is ultimately why BEACON exists in your project.
Machine learning models learn patterns from the data they receive.
If the input contains:
missing values
inconsistent categories
invalid values
poorly documented observations
unrepresentative distributions
then the model may learn patterns that do not generalise well.
BEACON therefore sits before the ML stage:
PCF Data
↓
BEACON
↓
Quality assessment
↓
Quality treatment
↓
Reassessment
↓
ML-ready dataset
↓
Machine Learning
Your research then asks whether this quality-assurance process actually changes predictive performance.
That is where your RQ3 becomes important.
21. The final BEACON idea in one picture
PRODUCT CARBON DATA
│
▼
"Can we trust this?"
│
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Completeness Validity Consistency
│ │ │
├───────────────┼────────────────┤
│ │ │
▼ ▼ ▼
Plausibility Traceability Timeliness
│ │ │
└───────────────┼────────────────┘
│
Interpretability
│
Representativeness
│
▼
FEATURE–DIMENSION
MAPPING
│
▼
15 RULES
│
▼
AUTOMATED CHECKS
│
▼
QUALITY EVIDENCE
│
┌───────────┴───────────┐
▼ ▼
Score / Diagnose Issue Register
│
▼
Justified Treatment
│
▼
Reassess
│
▼
ML EVALUATION
22. The key message for a non-technical reader
If someone remembers only one thing from this article, it should be this:
Good data is not simply data with no empty cells.
For Product Carbon Footprints, good-quality data should be:
complete enough to use, valid enough to trust, consistent enough to compare, plausible enough to make sense, traceable enough to verify, timely enough for its purpose, understandable enough to interpret, and representative enough for the population being studied.
BEACON brings these perspectives together into a structured assessment process.
The eight dimensions are not claimed as a universal replacement for existing data-quality standards. They are a PCF-focused synthesis, selected from established research and standards and filtered according to whether they can be measured, expressed as rules and implemented computationally.
And the Feature–Dimension Mapping is the key bridge: it prevents BEACON from applying arbitrary checks to every column and instead establishes which quality questions are meaningful for each type of PCF information.
Top comments (0)