Within the MT Analytics Engine, Total Addressable Market is not a single value. It is a governed family of related market measurements that describe the maximum potential market from different analytical perspectives.
The principal TAM measures are:
Population or Cohort TAM Go To
The number of people, households, consumer units, establishments, or other entities that satisfy a governed market definition. Expressed in: people or households
Consumer-Demand TAM Go To
The modeled annual expenditure that an eligible consumer population could direct toward the selected product or service category. Expressed in: annual dollars
Industry-Revenue TAM Go To
The supplier-side receipts associated with the selected product, industry, geography, and economic layer. Expressed in: supplier receipts
Real-Dollar TAM Go To
A nominal consumer-demand TAM restated in the dollars of a common base period.
Reconciled TAM Go To
A governed comparison or combination of consumer-demand and industry-revenue TAM. A reconciled TAM is a governed analytical comparison between market perspectives.
The engine examines the market through two primary analytical forks:
The user fork describes potential demand. It begins with people, households, demographic cohorts, consumer units, income, and expenditure behavior.
The vendor fork describes the businesses, establishments, workers, receipts, and productive footprint through which products and services are supplied.
These forks are connected, but they answer different questions.
| Fork | Primary question |
|---|---|
| User | Who could purchase or participate, and what expenditure could they support? |
| Vendor | Which businesses could supply, distribute, host, promote, or purchase the offering? |
A single market may therefore have several valid TAM values:
Eligible households: 250,000 households
Eligible people: 620,000 people
Consumer-demand TAM: $180 million per year
Industry-revenue TAM: $205 million per year
Retail establishments: 4,800 establishments
None of these values replaces the others. Each represents a different part of the market model.
The system supports:
The geographic layers must not be assumed to be arithmetically interchangeable.
A state observation is not necessarily equal to the sum of its county observations. Differences may result from:
Counts may sometimes be aggregated across non-overlapping geographies. Rates, averages, percentages, and indexed values generally cannot be added.
The calculation must therefore identify its source geography level explicitly:
us
state
county
The system records the exact geography identifiers used in each immutable input snapshot.
The American Community Survey 5-year estimates provide the primary demographic and household foundation for the user fork.
ACS supports:
ACS is used for:
ACS estimates are stored with their published margins of error. The application retains both values when calculating population TAM.
Representative warehouse relations include:
norm.acs5_2024_us
norm.acs5_2024_st
norm.acs5_2024_co
The BLS Consumer Expenditure Survey provides annual expenditure behavior by consumer-unit and demographic category.
CEX is used to answer:
How much does an eligible consumer unit normally spend in the relevant product or service category?
CEX supplies expenditure values used in:
Representative warehouse relation:
norm.bls_cex
CEX expenditure is not treated as direct local sales. It is localized by applying broader expenditure behavior to the selected ACS population.
The Economic Census provides employer-business activity and product receipts.
ECN supplies:
ECN is the principal source for:
Representative warehouse relations include:
norm.ecn_2022_us
norm.ecn_2022_st
norm.ecn_2022_co
County Business Patterns provides annual structural information about employer establishments.
CBP supplies:
CBP does not normally provide the same product-receipt detail as the Economic Census. Its principal role is to describe the physical and employment structure of the supplier market.
Representative warehouse relations include:
norm.cbp_2023_us
norm.cbp_2023_st
norm.cbp_2023_co
CBP should not be added to Economic Census receipts as though it were an additional revenue source. CBP complements ECN by describing how employer activity is distributed across establishments and workers.
Nonemployer Statistics describe businesses with receipts but no paid employees.
NES captures:
Representative warehouse relations include:
norm.nes_2023_us
norm.nes_2023_st
norm.nes_2023_co
NES is used to represent the nonemployer portion of the supplier market that is absent from CBP.
ECN and NES may be combined only when:
The application does not treat all ECN, CBP, and NES values as directly additive.
The Consumer Price Index and Producer Price Index provide price-period adjustment.
CPI is used to:
PPI is used to:
Representative warehouse relations:
norm.bls_cpi
norm.bls_ppi
The analytical sources do not always use the same NAICS edition.
For example:
The engine uses governed crosswalks to reconcile these differences.
Representative reference object:
ref.dim_naics_xwalk
Crosswalks must preserve:
A taxonomy match is not assumed merely because two labels appear similar.
The user fork describes the potential consumer population and its economic capacity.
It answers:
The user fork begins with one or more population or household TAM calculations.
It may then produce:
The vendor fork describes the business population with which Magic Toybox may transact or through which the consumer offering may be delivered.
The initial vendor scope filters the supplier market to:
NAICS 44-45 — Retail Trade
This is a governed starting assumption. It remains open to validation and expansion.
The vendor scope may later include additional industries such as:
estab — EstablishmentsThe number of physical or operational establishments within the selected geography and industry.
One firm may operate multiple establishments.
firm — FirmsThe number of legal or enterprise organizations operating within the selected geography and industry.
A firm may control several establishments.
emp — EmploymentThe number of employees associated with the selected geography and industry.
payann — Annual PayrollAnnual payroll, commonly reported in thousands of dollars.
rcptot — Total ReceiptsTotal sales, shipments, receipts, revenue, or business activity, commonly reported in thousands of dollars.
rcptot is a total measure, not an average-revenue measure.
Average receipts per establishment may be derived as:
[
AverageReceiptsPerEstablishment =
\frac{TotalReceipts}{Establishments}
]
taxstat — Tax StatusThe tax-status classification applicable to the establishment, firm, or source observation, such as taxable or tax-exempt status.
Vendor data supports:
Population TAM answers:
How many people, households, or consumer units satisfy the governed market definition?
The Rust warehouse implementation supports three algorithms.
This method is used when the selected ACS measure is directly additive across the selected non-overlapping geographies.
For geographies (g):
[
TAM = \sum_g Estimate_g
]
ACS margins of error are converted into standard errors:
[
SE_g = \frac{MOE_g}{1.645}
]
The combined standard error is:
[
SE_{total} = \sqrt{\sum_g SE_g^2}
]
The approximate 95 percent interval is:
[
Lower = \max(0, TAM - 1.96SE_{total})
]
[
Upper = TAM + 1.96SE_{total}
]
tam.warehouse_acs_metric_sum.v1
Request model:
src/analytics/shared/warehouse_models.rs
Validation and source materialization:
src/analytics/shared/warehouse_store.rs
The additive aggregation and margin-of-error calculation are implemented in the active warehouse_store.rs module.
Frozen input:
analytics.calculation_input_snapshot
Individual ACS source components:
analytics.calculation_input_component
Run:
analytics.calculation_run
Final result:
analytics.calculation_run_result
Frozen method:
analytics.calculation_run_methodology
Ordered transformation lineage:
analytics.calculation_run_lineage
This method is used when one ACS table cell directly represents the full governed cohort.
For example, the selected measure might already describe:
The formula is:
[
TAM = \sum_g JointEstimate_g
]
The same ACS margin-of-error treatment used by the additive method is applied.
tam.warehouse_acs_joint_metric.v1
The materialization request must include a substantive explanation of why the selected measure represents the complete joint cohort.
This rationale is stored with the frozen snapshot.
A marginal demographic measure must not be labeled as a joint cohort. The source measure must represent the complete intersection required by the market definition.
This method is used when a direct joint-cohort ACS estimate does not exist.
For geography (g):
[
Adjusted_g =
Base_g
\times
\prod_i Ratio_{g,i}
]
Each ratio is:
[
Ratio_{g,i} =
\frac{
\sum NumeratorMetric_{g,i}
}{
\sum DenominatorMetric_{g,i}
}
]
The total is:
[
TAM = \sum_g Adjusted_g
]
An illustrative model might be:
Total households
× share with children
× share above income threshold
× share in selected age cohort
tam.warehouse_acs_ratio_chain.v1
The numerator, denominator, ratio, and adjusted geography value are calculated in:
src/analytics/shared/warehouse_store.rs
The current ratio-chain algorithm does not generate a formal confidence interval.
A defensible interval would require covariance information or a direct joint estimate. The result must therefore be described as an approximation.
Consumer-demand TAM answers:
What annual expenditure could the eligible population direct toward the governed product or service category?
It combines local ACS household evidence with Consumer Expenditure Survey behavior.
For each geography, segment, and product mapping:
[
Contribution =
H
\times W_g
\times W_m
\times W_b
\times F_{cu}
\times E
\times W_p
\times W_x
]
Where:
| Symbol | Meaning |
|---|---|
| (H) | Eligible ACS households |
| (W_g) | Geography inclusion weight |
| (W_m) | Market-segment weight |
| (W_b) | ACS-to-CEX demographic bridge |
| (F_{cu}) | Household-to-consumer-unit equivalency factor |
| (E) | Annual CEX expenditure per consumer unit |
| (W_p) | Product-scope weight |
| (W_x) | CEX UCC-to-NAPCS allocation weight |
Total consumer-demand TAM is:
[
ConsumerTAM = \sum Contribution
]
Consumer-demand TAM is:
It is not:
The active Rust warehouse modules do not calculate the complete consumer-demand formula.
The canonical implementation is established in the PostgreSQL analytics migrations, including:
20260701_006_consumer_tam_engine_up.sql
Primary metric key:
consumer_tam_cex_acs_v1
Calculation run:
analytics.metric_calculation_run
Component-level evidence:
analytics.consumer_tam_component
Final result:
analytics.market_size_result
Diagnostics:
analytics.metric_run_diagnostic
The component table stores:
The current consumer-demand model is intentionally capped at confidence grade C.
This reflects the fact that national or regional expenditure behavior is being localized to a specific population.
Confidence may be reduced by:
Industry-revenue TAM answers:
How much supplier-side revenue or receipts are reported for the selected product, industry, geography, and economic layer?
This is the principal supply-side dollar TAM.
For each industry-revenue component:
[
Contribution =
ReportedReceipts
\times GeographyWeight
\times ProductScopeWeight
]
Total:
[
IndustryTAM = \sum Contribution
]
The preferred source is Economic Census product receipts.
The calculation must define:
The application selects one declared economic layer, such as:
This prevents multiple stages of the same value chain from being added together and counted as separate market demand.
Primary migration:
04_industry_revenue_tam_and_reconciliation.sql
Primary metric key:
industry_revenue_tam_ecn_v1
Input binding:
analytics.industry_revenue_tam_input_binding
Component-level evidence:
analytics.industry_revenue_tam_component
Run:
analytics.metric_calculation_run
Final result:
analytics.market_size_result
Each component records:
Industry-revenue TAM is not automatically equivalent to consumer-demand TAM.
Differences may result from:
A nominal TAM calculated in one period cannot always be compared directly with a TAM calculated in another period.
The real-dollar TAM engine restates consumer-demand TAM into a common price base.
For each nominal component:
[
RealContribution =
NominalContribution
\times
\frac{
BasePeriodIndex
}{
ObservationPeriodIndex
}
]
The total is:
[
RealTAM = \sum RealContribution
]
Primary migration:
20260701_008_price_deflation_engine_up.sql
Primary execution function:
analytics.run_consumer_tam_real_v1(...)
Price-series registry:
analytics.price_series
Price observations:
analytics.price_series_observation
Market-specific binding:
analytics.price_adjustment_binding
Component-level adjustment:
analytics.consumer_tam_real_component
Final result:
analytics.market_size_result
Bindings may be classified as:
Broad fallback mappings reduce confidence.
Real TAM changes the dollar basis of the result. It does not change:
Consumer-demand TAM and industry-revenue TAM provide different views of the same broad market.
The reconciliation engine compares these perspectives without assuming that either is automatically correct.
[
GapRatio =
\frac{
|ConsumerTAM - IndustryTAM|
}{
\max(ConsumerTAM, IndustryTAM)
}
]
The two TAM values are compared, but no combined point estimate is produced.
[
ReconciledTAM = ConsumerTAM
]
[
ReconciledTAM = IndustryTAM
]
[
ReconciledTAM =
ConsumerTAM \times ConsumerWeight
+
IndustryTAM \times IndustryWeight
]
Where:
[
ConsumerWeight + IndustryWeight = 1
]
Primary migration:
04_industry_revenue_tam_and_reconciliation.sql
Configuration:
analytics.tam_reconciliation_configuration
Result component:
analytics.tam_reconciliation_component
Run:
analytics.metric_calculation_run
Final reconciled market-size result, where applicable:
analytics.market_size_result
The engine verifies:
The default mode is comparison only. The system does not silently average unrelated values.
Economic Census receipts provide the principal supplier-side dollar measure.
CBP provides structural context:
The relationship is complementary rather than additive.
ECN:
How much employer business activity occurred?
CBP:
How many establishments and workers make up that activity?
CBP may be used to calculate:
It is not added to ECN receipts.
NES captures nonemployer activity that is absent from CBP.
NES may be combined with employer evidence when:
Within the current SOM capacity model, ECN and NES receipt-derived proxies may be combined into one candidate public-capacity ceiling.
This is a proxy calculation, not a direct industry-revenue TAM rule.
ACS describes the local eligible population.
CEX describes broader expenditure behavior.
Together they form the consumer-demand TAM:
Local eligible households
× expenditure behavior
× product allocation
= modeled annual consumer-demand TAM
ACS income and population values may be used as a demand-side plausibility check.
However, consumer income and supplier receipts are not expected to match exactly because:
ACS validation should therefore detect implausible magnitude or scope, rather than enforce equality.
SAM is the portion of TAM that is serviceable by the governed offering at a particular price.
The system first localizes an annual product budget.
[
CPIRatio =
\frac{TargetPeriodCPI}{BasePeriodCPI}
]
[
AdjustedCEX =
ObservedCEX \times CPIRatio
]
[
ConsumerUnits =
\frac{
TAMPopulation
}{
PeoplePerConsumerUnit
}
]
[
ProductBudget =
AdjustedCEX
\times CategoryCaptureRate
]
[
Q_0 =
\frac{
ConsumerUnits
\times ProductBudget
\times ParticipationRate
}{
ReferencePrice
}
]
The SAM baseline is calculated in:
src/analytics/shared/warehouse_sam_store.rs
Request contract:
src/analytics/shared/warehouse_sam_models.rs
The Rust layer:
The full price curve is executed by the migration-managed PostgreSQL function:
analytics.execute_warehouse_sam_run(...)
[
Q(P) =
Q_0
\left(
\frac{P}{P_0}
\right)^\epsilon
]
Algorithm key:
sam.warehouse_constant_elasticity.v1
[
Q(P) =
\max\left(
0,
Q_0
\left[
1 +
\epsilon
\frac{P-P_0}{P_0}
\right]
\right)
]
Algorithm key:
sam.warehouse_linear_elasticity.v1
[
AnnualOfferCost =
P \times VisitsPerBuyer
]
[
Affordability =
\frac{
1
}{
1 +
\exp\left[
k
\frac{
AnnualOfferCost-ProductBudget
}{
ProductBudget
}
\right]
}
]
Algorithm key:
sam.warehouse_logistic_affordability.v1
Shared input snapshot:
analytics.calculation_input_snapshot
Inputs and assumptions:
analytics.calculation_input_component
Run:
analytics.calculation_run
Price curve:
analytics.calculation_run_curve_point
Selected-price result:
analytics.calculation_run_result
The current engine performs price-scenario analysis, rather than autonomous price selection.
For every governed price point, it calculates:
[
Supply(P) =
\max\left(
0,
BaseSupply +
(P-P_0)\times SupplySlope
\right)
]
[
UnitCost(P) =
\max\left(
0,
BaseUnitCost \times PPIRatio
+
(P-P_0)\times CostSlope
\right)
]
[
Revenue(P) = Q(P)\times P
]
Q(P)\times UnitCost(P)
]
[
MarketGap(P) =
Supply(P)-Q(P)
]
The application currently requires a selected price as an input. It does not automatically designate one point as the optimal price.
The curve can be analyzed for:
The price curve is stored in:
analytics.calculation_run_curve_point
SOM is the portion of SAM that can be obtained after applying:
[
QualifiedPeople =
\min(
SAMBuyers,
PlannedReach
)
\times QualificationRate
]
[
ForecastBuyers =
QualifiedPeople
\times ConversionRate
]
[
ForecastUnits =
ForecastBuyers
\times VisitsPerBuyer
]
[
CBPProxy =
Establishments
\times UnitsPerEstablishment
+
Employment
\times UnitsPerEmployee
]
[
ECNProxy =
\frac{
Receipts
\times ReceiptsUnitMultiplier
}{
RevenuePerUnit
}
]
[
NESProxy =
\frac{
Receipts
\times ReceiptsUnitMultiplier
}{
RevenuePerUnit
}
]
These calculations are implemented in:
src/analytics/shared/warehouse_som_vct_store.rs
[
PublicCap =
PositiveMinimum(
CBPProxy,
ECNProxy + NESProxy
)
]
[
SOMUnits =
\min(
SAMDemand,
CampaignForecast,
OpenCapacity,
PublicCap
)
]
Algorithm key:
som.warehouse_conservative_min.v1
[
WeightedProxy =
\frac{
CBPProxy\times w_{cbp}
+
ECNProxy\times w_{ecn}
+
NESProxy\times w_{nes}
}{
w_{cbp}+w_{ecn}+w_{nes}
}
]
[
OperationalCap =
OpenCapacity
\times UtilizationRate
]
[
PublicCap =
WeightedProxy
\times UtilizationRate
]
[
SOMUnits =
\min(
SAMDemand,
CampaignForecast,
OperationalCap,
PublicCap
)
]
Algorithm key:
som.warehouse_weighted_capacity.v1
Run:
analytics.calculation_run
Frozen inputs:
analytics.calculation_input_snapshot
analytics.calculation_input_component
Candidate and binding constraints:
analytics.calculation_run_constraint
Final result:
analytics.calculation_run_result
The binding constraint is stored explicitly. The frontend should not attempt to infer it independently.
The Vendor Campaign Target converts a market result into a contactable campaign-planning audience.
[
VCT =
SAMBuyers
\times ContactableRate
]
Algorithm key:
vct.sam_contactable.v1
[
VCT =
SOMBuyers
\times ContactableRate
]
Algorithm key:
vct.som_contactable.v1
analytics.vendor_campaign_target
The record contains:
VCT is not a count of:
It is the governed contactable universe available for campaign planning.
The application distinguishes between assumed elasticity and empirical elasticity evidence.
The elasticity used by the SAM algorithms is supplied as a model input.
Rust request field:
MaterializeWarehouseSamRequest.elasticity
Defined in:
src/analytics/shared/warehouse_sam_models.rs
Stored as an assumption in:
analytics.calculation_input_component
It may originate from:
It is not automatically treated as a locally observed elasticity.
The canonical analytics schema supports a log-log price and quantity model:
[
\ln(Q) =
\alpha +
\beta\ln(P) +
\varepsilon
]
The slope is:
[
\beta =
\frac{
Cov(\ln P,\ln Q)
}{
Var(\ln P)
}
]
Primary migration:
20260701_011_elasticity_evidence_layer_up.sql
Primary schema:
analytics.sales_observation
analytics.competitor_price_observation
analytics.elasticity_model_specification
analytics.elasticity_dataset_build
analytics.elasticity_model_observation
analytics.elasticity_model_result
The in-database estimator is labeled as an:
uncontrolled log-log price/quantity association
It must not be described as causal elasticity without an approved identification strategy.
Controlled estimates may be calculated externally and registered with:
The active analytics code is located under:
src/analytics/
Historical backup directories must not be treated as current implementation.
The server maintains:
db_generic
db_warehouse
db_warehouse reads normalized Census and BLS data.
db_generic stores analytics definitions, snapshots, runs, lineage, and results.
Relevant files:
src/main.rs
src/state.rs
src/analytics/shared/warehouse_connections.rs
TAM, SAM, SOM, and VCT routes are registered in:
src/analytics/routes.rs
API handlers include:
src/analytics/api/warehouse.rs
src/analytics/api/warehouse_sam.rs
src/analytics/api/warehouse_som_vct.rs
Calculation dispatch is implemented in:
src/analytics/shared/jobs/worker.rs
The worker directs:
TAM → warehouse TAM execution
SAM → warehouse_sam workflow command
SOM / VCT → warehouse_som_vct workflow command
TAM and general calculations use:
src/analytics/shared/database_functions.rs
SAM, SOM, and VCT use:
src/analytics/shared/workflow_command_store.rs
Rust inserts a typed command. A migration-installed PostgreSQL trigger invokes the corresponding database executor.
This means that successful Rust compilation alone does not prove that all analytical functions are installed or current in PostgreSQL.
analytics.market_target
analytics.market_target_version
analytics.calculation_pattern
analytics.analytic_mapping
analytics.criterion_binding
analytics.source_dataset
analytics.warehouse_object
analytics.calculation_input_snapshot
analytics.calculation_input_component
analytics.calculation_run_input_snapshot
analytics.warehouse_query_execution
analytics.warehouse_validation_run
analytics.warehouse_validation_check
analytics.warehouse_source_coverage
analytics.calculation_run
analytics.calculation_execution_command
analytics.workflow_execution_command
analytics.calculation_run_result
analytics.calculation_run_curve_point
analytics.calculation_run_constraint
analytics.calculation_run_methodology
analytics.calculation_run_lineage
analytics.vendor_campaign_target
analytics.metric_definition
analytics.metric_calculation_run
analytics.market_size_result
analytics.metric_run_diagnostic
analytics.consumer_tam_component
analytics.consumer_tam_real_component
analytics.industry_revenue_tam_component
analytics.tam_reconciliation_component
analytics.supplier_footprint_result
analytics.market_pressure_result
analytics.elasticity_model_result
Every value should be classified according to its origin.
| Classification | Meaning | Example |
|---|---|---|
| Observed | Directly reported source value | ACS households |
| Assumption | Analyst- or business-supplied parameter | Participation rate |
| Derived | Deterministic calculation | CPI ratio |
| Proxy | Indirect estimate based on observations and assumptions | ECN capacity proxy |
| Prior result | Output from an upstream governed calculation | TAM population used by SAM |
The source classifications are stored in:
analytics.calculation_input_component.origin_type
The complete chain is:
TAM
Maximum population, spending, receipt, or supplier universe
SAM
Portion of TAM that is suitable for the offering at a selected price
SOM
Portion of SAM obtainable under campaign and operational constraints
VCT
Contactable portion of SAM or SOM
More formally:
[
TAM
\rightarrow
SAM(P)
\rightarrow
SOM(P, Campaign, Capacity)
\rightarrow
VCT
]
The boundaries are:
Defined by:
Defined by TAM plus:
Defined by SAM plus:
Defined by SAM or SOM plus:
Analysts should use precise labels.
rcptot.The present implementation includes several deliberate modeling boundaries.
Consumer-demand TAM localizes broader CEX behavior.
It is not directly observed local expenditure.
Ratio-chain population TAM is approximate.
It does not produce a formal confidence interval.
SAM elasticity is normally an assumption.
It is not automatically populated from reviewed transaction evidence.
Supply and cost slopes are assumptions.
PPI adjusts the base cost, but the full cost schedule is not discovered from public data.
Public producer capacity is a proxy.
CBP, ECN, and NES do not report directly bookable units.
Selected price is an input.
The price grid is evaluated, but the server does not yet automatically select an optimum.
Two calculation-run systems coexist.
Warehouse calculations use analytics.calculation_run; canonical domain metrics use analytics.metric_calculation_run.
Database migrations contain executable analytical logic.
The Rust code alone is not the complete analytical implementation.
Before accepting or publishing a TAM value:
The MT Analytics Engine does not reduce the market to one undifferentiated TAM value.
It maintains a connected set of market perspectives:
Population and household universe
↓
Consumer spending opportunity
↔
Supplier revenue opportunity
↓
Real-dollar comparison and reconciliation
↓
Price-specific serviceable market
↓
Campaign- and capacity-constrained obtainable market
↓
Contactable vendor campaign target
This structure allows the application to explain not only how large a market may be, but also: