Privacy-Preserving Malicious Activity Detection

Figure 3 gives a reader-facing view of the four dataset surfaces referenced in this appendix. The canary surface anchors calibration, the live-adjacent corpus supplies the main observed collection base, the provenance-labeled companion adds bounded source-aware labels, and the reviewed honeypot subset broadens the operational picture under stricter runtime conditions with 103 retained rows spanning 50 unique reviewed records, 26 bounded labeled identities, and 24 explicitly unlabeled reviewed identities.

Each retained row is one obfuscated event-level record keyed by a stable record_id. The dataset builder materializes timing, structure counts, surface markers, prompt-risk indicators, derived scalar features, and one-hot event-type flags into the obfuscated_record_v1 schema. Within the retained modeling workflow, analysis operates on structural telemetry only: timestamps, lengths, counts, flags, and derived scalars remain available after reduction, while message text stays outside the stored ML surface. Additive fields that are absent in older records are normalized to stable zero or false defaults during extraction so the dataset contract remains consistent across the admitted collection regimes.

Table 2 keeps this section at the family level rather than dumping raw field names. Appendix B can carry the stricter field-by-field contract later.

This grouping keeps the observation model reader-facing. Identity and timing support deterministic splits, structural and surface markers preserve behavioral shape, reduced risk indicators capture the strongest blind signals, and event-type flags retain coarse interaction form without storing raw content.

The comparison-ready build summarized here remains tightly tied to the live-adjacent collection corpus. Its input slices contribute 13,718 live-adjacent records and 124 canary-sourced records, yielding the 13,842-row dataset used for the current build. The deterministic split manifest preserves a near-exact 70/15/15 allocation with 9,587 training rows, 2,297 validation rows, and 1,958 test rows. Among the visuals gathered here, the broader input-volume reference view, Split balance, and Feature family breakdown add the clearest appendix value because they make both dataset context and dataset structure legible without overloading the main body.

The inserted input-volume plot now serves as broader reference context rather than as a direct rendering of the admitted 13,842-row live-adjacent build. It shows the larger canary/reference slice family feeding the canary-aligned build lineage, with the 133,837-sample benign calibration slice appearing as the dominant visible input. The live-adjacent build counts remain the ones listed in the snapshot bullets above.

Taken together, the input-volume view, feature-family breakdown, and split-balance outputs show two distinct layers of Appendix A evidence. The input-volume figure situates the broader canary/reference intake behind the calibration lineage, while the feature-family and split-balance figures describe the structure of the admitted 13,842-row live-adjacent build summarized in the bullets above. This separation keeps the larger reference intake visible without confusing it with the composition of the current comparison-ready corpus.

Table 3 lists the current admitted feature families exactly as they are materialized into the live-adjacent dataset bundle. The emitted table carries 30 columns in total and matches the feature contract recorded in the dataset manifest and downstream training artifacts.

The builder applies a small set of stable transformation rules before the dataset reaches the training and evaluation lane.

• •

  Stable row identity. Each record receives a deterministic record_id so feature rows, split assignments, and optional labels can be joined safely across artifacts.

• •

  Timestamp reduction. The emitted ts_epoch value prefers the promoted scalar f_timestamp_epoch; if that scalar is absent, the builder falls back to parsing timestamp or ts.

• •

  Boolean normalization. Source booleans are written into the CSV as binary integer flags, so fields such as has_code_block, has_link, the contains_* indicators, is_canary, and all type_* columns appear as 0/1 values in the admitted feature table.

• •

  Pattern reduction. The broader schema can carry matched_pattern_labels as an array of strings, but the current dataset contract reduces that surface to the scalar matched_pattern_count.

• •

  Event-type normalization. Source event labels are mapped into seven one-hot columns, with type_unknown serving as the fallback when the incoming event type falls outside the current vocabulary.

• •

  Backward-compatible defaults. Additive uplift fields that are missing in older records are normalized to stable zero or false defaults so earlier retained rows remain admissible under the same contract.

• •

  Separate label channel. When a labeled companion is present, labels are written to a separate labels.csv surface keyed by record_id rather than embedded inside features.csv.

The broader obfuscated-record schema permits additional routing, provenance, and integrity fields, including packet_family, packet_version, venue_id, entity_kind, source_id_hash, author_hash, sender_hash, matched_pattern_labels, node_id, mode, kind, signature, and tv_id. Those fields remain useful for ingestion, governance, or auxiliary reporting, but they are not part of the current admitted modeling matrix. This boundary matters for two reasons: it keeps hashed actor identifiers and raw matched-pattern strings out of the learning surface, and it prevents runtime or routing metadata from quietly becoming a stand-in for the privacy-safe behavioral signals the study is actually trying to evaluate.

