DEV Community

Cover image for BEACON-01
Sajjad Rahman
Sajjad Rahman

Posted on

BEACON-01

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]
Enter fullscreen mode Exit fullscreen mode

The information is incomplete.

Example 2 — Impossible information

Product weight = -500 kg
Enter fullscreen mode Exit fullscreen mode

The value exists, but it does not make physical sense.

Example 3 — Inconsistent information

One record says:

Country = USA
Enter fullscreen mode Exit fullscreen mode

while another uses:

United States
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

but still contain:

invalid values
Enter fullscreen mode Exit fullscreen mode

or:

physically implausible values
Enter fullscreen mode Exit fullscreen mode

or:

poorly documented information
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

can be measured.

2. Rule Definition

Can we define a clear rule?

For example:

Product weight must be greater than zero.
Enter fullscreen mode Exit fullscreen mode

is a rule that can be tested.

3. Computability

Can the assessment be performed consistently using the BEACON software?

For example:

weight > 0
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

or:

Weight = -50 kg
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The number looks enormous.

But then we discover:

Product = large wind turbine
Weight = 600,000 kg
Carbon intensity ≈ 6.2 kg CO₂e/kg
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Therefore, the selection was guided by:

Established research
       +
PCF-specific requirements
       +
Carbon Catalogue characteristics
       +
Measurability
       +
Rule definition
       +
Computability
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

It makes sense to ask:

Is it complete?
Is it valid?
Is it consistent?
Is it plausible?
Enter fullscreen mode Exit fullscreen mode

But it makes much less sense to apply exactly the same questions to:

Product Name
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and:

25 dataset features
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

while:

Product Name
      ↓
Completeness
Interpretability
      ↓
Relevant validation rules
      ↓
Automated checks
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

Another example:

Feature
   ↓
PCF + Weight + Carbon Intensity
   ↓
Plausibility
   ↓
Cross-Field Validation
   ↓
Is PCF consistent with Weight × CI?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

or:

IF required field is missing
THEN fail completeness check
Enter fullscreen mode Exit fullscreen mode

or:

IF PCF is inconsistent with related physical/carbon values
THEN flag for investigation
Enter fullscreen mode Exit fullscreen mode

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."
Enter fullscreen mode Exit fullscreen mode

and the controlled vocabulary uses:

United States
Enter fullscreen mode Exit fullscreen mode

Standardisation may be straightforward.

But suppose BEACON finds:

PCF = 87,589 kg CO₂e
Enter fullscreen mode Exit fullscreen mode

and determines that it is extreme.

It does not mean that BEACON should invent a new PCF value.

The correct action may be:

Investigate
Enter fullscreen mode Exit fullscreen mode

or:

Flag for review
Enter fullscreen mode Exit fullscreen mode

rather than:

Automatically change the number
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

R06 Range Validation
        ↓
62.63%

R07 Cross-Field Validation
        ↓
84.99%
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

could disappear inside a broad "quality" category.

Likewise:

Representativeness
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)