R package boundaries

The R layer is divided by user task instead of placing every interface in one large gsuite package. The root gsuite package remains the ecosystem identity, website and development integration surface. A root R release is not currently planned; greml/gsolve R packaging is deferred, with separate or combined packaging undecided. Independently distributed task capabilities are R/native pairs: an R package owns the user contract and its corresponding native library owns the implementation. Each task package can be installed and used without the root package.

Dependency rule

The dependency direction is:

gbase <- gcorr, glma, gbayes, gscore, gmap, gsea

task packages do not import gsuite
task packages depend on each other only for an explicit scientific workflow

gbase must not depend on a task package. Its public source distribution builds task-neutral gbits/gmat and bounded gsolve-core/greml-core source into a reusable static archive. A task package must not depend on the root gsuite package. This prevents dependency cycles and lets users install one task without installing the complete suite.

Package map

This is the canonical map of R/native distribution units. Method details belong in the capability overview; native transitive dependencies belong in the build manifests.

R distribution surface	Native owner shipped or linked for that surface	Status and boundary
`gsuite`	Root bridge over gsolve, greml, gbits, gmat and `gbits::gsolve_adapter`	Mixed-model, solver and integration interfaces.
`gbase`	Task-neutral gbits/gmat plus bounded gsolve-core and greml-core source	Shared Glist, summary-statistics, LD-resource and public source-build contracts. This is the deliberate exception to the one-task/one-native-owner pattern.
`gcorr`	`libgcorr`	Genetic correlation, covariance models and MR.
`glma`	`libglma`	Association scans and the native implementation of `vegas()`.
`gbayes`	`libgbayes`	Bayesian inference and posterior prediction.
`gscore`	`libgscore` and `libgscore_summary`	Score application and C+T; model fitting remains with model owners.
`gmap`	unified `libgmap` with Bayesian support	Fine-mapping and colocalisation.
`gsea`	`libgsea` and `libgsea_bayes`	Enrichment; re-exports `glma::vegas()` for the connected workflow.
`gsuite` native dependencies	gbits, gmat, gsolve, greml and `gbits::gsolve_adapter`	Native infrastructure used by the public root integration interfaces.

gsim is the simulation package and exchanges ordinary data with the analysis packages.

What belongs in gbase

Code belongs in gbase only when it is stable, task-neutral and needed by more than one task package. The package contains or will own:

allele-labelled summary-statistics data frames, marker-by-trait matrices and gact Z/N lists;
checkStat() mapping, harmonization and explicit QC of reported statistics against a Glist reference;
opt-in DENTIST-style LD consistency checks and quality-filtered Z-score imputation against ancestry-matched complete regional BED correlation;
validation of marker identity, positions, alleles and supplied numerical columns;
explicit allele-oriented variant keys;
gbase::gprep() preparation and sparse-LD publication plus the serializable Glist contract shared by individual-level task packages;
gbase::define_ld_blocks() one-time verification and serialization of an exhaustive independent-block partition tied to the sparse-LD identity;
summary-based marker filtering and Glist-owned LD scores, regional matrices, complete verified regional eigensystems, and reusable eigenvalues-only full regional BED spectra through gprep(task = "eigen", sets = ...).

checkStat() follows the established qgg workflow and preserves ordinary input formats. Its data-frame columns are rsids, chr, pos, ea, nea, with the available analysis columns among eaf, b, seb, stat, p, n and info. Downstream functions validate the subset they require. Gbase does not require a public summary-statistics class, constructor, accessor or print method.

The following do not belong in gbase:

automatic strand inference or downstream LD-model fitting;
genotype, LD or matrix storage;
statistical fitting, priors or sampler controls;
scoring, correlation or association algorithms;
orchestration across tasks.

Those responsibilities remain with gmat/data preparation, the relevant task package or the gsuite umbrella.

R interfaces by package

The groups below cover the current exported interface.

Interface	R package
`gbase::gprep()` prepare/sparseld/eigen routes, lightweight Glist validation, explicit `verify_ld()` integrity checks and printing	gbase
`checkStat()` user-facing summary-statistic mapping, harmonization and QC	gbase
`impute()`, optional LD checking in `checkStat()` and `setReferenceGroups()`	gbase R/native adapter; gbits/gmat own reference access and gsolve owns numerical factors
`gbase::gfilter()`, `ld_scores()`, `ld_region()` and `ld_eigen()` over Glist	gbase
`mapSets()` marker membership, `getChromosomeSets()`, `createMarkerSets()`, `getLDscores()`, `createLDsets()` and `getLD()` regional BED correlation	gbase; installed gmat owns genotype decoding
`gcorr()` and its fit, summary, plot, covariance, annotation and MR methods	gcorr
`gscore()`, `clump_threshold()` and score prediction methods	gscore; C+T is scoring-specific, while fitted association and posterior effects remain with their model packages
`gbayes()`, fixed-variance `gbayes_single_effect()` and Bayesian fit, continuation, posterior and prediction methods	gbayes
`glma()` and association-result methods	glma
`vegas()` marker-set association evidence	glma implementation and native integration; gsea re-export and `gsea_input()` handoff
`gmap()`, `gmap_stat()`, `gmap_bed()`, `getCredibleSets()` and focused mapping/colocalisation methods	gmap; statistical priors, adapters and posterior grouping remain task-owned
`gsea()`, familiar `magma()` pathway regression, ridge/BayesC/BayesR chromosome-held-out `pops()` and result methods	gsea
`greml()`, persistent mixed-model, pedigree, multivariate, longitudinal and component-model constructors and methods	gsuite, backed by greml
`gsolve()`, `gsuite_solve()` and solver result methods	gsuite, backed by gsolve
`gsuite_versions()` and cross-task workflows	gsuite umbrella
`diagnostics()` generic and future common result conventions	Candidate for gbase after method compatibility is audited

Low-level native libraries do not automatically require user-facing R packages. In particular, gbits remains an implementation dependency unless a distinct user task emerges.

Present native dependency closures

These are planning boundaries, not new build declarations:

R package	Main native dependencies
gbase	gmat and gbits for genotype/sparse-LD preparation and LD utilities; gsolve for complete verified regional eigensystems
gcorr	gcorr, with prepared gmat LD resources
gscore	core gscore for BED application plus `gscore::summary` for C+T; the installed summary library currently brings gbayes, gmat, gsolve and gbits transitively
gbayes	gbayes, gmat, gbits and gsolve; the qualified portable profile retains OpenMP while disabling CHOLMOD, MKL and PARDISO
glma	glma, with gmat/gbits, greml or gbayes where the selected association task requires them
gmap	unified gmap library and gbayes, with prepared gmat resources
gsea	gsea and its selected gbayes companion

Development builds may use the qualified installed native prefix. Public source packages instead extract the same canonical owner sources into generated archives; task packages link the static core installed by gbase. Packages that reuse Bayesian native code also declare gbayes and link its installed archive instead of recompiling it. See the source-package repository guide.

Summary-statistics integration

gbase::checkStat() maps, validates, harmonizes and filters ordinary qgg-style data frames. It also supports trait matrices and gact Z/N lists, with optional LD consistency checking and imputation. These are preparation operations; effects, missing sample sizes and downstream sampling models are not inferred. Analysis packages then validate the exact columns they consume.