Current training and scoring routines load the feature contract from the dataset manifest, then remove record_id and is_canary before constructing learned feature vectors. The remaining numeric columns feed the current ApexLab-backed Isolation Forest and Random Forest workflows. In practical terms, that means the admitted model surface is still fully names-only: no message bodies, no raw links, no matched-pattern label strings, no hashed actor identifiers, and no secret-bearing runtime fields enter the learned representation. What remains is the structural evidence the analytical core uses—timing, shape, formatting markers, risk cues, and compact derived scalars—kept in a form that is reproducible, auditable, and narrow enough to preserve the Blind ML privacy boundary.

The current evidence base rests on three public-facing anchors. First, the Canary V1 Inference Report establishes the calibration story with 133,837 benign examples, a threshold near $-0.0451$, and a benign false-positive rate close to 1%. Second, the live-adjacent current-collection snapshot establishes the 13,842-row corpus described in Appendix A. Third, the provenance-labeled companion adds the 208 uniquely labeled record_id values that support bounded source-aware comparison work and the admitted feature contract.

From there, the analytical story advances through four aligned summary layers. The build summary materializes the dataset bundle and deterministic split. The training summary records the available source-aware model path and the admitted feature contract. The evaluation summary records threshold-publication posture for that path, and the scoring summary carries the broader canary-distribution view that supports the calibration story. Read together, these surfaces preserve one continuous evidence chain across the project.

The current collection pair is organized as a main empirical base plus a focused companion layer. The current-collection snapshot contributes 13,718 recent live records and 124 recent canary records, yielding the 13,842-row corpus used throughout the current analysis. The provenance-labeled companion builds on that same corpus and adds 208 uniquely labeled record_id values for source-aware analysis and later source-aware comparison work.

Within that companion, the label values have a direct reader-facing meaning. Label 0 marks the recent live slice, and label 1 marks the recent canary slice. This compact label layer supports provenance-aware analysis while keeping the broader dataset story unified around one stable collection snapshot.

Beyond the main current-collection pair, the evidence base now also includes a bounded reviewed honeypot proof-of-life chain. The reviewed subset contains 103 retained rows spanning 50 unique reviewed records, with 26 bounded labeled identities and 24 explicitly unlabeled reviewed identities. That higher-risk subset has already passed through governed reviewed-dataset registration and into the same analysis-ready dataset preparation workflow used elsewhere in the study. A selector-visible registration step and emitted comparison-baseline packet make that handoff explicit in the current authority spine. It therefore extends the lineage story from collection and review into governed higher-risk admission and downstream consumability without overstating the present scale of multi-class evidence.

A reader-facing summary in this project consistently carries four ingredients:

• •

  dataset identity, so the reader can see which study surface a result belongs to;

• •

  workflow stage, so the role of each summary is clear inside the larger pipeline;

• •

  core outputs, such as dataset bundles, metrics, figures, or score distributions;

• •

  interpretive role, so each surface contributes a specific analytical claim.

That structure is what keeps the lineage legible. The build summary clarifies dataset materialization, the training and evaluation summaries clarify the source-aware comparison path, and the canary calibration surface plus scoring summary clarify the calibration story. Each surface adds one part of the overall picture while preserving a shared study identity.

This lineage supports dataset-role interpretation, calibration, companion-label meaning, and current experimental interpretation. Appendix C carries the connective tissue that links those ideas into one forward-moving evidence story. In that form, lineage serves the reader directly: it shows how the live-adjacent corpus, the bounded companion, and the stage-specific summaries fit together into a coherent research contribution.

Benign canary calibration remains the clearest empirical anchor for the Blind ML workflow. Figure 7 shows the full 133,837-sample benign distribution on a linear count scale, which makes the dominant benign mass easier to read than a tail-focused display alone. Figure 8 then shows how the selected threshold near $-0.045$ isolates only the extreme lower tail, flagging 1,364 benign samples and keeping the benign flagged share at approximately 1.02%.

