Reference
Exact operational and technical reference for GeoSC.
Exact operational and technical reference for GeoSC.
Technical reference for the shipped GeoSC interfaces.
Primary operational interface:
geosc CLI and compatibility geolift CLIProgrammatic interface:
GeoLiftAnalyzerload_configload_and_prepare_dataprocess_sparse_sc_resultsCompatibility interfaces:
runme.pyrecipes/For the exact CLI command surface, see CLI Reference.
Installed commands:
geosc powergeosc donorsgeosc infergeosc pipelineShared flags on all commands:
--config--output-dir--jobs--use-gpu--no-progress--quietInfer-only flags:
--data--create-plots--no-create-plotsPipeline-only flags:
--skip-power--skip-donor--only-inference--report--no-reportPipeline config contract:
pipeline --config accepts one canonical stage YAML pathGeoLiftAnalyzerMain orchestration class for causal inference analysis using SparseSC-backed estimation.
Initialization modes:
config_path plus data_pathoutcomes_df plus unit_treatment_periodsFile-based example with user-owned config and data paths:
Source-checkout example:
Direct-data example:
run_geolift_analysis()Executes the full inference workflow and returns the compact top-level results dictionary.
Returned fields include:
schema_versionstatusattp_valuep_value_methodn_placebosmax_n_placebospossible_placebosp_value_placebo_modeplacebo_seedci_lowerci_uppercisese_availablese_approx_from_cise_approx_availablese_approximation_methodsignificantsignificance_availableassumption_statusassumption_requiredassumption_checks_runassumption_checks_completedDetailed diagnostics remain on analyzer.diagnostics. Assumption validation is
available on analyzer.assumption_validation and, when output_dir is set, in
assumption_validation.json.
analyzer.diagnostics["inference"] records the estimator method, placebo mode,
seed, requested placebo count, possible combinations, and effective placebo
count. The seed is material only when the placebo mode is sampled.
For the 0.3.0 beta, these public wrapper semantics are release-certified by
the statistical certification gate in scripts/verify_release_candidate.py.
That gate covers SparseSC parity, deterministic effect recovery,
timing/orientation, artifact parity, uncertainty and placebo metadata, donor
design-stage semantics, power failure accounting, assumption-validator status
metadata, and release-preflight schema regressions. It does not certify that a
specific campaign satisfies causal-design assumptions.
run_analysis()Primary convenience entry point that delegates to run_geolift_analysis().
Either method is valid on the shipped class.
plot_results(output_path: str | None = None) -> strGenerates and saves the uplift time-series plot. When output_path is omitted,
the plot is written to <output_dir>/uplift_timeseries.png.
load_and_prepare_data(...)File-based data preparation helper used by the analyser path.
load_config(path)Loads one YAML config file.
process_sparse_sc_results(sparse_sc_results, config)Transforms SparseSC outputs into the compact top-level results plus the richer diagnostics payload.
Inference outputs:
geolift_results.jsongeolift_diagnostics.jsondata_validation.jsonassumption_validation.jsonuplift_timeseries.png when plot generation is enabledPower outputs:
power_analysis_results.csvpower_curves.pngPower CSV rows include reproducibility and failure fields such as
random_seed, n_failed, failure_rate, valid, dgp_rank, and
requested_max_n_pl, possible_placebos, effective_max_n_pl,
dgp_backend, and generation_backend.
Donor outputs:
donor_eval_results.csvdonor_pool_quality.jsondonor_map_*.pngPipeline reports:
geolift_pipeline_report.mdgeolift_pipeline_report.htmlrunme.py and the scripts in recipes/ remain available for compatibility.
They are not the primary documented interface.
Migration map:
python runme.py -> geosc pipeline --config data-config/geolift_analysis_config.yamlpython recipes/power_calculator_sparsesc.py ... -> geosc power ...python recipes/donor_evaluator.py ... -> geosc donors ...python recipes/geolift_multi_cell.py ... -> geosc infer ...Canonical reference for the installed geosc command surface. The legacy
geolift command remains available as a compatibility alias during the beta.
Examples below use source-tree config paths such as data-config/... when that
helps illustrate the shipped demo workflow. Built wheel and sdist installs do
not include data-config/; packaged users should supply their own YAML config
paths.
Installed subcommands:
geosc powergeosc donorsgeosc infergeosc pipelineAll commands accept:
--config CONFIG--output-dir OUTPUT_DIR--jobs JOBS--use-gpu--no-progress--quietSemantics:
--config points to the YAML configuration file for the command--output-dir overrides the configured output directory for stage commands--jobs overrides n_jobs--use-gpu is meaningful for power analysis--no-progress disables progress output--quiet reduces non-critical output without hiding errorsgeosc powerSource-checkout example:
Purpose:
Typical outputs:
power_analysis_results.csvpower_curves.pngpower_analysis_results.csv includes failure_rate and valid; invalid rows
should not be used for recommendations.
geosc donorsSource-checkout example:
Purpose:
Typical outputs:
donor_eval_results.csvdonor_pool_quality.jsondonor_map_*.pnggeosc inferPackaged-install example:
Source-checkout example:
Infer-only flags:
--data DATA--create-plots--no-create-plotsSemantics:
--data overrides the CSV path defined in YAML--create-plots forces plot generation--no-create-plots disables plot generationTypical outputs:
geolift_results.jsongeolift_diagnostics.jsonuplift_timeseries.png when plots are enabledgeosc pipelinePackaged-install example:
Source-checkout example:
Pipeline-only flags:
--skip-power--skip-donor--only-inference--report--no-reportPipeline config contract:
--config is an anchor to one canonical stage YAML filepower_analysis_config.yamldonor_eval_config.yamlgeolift_analysis_config.yamlpipeline --stageStage-selection semantics:
--skip-power skips power analysis--skip-donor skips donor evaluation--only-inference skips both earlier stagesReport semantics:
--report forces report generation explicitly--no-report suppresses report generationOutput-root semantics:
This preserves the legacy stage/report layout under the supplied root:
results/campaign_a/multicell_power_analysis/results/campaign_a/multicell_donor_eval/results/campaign_a/multicell_geolift_analysis/results/campaign_a/geolift_pipeline_report.mdresults/campaign_a/geolift_pipeline_report.html| Legacy source-checkout command | Preferred command |
|---|---|
python runme.py |
geosc pipeline --config data-config/geolift_analysis_config.yaml |
python recipes/power_calculator_sparsesc.py --config data-config/power_analysis_config.yaml --use-gpu --jobs -1 |
geosc power --config data-config/power_analysis_config.yaml --use-gpu --jobs -1 |
python recipes/donor_evaluator.py --config data-config/donor_eval_config.yaml |
geosc donors --config data-config/donor_eval_config.yaml |
python recipes/geolift_multi_cell.py --config data-config/geolift_analysis_config.yaml |
geosc infer --config data-config/geolift_analysis_config.yaml |
runme.py remains available as a compatibility wrapper. recipes/ remain
available for migration and legacy stage-specific workflows.
GeoSC uses flat YAML keys for its configuration.
The example below reflects the supported YAML shape. The data-config/
directory is a source-tree example asset, not a packaged runtime asset, so
built wheel and sdist installs should replace those demo paths with user-owned
config and data paths.
Below are the standard configuration keys used in
geolift_analysis_config.yaml:
cooldown_periods excludes an initial post-launch transition window from effect
measurement. It defaults to 0, which preserves the existing behavior where the
measurement window starts on intervention_date_str.
Cooldown counts observed data periods, not calendar days. For daily data,
cooldown_periods: 7 excludes seven daily observations. For weekly data,
cooldown_periods: 2 excludes two weekly observations.
When cooldown is positive:
intervention_date_str;min_post_treatment_periods is checked after cooldown exclusion.You may supply measurement_start_date_str explicitly, but if it is supplied
with cooldown_periods, both settings must resolve to the same observed period.
Positive cooldown shortens the measurement window and can reduce power.
sparse_sc_T0 and sparse_sc_T1 are SparseSC history-length settings. They are
not cooldown controls.
All file-based and direct-data panels are canonicalised before validation. Date
labels become a sorted, timezone-naive DatetimeIndex; malformed or
timezone-aware labels, duplicate periods after parsing, and treatment dates
absent from the outcome panel are rejected rather than coerced.
estimator: "sparsesc" is the only supported estimator selector and is also
the default when the key is omitted. Historical values sdid, sc, did, and
regsynth all executed this same SparseSC path; they are now rejected because
their names implied implementations that were not present. Replace any such
value with estimator: "sparsesc".
GeoSC validates keys that start with sparse_sc_ so misspellings fail before
the adapter falls back to defaults. Supported SparseSC runtime keys are:
sparse_sc_model_typesparse_sc_fast_estimationsparse_sc_return_cisparse_sc_T0sparse_sc_T1sparse_sc_max_n_plsparse_sc_placebo_seedsparse_sc_levelsparse_sc_lasso_max_itersparse_sc_lasso_tolsparse_sc_cv_foldssparse_sc_scoringsparse_sc_gcv_modesparse_sc_placebo_seed defaults to 110011 and must be a non-negative
integer. It controls only the sampled-placebo branch used when
sparse_sc_max_n_pl caps the feasible placebo combinations. Exhaustive
enumeration is unchanged. Results persist the seed, placebo mode, requested
count, possible count, and effective count so sampled inference can be replayed.
Existing non-prefixed lasso options such as lasso_selection,
lasso_fit_intercept, and lasso_normalize keep their legacy behavior and are
not part of the sparse_sc_* allowlist.
Inference defaults are fail-closed:
duplicate_policy: "error" rejects duplicate location-date rows. Use
"mean" or "sum" only when that aggregation is statistically intended.missing_outcome_policy: "error" rejects incomplete outcome panels. Explicit
alternatives are "drop_unit", "drop_period", and
"impute_with_report".Every inference run writes data_validation.json next to the result artifacts.
Review it before interpreting lift. The artifact includes raw outcome value
checks plus separate input-panel and model-panel quality summaries, so missing
values hidden by explicit duplicate aggregation remain auditable.
Inference also writes geolift_results.json with schema_version and
status. Treat ok as “the configured contract completed”, not as a proof of
causal validity. Treat partial as “estimate available but interpretation
metadata incomplete”, and treat failed as unusable for decision-making.
run_assumption_checks: false skips the parallel-trends diagnostic and
advisory interference screen, but still writes assumption_validation.json
with overall_status: "skipped".require_assumption_checks: true makes only the gate-eligible
parallel-trends diagnostic a hard result gate. A failed gate marks
geolift_results.json as status: "failed".fail_on_assumption_error: true treats parallel-trends validator exceptions
as failed gates when checks are run. An interference-screen exception is
recorded as indeterminate and remains advisory.parallel_trends_method supports "placebo", "regression", and
"visual".spillover_method supports "correlation", "change", and "visual"
for the advisory interference screen.The interference screen reports signal, no_signal, or indeterminate and
adds a result caveat where appropriate; it never changes result status or
significance. Neither a signal nor no signal identifies treatment exposure or
proves the presence or absence of spillover. A future hard interference gate
would need a pre-specified exposure, network, or geographical-interference
design; GeoSC does not implement one.
Power analysis accepts the demo keys in
data-config/power_analysis_config.yaml, including:
random_seed makes repeated runs with the same config reproducible. Each
power_analysis_results.csv row records n_failed, failure_rate, valid,
random_seed, simulation_seed, dgp_rank, dgp_explained_var,
requested_max_n_pl, possible_placebos, effective_max_n_pl, dgp_backend,
generation_backend, seeded_reproducibility_mode, and effect_pattern. Rows
with valid: false exceeded the configured failure tolerance or had no
successful simulations. power_failure_rate_threshold must be a finite number
in [0, 1]; non-finite values are rejected at construction. When random_seed
is set, GPU DGP estimation and GPU post-period generation are disabled so
seeded CPU simulation draws are reproducible. The shipped demo config sets
use_gpu: false to match this seeded reproducibility default.
The factor-model DGP supports SVD extraction only. power_dgp_rank controls the
number of SVD factors, and power_dgp_max_rank caps automatic rank selection.
GeoSC estimates VAR(1) dynamics on the selected factor series and stores the
transition, intercept, innovation covariance, and initial factor distribution in
the DGP metadata used for simulation. Automatic rank selection applies an
additional effective cap so the selected rank is estimable by the VAR(1)
regression on short pre-period panels. Explicit power_dgp_rank values that
cannot support VAR(1) estimation fail with an actionable error instead of
silently switching DGP families. Unsupported extraction methods such as pca
are rejected rather than treated as aliases.
Generated post-period panels use the VAR(1) temporal parameters whenever they
are present. Covariance matrices are symmetrized and regularized with a small
diagonal floor; invalid factor dynamics or failed factor draws raise errors
instead of falling back to diagonal covariance. Because the current GPU path
does not implement the VAR(1) generator contract, post-period generation for
estimator-produced power DGPs is reported as cpu_numpy_generator even when GPU
SVD estimation was requested and available.
Power values are Monte Carlo estimates, not guarantees; compare them with
power_ci_lower, power_ci_upper, n_simulations, and failure_rate.
If a power-analysis design has fewer control units than treatment units the
calculator now fails fast at construction with a ValueError rather than
forwarding an infeasible placebo count to SparseSC. plot_power_curves filters
rows with valid: false out of the decision plots (logging the count of
excluded rows) and skips plot creation entirely when no valid rows remain.
Donor evaluation accepts donor_dominance_threshold in addition to the existing
metric thresholds. donor_eval_results.csv includes rank, quality_band,
warning_flags, and selected_weight. selected_weight is a normalized
recommendation weight within the ranked donor set; it is not a fitted SparseSC
weight. The stage also writes versioned donor_pool_quality.json with threshold
settings, warning-flag counts, selected-weight concentration, effective donor
count, and by-treatment quality summaries.
The maintained artifact contract is enforced by release preflight and described in the output sections of API Reference, Interpreting Results, and the stage-specific how-to guides.
Donor maps use:
shapemap_file may point to any GeoPandas-readable vector file. The configured
shapemap_id_column must contain IDs that exactly match the treatment and donor
unit IDs in the analysis data. For UK production workflows, postcode district
IDs such as SW1A or postcode area IDs such as SW can be used when the data
and shapemap are both normalized to the same geography. See
How to Use Shapemaps for examples.
scripts/verify_release_candidate.py includes a named statistical
certification gate for the 0.3.0 beta. The gate runs the maintained wrapper
tests for SparseSC parity, effect recovery, treatment timing and orientation,
artifact parity, result uncertainty and placebo semantics, donor semantics,
power semantics, assumption-validator metadata, and release-preflight schema
regressions.
Passing the gate means the tested GeoSC wrapper contract is intact for the declared SparseSC operational surface. It does not prove donor exchangeability, absence of spillovers, correct campaign timing, outcome suitability, credible power DGP assumptions, or acceptable placebo p-value granularity for a specific measurement decision.
This project vendors parts of third-party libraries to ensure stability, provenance, and reproducibility of core methods.
https://github.com/microsoft/SparseSCsrc/sparsesc/3b4d2ebd87b41fc8e0ec3e97fcb2be1b689275c0src/sparsesc/ is a governed integration fork of Microsoft’s SparseSC.src/sparsesc/PROVENANCE.md for upstream commit, local modifications, coupling notes, and update procedure.src/sparsesc/ must be documented in src/sparsesc/PROVENANCE.md with rationale and verification impact.pyproject.toml).scripts/verify_release_candidate.py. The gate checks adapter/result parity,
effect recovery, timing/orientation, artifact schemas, uncertainty and
placebo metadata, and related advisory diagnostics. It does not treat passing
wrapper tests as proof that a specific campaign satisfies SparseSC’s causal
design assumptions.src/sparsesc/utils/AzureBatch/ remains part of the
governed vendored SparseSC fork. Removing or pruning it requires a separate
SparseSC provenance-backed phase with documented rationale, verification
impact, and an update to src/sparsesc/PROVENANCE.md.src/synthdid/GeoLiftAnalyzer workflow.pyproject.toml exclusion lists only if vendored paths change.