Skip to contents

[Experimental]

Usage

validation_status()

Value

A data frame of validation status records with class "hs_validation_status".

Details

validation_status() reports the current validation atoms and planned comparator lanes for hsquared. It is a developer evidence table, not the user-facing list of what you may report. For that list, read Can I fit and report this?. This function does not run validation checks, fit models, or promote any capability to working status.

This table is not the full list of covered routes

The rows here are validation atoms, grouped by evidence chain rather than by public modelling route, so the covered row count is not the number of covered routes. Two capabilities that count as publicly covered have no row of their own yet:

  • the opt-in reaction-norm model, k = 2: animal(rr(x, order = 2) | id, pedigree = ped) with engine_control = list(target = "random_regression");

  • the opt-in correlated direct-maternal 2x2 G model: animal(1 | id, pedigree = ped) + maternal_genetic(1 | dam) with engine_control = list(target = "direct_maternal").

Both are covered at validation scale, opt-in, and REML-only. The engine-enforced dense rule on guarded routes is nobs^2 + nanimals^2 <= 1e6 (default max_dense_cells), counting every animal in the pedigree, not just records. These two routes do not currently accept that lever, so they have no engine-enforced cell cap. Their scope and reporting limits are recorded in the repository capability ledger (docs/design/capability-status.md) and, for readers, in Can I fit and report this?. Read this table together with that enumeration: an absent row is not an absent capability, and this table alone does not tell you everything you may report.

Bridge production fences (0.9)

The R-to-Julia bridge is live at validation scale for covered default and opt-in targets, but not production-complete. Infrastructure capabilities (R-to-Julia bridge payload, opt-in experimental Julia engine) stay partial even when individual targets are covered. Targets split into: default live (engine = "fit"), opt-in live (engine_control$target), PATH_ONLY smoke (C1-ext intervals; not a fit bridge), and blocked planned grammar (for example animal(cov = fa(...))). The explicit four-trait rank-one FA engine_control cell is partial and opt-in. payload_v2 routing is limited to direct_maternal and multi_effect. See docs/design/45-bridge-production-fences-DRAFT.md.

Capability identifiers versus labels

capability is a stable identifier. Dated evidence records – comparator runs under docs/dev-log/comparator-runs/ and check-log entries – cite these strings verbatim to name the row they report against, so an identifier is not rewritten once evidence points at it. Look rows up by capability.

capability_label is the current wording, and is what reader-facing surfaces print. The two differ only where an identifier's wording has been overtaken by a later change; today that is the multivariate row, whose cbind() route became default rather than opt-in.

Examples

validation_status()
#> <hs_validation_status>
#>   validation: status table only; checks are run by tests and CI
#>   public claims: developer evidence table, not the user-facing list
#>   of what you may report; see Can I fit and report this?
#>   this table is not the full list of covered routes -- opt-in
#>   random_regression (k = 2) and direct_maternal are covered with no
#>   row yet; see the current-limits article
#>   shown below: `capability_label` (current wording); look rows up by
#>   the stable `capability` id that dated evidence records cite
#>                                                                                                                              capability_label
#>                                                                                                               tiny deterministic Ainv fixture
#>                                                                                                               Mrode9 pedigree Ainv comparator
#>                                                                                                       supplied-variance Henderson MME fixture
#>                                                                                                               sparse REML likelihood identity
#>                                                                                                         Mrode-style supplied-variance outputs
#>                                                                                                   experimental sparse REML estimator (opt-in)
#>                                                                                                 experimental repeatability estimator (opt-in)
#>  two-effect / arbitrary-N independent-effect estimator (opt-in; covered: common-env + (1|g) iid / A2=I; experimental: maternal / A2=pedigree)
#>                                                                   experimental supplied-relationship estimator (opt-in: genomic, single-step)
#>                                                       experimental SNP-BLUP marker-effect model (opt-in; supplied-variance or REML-estimated)
#>                                                                                      experimental multivariate REML estimator (default route)
#>                                                                                  univariate Gaussian animal-model fit (default path, AI-REML)
#>                                                                                       external published-REML recovery (gryphon, R reference)
#>                                                                                     known-truth DGP variance-component recovery (R reference)
#>                                                                                                             Mrode fitted animal-model outputs
#>                                                                                                                      ASReml comparison policy
#>                                                                                                          BLUPF90/DMU/WOMBAT comparison policy
#>                                                                                                                         XSim simulation truth
#>                                                                                                               genomic and QTL/eQTL validation
#>                                                                                                           GLLVM-style multivariate validation
#>                                                                                                                    CPU/GPU backend comparison
#>     phase  status
#>   Phase 1 partial
#>   Phase 1 partial
#>   Phase 1 partial
#>   Phase 1 partial
#>   Phase 1 partial
#>   Phase 1 partial
#>   Phase 2 partial
#>   Phase 2 covered
#>   Phase 5 covered
#>   Phase 5 partial
#>   Phase 3 covered
#>   Phase 1 covered
#>   Phase 1 covered
#>   Phase 1 covered
#>   Phase 1 planned
#>   Phase 1 planned
#>   Phase 1 planned
#>  Phase 5+ planned
#>  Phase 5+ planned
#>   Phase 6 planned
#>  Phase 7+ planned