The larger canary-aligned comparison corpus extends the calibration story beyond the smaller benign anchor. Figure 9 shows the full score surface for 412,340 scored records under the current unsupervised lineage. The paired evaluation packet publishes a threshold of 0.434329 and selects 4,478 records for review, a flagged share of 1.086%. Read together, the calibration and comparison views show the same conservative pattern: the review boundary sits at the lower edge of the score mass rather than near its center.

The current paper also includes a separate higher-risk evidence thread in the form of a bounded reviewed honeypot subset. That subset spans 103 retained rows, 50 unique reviewed records, 26 bounded labeled identities, and 24 explicitly unlabeled reviewed identities. It shows that reviewed labeling, governed reviewed-dataset registration, and downstream analysis-ready dataset preparation already function in a higher-risk regime. This evidence complements the calibration and canary-score figures above while keeping the claim envelope disciplined, with a full honeypot train/evaluate benchmark family positioned as a later expansion step.

The retained model surface is deliberately narrow. The admitted feature table keeps only privacy-safe structural telemetry: timing, length, counts, visible formatting markers, prompt-risk indicators, derived scalar summaries, and one-hot event types. It excludes retained message text, raw matched-pattern strings, and actor-identifying fields from the learned representation. That boundary is central to the Blind ML contribution, because it keeps the downstream analytical surface names-only and reproducible. It also creates an explicit information ceiling. Distinctions that depend on lexical meaning, longer conversational context, sarcasm, or topic-specific semantics are only partially recoverable once the retained representation has been reduced to structure alone. The current results should therefore be read as evidence that privacy-safe behavioral screening is possible under a constrained observation model, not as evidence that every harmful-behavior distinction survives full semantic stripping.

The active labeled companion is a provenance layer derived from the existing canary-membership field already present in the approved feature table. Its 208 uniquely labeled record_id values divide into 84 recent real/live records and 124 recent sim/canary records. Those labels preserve source-slice truth for the current corpus and make the dataset comparison-ready for stratified analysis. They do not define a hostile-behavior ground-truth benchmark. In consequence, this label layer supports bounded source-aware comparison work inside the current corpus, while fuller multi-class threat discrimination still depends on broader reviewed labels.

The current project evidence contains several threshold-bearing surfaces, each with a different interpretive role. The benign calibration report on 133,837 samples places the operating point near $-0.0451$ in order to hold the benign false-positive rate at approximately 1%. A later canary-facing evaluation summary on 412,340 records reports a threshold of 0.434329 and a 1.086% lower-tail review share under the same lower-is-more-anomalous scoring direction. These values support a consistent guardrail idea—conservative lower-tail review at a bounded operating point—but they do not live on one universal numeric scale. Each threshold belongs to its own run lineage, score surface, and label posture, so direct numeric transfer across calibration, canary comparison, and reviewed higher-risk settings would overstate comparability.

The study already spans more than one observed regime: a large benign canary corpus, a live-adjacent collection corpus, a provenance-labeled companion built from that live corpus, and a reviewed higher-risk honeypot subset. This breadth is a real strength because it shows that the same privacy-safe feature contract can survive across different collection conditions. At the same time, the strongest labeled high-risk evidence remains small. The reviewed honeypot companion covers 103 retained rows, which collapse to 50 unique reviewed records, of which 26 received bounded labels while 24 remained explicitly unlabeled. That scale is appropriate for demonstrating that a reviewed higher-risk regime exists and can be governed honestly, but it remains too small to support broad prevalence claims, robust multi-class comparison, or strong cross-regime generalization. More reviewed labels, longer time coverage, and broader venue diversity would all improve the external validity of the present findings.

Taken together, these limitations define the current scientific boundary in a constructive way. The project has already established a governed metadata-only workflow, a strong benign-calibration result, bounded label-ready extensions, and a reviewed higher-risk proof-of-life surface. The next empirical gain comes from expanding reviewed label coverage and controlled cross-regime evaluation. Governance maturity and runtime discipline strengthen traceability throughout that process, and larger labeled evidence will further strengthen performance claims.

The normal ML lane persists structural telemetry and derived scalars rather than retained message text. In the current admitted workflow, the stored analytical surface is built from event timing, event class, lengths, counts, surface markers, prompt-risk indicators, deterministic row identity, and compact derived features such as complexity, code density, and toxicity. Earlier safety handling may still inspect raw content briefly inside the controlled upstream environment, but that text stays outside the stored dataset, the admitted learned feature table, and the reader-facing publication packets discussed elsewhere in the paper.

This same names-only rule shapes supporting artifacts. Values that would be unsafe to expose in a static appendix are carried through hashes, selectors, or reference-handle fields whose names end in _ref rather than copied into the released artifact itself. In practical terms, routing fields, raw matched-pattern strings, and hashed actor identifiers remain governance-side context rather than part of the current learned surface.

The project keeps source authority, derived artifacts, and publication views in separate roles. Approved dataset selectors, manifest-backed dataset definitions, and run-ledger surfaces carry the canonical machine-readable lineage for admission, preparation, evaluation, and release. Generated figures, collection packets, and aggregate report pages sit downstream as reader-facing publication surfaces rebuilt from those governed artifacts. This one-way relationship matters methodologically: published packets can summarize a run clearly for readers, but they do not become configuration inputs or a second machine-readable authority layer.

That boundary also explains why the project treats generated artifacts conservatively. Public documentation may reference canonical local runtime paths and evidence families, but those references remain descriptive. They help the reader follow the workflow without turning local runtime evidence into tracked public authority.

Governed custody is enforced through an integrity-checked librarian vault rather than through ad hoc file placement. In the current observer workflow, the normal operating posture is the locked state: approved dataset selectors, admission snapshots, and protected release projections remain available for signed operations while the integrity layer compares the current managed-surface checksum against a recorded baseline checksum and preserves the associated audit surfaces. Manual maintenance is bounded rather than informal: unlock opens a deliberate maintenance window, relock restores the normal posture, and rebaseline refreshes the checksum anchor once the controlled mutation is complete.

This integrity layer contributes directly to reproducibility. Registration and protected-release mutations refresh the vault baseline, preserve tracked-file counts and checksum evidence, and append names-only audit records. As a result, dataset admission and later protected release remain attributable to specific governed mutations instead of becoming undocumented file copies.

Protected-source dataset access follows a short delegated release sequence once an approved selector has been resolved to a ready manifest.

1. 1.

   A signed request.json packet records the requester, requested action, expiry, access class, source binding, and dataset-manifest checksum.

2. 2.

   That request is verified before release proceeds.

3. 3.

   A signed attestation.json packet binds the request hash to the selector identity, readiness state, source binding, and grant decision at the governed dataset-authority layer.

4. 4.

   A signed release_receipt.json packet then binds the request and attestation hashes to the released manifest path and the granted protected-source action.

5. 5.

   The release mutation refreshes the vault baseline and appends an audit record so the delegated handoff remains reviewable after the fact.

Local approved datasets resolve directly from the admitted manifest path, but protected-source datasets enter this delegated request $\to$ attestation $\to$ release flow so the release surface stays attributable, bounded, and checksum-coupled to the same governed custody layer.

Table 5 summarizes the authority split used throughout the paper.

This split keeps the paper reader-first without flattening the governance model. The narrative can point readers to public packets and validation publications, while the underlying selector catalogs, manifests, release receipts, and run ledgers remain the canonical local surfaces that make those publications reproducible.

The operator-facing authority surface remains observerctl ops keysmith mint, backed by a single underlying keysmith mint command family. The dry-run path is intentionally permissive enough for local verification: it can execute from the host, writes into a timestamped local_untracked/keysmith_exports/ directory, and produces a deterministic-shaped artifact set without contacting the vendor. Live minting is stricter. A non-dry-run execution must occur in the approved sandbox/container lane, where KEYSMITH_SANDBOX=1 marks the controlled execution surface and the output root is constrained to the sandbox-approved export directory.

That boundary is fail-closed rather than advisory. KEYSMITH denies non-dry-run execution outside the sandbox lane, denies outputs inside the tracked project tree outside local_untracked/, denies non-empty output directories to avoid sealed-drop reuse, and denies non-allowlisted hosts. In the current implementation, the allowlisted canonical vendor host is www.moltbook.com, and the sandbox runner mounts the project-local export root into the container so the resulting names-only artifact bundle remains reviewable after execution.

Once the mint succeeds, the shipped bundle is small and deliberate. Humans receive only the claim URL and never the credential value itself; the secret remains in the sealed-drop file and in downstream import surfaces that report presence only.

The important design point is that the sealed drop is the handoff boundary, not a human-readable checkpoint. The current shipped code treats it as a short-window plaintext-at-rest artifact inside the bounded export root, while the audit trail records only names-only metadata such as artifact paths and sealed-drop byte length. This is why the paper can describe KEYSMITH as a secret-authority surface rather than as an ordinary registration helper.

Within the broader authority matrix, KEYSMITH does not create the live and honeypot regimes; those stricter collection regimes already exist inside the governed observer continuum. Instead, KEYSMITH supplies the credential-acquisition and hydration path required for real-source operation while Watchdog and the observer runtime continue to own the downstream fail-closed movement gates. In practice, this means the runtime still refuses real-source work when MOLTBOOK_API_KEY is absent, even though the rest of the collection stack is already admitted and operational.

That distinction explains the current status nuance. The shipped KEYSMITH lane can truthfully report that the surface is present and that host dry-run remains available while live mint authority is still sandbox-only. In the current operator status packet, this split can appear as a human-readable success state for the shipped surface alongside a JSON-only nonzero readiness code when the sandbox lane is not armed. That is shell-local readiness signaling, not evidence that the broader live or honeypot collection reality is hypothetical. Those regimes already belong to the admitted governed workflow; KEYSMITH simply keeps their credential path inside a separate, controlled access surface.

The current stable sandbox catalog covers metadata integrity, DS-wizard hydration and state continuity, DS-wizard truthfulness, publication alias coherence, baseline-monitor runtime continuity, and librarian governance. Table 7 summarizes those families at the role level rather than replaying the full historical order in which the probes were added.

Each retained sandbox family writes into a stable subtree under report_tmp/, typically with per-run material under runs/<run_id>/ and an append-only run_index.jsonl file at the family root. Those index rows preserve the definition identity, timestamp, result, report paths, and next-bite status so later review does not depend on a single latest-run overwrite. The per-run artifacts are intentionally paired: a JSON report preserves the machine-readable check matrix, while a Markdown companion preserves the same run as a compact review surface.

The CLI mirrors that storage discipline. Before execution, observerctl sandbox show <definition> surfaces purpose, outputs, guardrails, and run-index destination for the selected stable definition. After execution, observerctl sandbox runs show <run_id> summarizes retained checks, command results, and surfaced findings for the saved run. In current retained examples, baseline-monitor runtime runs preserve monitor-state and resource-retention evidence, DS-wizard truthfulness runs preserve command previews and validation blockers, and librarian governance runs preserve request, attestation, release, and vault-control artifacts. Names-only terminal output and no-secret-printing rules remain part of the documented guardrail surface throughout that review flow.

This sandbox lane is stronger than a smoke-test family because it validates artifact content, publication coherence, continuity behavior, and governance semantics rather than only exit codes. The retained baseline-monitor runtime probe, for example, checks that monitor state is written, resource_normal retention continuity is real, and the resulting evidence packet carries the expected readiness and reporting sections. The librarian access-exchange probe confirms that protected-source request, attestation, and release artifacts are written and signature-verified while the corresponding vault baseline and vault audit surfaces are refreshed. The librarian vault-controls probe then confirms that registration is denied while the vault is locked and that rebaseline and verify return the managed surface to an ok integrity state.

The same pattern holds for the DS-facing probes. Hydration, stale-state, durability, alias-coherence, and truthfulness runs verify what the system actually writes and how it fails, not merely whether a command starts. In methodological terms, that is why the project treats observerctl sandbox as a retained empirical rehearsal lane: each run leaves a reviewable evidence packet about successful checks, denied transitions, and emitted artifacts, which makes the lane a stronger validation surface than a conventional smoke-test suite.

Table 8 summarizes the current state vocabulary. The source axis identifies whether the collection lane is simulated or real-source, the mode axis identifies the active operational lane, and the trigger posture is derived from mode rather than chosen independently.

Because posture is mode-derived, live and honeypot are not merely descriptive labels. They activate the lockdown family, while watch and canary remain isolation paths. In practice, any request targeting live or honeypot, or promoting sim to real, is treated as a stricter path.

The public control surface stays intentionally small. ops mode current and ops mode list expose the saved runtime state, gate produces a read-only go/no-go packet, set applies a freshly admitted change, and transition performs the guarded gate $\to$ set $\to$ evidence workflow. The important reader-facing point is that these are different layers of authority: a runtime may be running, yet the authoritative route state remains unchanged until the state packet itself moves.

For the stricter lockdown targets, the gate does more than check whether a process is alive. Current code and tests require coherent runtime state, watchdog and observer freshness, a valid trigger posture, security-report linkage, escalated heartbeat and baseline-validation cadence, an active baseline-monitor runtime, retained resource_normal continuity, and a complete baseline-window proof surface. The same packet family remains names-only throughout, surfacing fields such as timestamp_utc, from_state, to_state, decision, reason_codes, posture information, and security_report_ref rather than secret-bearing runtime material.

The denial surface is intentionally normalized and fail-closed. The current authority spine uses representative reason codes such as policy_denied:no_op_transition, policy_denied:target_mode_unsupported, critical_check_failed:run_security_report_missing, critical_check_failed:watchdog_trigger_posture_invalid, critical_check_failed:lockdown_heartbeat_rate_not_escalated, critical_check_failed:lockdown_baseline_rate_not_escalated, critical_check_failed:baseline_monitor_runtime_inactive, critical_check_failed:resource_stream_retention_unavailable, critical_check_failed:resource_baseline_window_incomplete, and critical_check_failed:cpu_spike_lockdown. For the lockdown path, the current test suite also fixes the activation-order vocabulary deterministically, so missing cadence, inactive monitor runtime, and incomplete retention or baseline evidence surface in a stable order rather than as ad hoc prose.

The retained probe family shows that this contract is empirical rather than purely documentary. The baseline-monitor runtime probe keeps the current state at sim:canary while generating a non-activation live-projection packet whose lockdown-prerequisite bundle is fully green, confirming active monitor runtime plus retained normal-stream and baseline-window evidence without falsely claiming that the system has already moved to sim:live. The validation-cycle lineage probe preserves append-only two-cycle linkage, so the latest cycle retains prior validation, baseline, and analysis anchors rather than overwriting them. The restart-continuity probe then shows the same continuity state marked preserved across a resumed live-mode cycle, while the malformed-state recovery probe marks continuity degraded with major_check_failed:baseline_monitor_state_malformed, repairs the saved anchors into a normalized form, and still writes a fresh validation cycle instead of discarding state silently.

Taken together, the runtime contract is watchdog-governed, names-only, and deliberately fail-closed. watch and canary are isolation states, whereas live and honeypot are lockdown requests that must prove tighter cadence and stronger continuity before the control plane will admit them. The reader-facing implication is straightforward: runtime authority in this project is not merely “which process is running,” but which $(source,mode)$ state has been explicitly gated, written, and evidenced under the current posture rules.

The retained evidence base for this appendix consists of three aligned surfaces: the ApexLab reference-validation runner projects/apexlab/examples/reference_validation_run.py, the machine-readable metrics artifact projects/apexlab/logs/metrics/reference_validation_20260324.json, and the companion validation report projects/calamum-moltbook-observer/docs/reports/validations/APEXLAB_REFERENCE_VALIDATION_REPORT_20260324.md. Together, those surfaces record the validation question, declared thresholds, observed deltas, and interpretation boundary in a form that is both reviewable and reproducible.

The validation question was simple and operationally important: are the current lightweight ApexLab comparison and regression helpers close enough to trusted SciPy and scikit-learn references to support the active Observer integration lane without adding heavyweight runtime dependencies? A passing answer in this context requires bounded numeric agreement under declared tolerance bands.

This appendix therefore presents the results in grouped numeric displays rather than one compressed narrative summary. The grouping follows the validation design itself: statistical comparison, OLS regression, and logistic regression.

Table 10 keeps one compact entry point at the front of the appendix, using the capability-group matrix idea from the earlier draft but tightening it into a denser numeric overview.

This validation supports the use of ApexLab as lightweight analytical infrastructure inside the Observer workflow. Its scope is reference alignment on small deterministic fixtures, giving the current lane a clear and reproducible baseline. The main empirical claims of the paper still rest on the dataset, calibration, lineage, and governance evidence summarized in the earlier appendices. Appendix J adds a different kind of confidence: the supporting statistical and regression helpers behind that analytical lane have been externally checked under declared thresholds.

That distinction is why this appendix belongs at the end of the stack. The calibration and score-surface displays in Appendix D remain the reader-facing Observer outputs that matter most empirically, while this appendix explains why the lightweight analytical surfaces sitting beside that broader lane can be treated as methodologically credible supporting infrastructure.

For the current Observer integration lane, the appropriate conclusion is straightforward. The 2026-03-24 ApexLab reference-validation run passed all declared capability groups. The strongest alignment appears in the statistical-comparison and OLS sections, which matched their references to effectively exact precision on the retained fixtures. The logistic section also passed and is strong enough for present use, while its non-convergence diagnostic remains an honest signal worth carrying forward into later optimization work.