For those not familiar, the SoW is a consulting agreement between contractor and employer, which defines the scope and timeline and requirements etc to “do the needful” in a broader sense of everyone’s favorite phrase from the ‘ol “Follow the Sun” SLA support model from the early pre-Cloud era (sorry cloudbabies it’s from when you were single digits old or not yet born).

This specific SoW has been used in prior endeavors which eventually follow the typical enterprise hardware lifecycle in no specific order [1]: forklifts, retros, rebuilds, expansion, and… words.. so many words.

Labs last a long time, so it’s important to build things correctly the first time - not waste time hacking together whatever compromised decision trees were necessary due to last-minute planning (or no planning at all) and little to no experience with building labs. Remember, if you are a specialized engineer who excels in one or two areas, that does not imply domain specific knowledge from adjacent or entirely different sides of engineering worlds. I’m a systems architect .. I don’t build jet engines (though it’s probably fun), so I do what I’m good at. Otherwise to say, “stay in your lane or learn to love losing - but protect that ego at all costs and never admit fault ever!” (yes, I’m bitter and for exceptionally valid reasons).

So, until the pre-IPO runway runs out, or the post-IPO environment bores people to tears and they jump ship with their ISOs and RSUs and START ALL OVER AGAIN! (I have definitely never not done this exact thing several times never for sure for sure? sure.)

Successful Labs Require People and Hardware

Vaporware labs don’t have hardware. Real labs do not revolve around PPTX slide decks, or Slack Canvas, or Sharepoint whatever, or ephemeral Confluence pages that change ownership by a click of a button. Real labs have real hardware and real engineers and architects involved at every critical stage to ensure that standards are being used, implemented, tested, and validated.

If you think I’m wrong, go ahead, do it all by slide deck, by half-baked simulators that don’t even use SST and parallelization correctly, with lots of Big Discussions for the Big People you want to impress to get ahead instead of making quality hardware.

See how far the Peter Principle gets you - chances are, if you’re surrounded by “Yes Men” and “C-Suite but never Technical” boardrooms, you will get far enough to be proven the fraud that you are.

The Peter principle is a concept in management .. which observes that people in a hierarchy tend to rise to “a level of respective incompetence”: employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.

Having risen rapidly, since you’re up high now - you can destroy entire companies by making extremely stupid choices “to save money” by not spec’ing hot-swap trays for NVMe drives on 1U systems which were never designed for the wattage you’re running - and were not spec’d for the BTU and LFM required to keep the systems from burning out 100G optics..

Just when you think it’s all good, um why are there only seven drives in this chassis that can run with eight?

• Oh it’s because the 8th drive would draw too much power and overload the non-redundant PSUs. What happens when a system which should have N+1 has only N?
• The PSUs could be in redundant mode but Billy didn’t want to authorize the enablement of active/active mode, and instead has demanded that his lacky make the systems run the PSUs in “combined mode” to try to get more power to that 8th drive… but no… not possible.
• So all of the fancy new systems can’t have eight drives like the original spec REQUIRED in order to fulfill global fleet machine generation scaling models. As in, you lose 1/8th of your drives on every new system for so many thousands of systems. 1/8th, for those not inclined to fractional conversions, is
• So now all of those systems will be missing ~2-16-64TB of NVMe drives (multiply by number of nodes per rack, per pod, per cage, per site, per region, per global fleet). That’s a lot of expected high-speed storage that is now not being deployed.
• Hopefully no contracts were made to customers based on “Total NVMe Raw Storage per <unit/region/etc>” variables, which now renders the deliverable impossible.
• What can be done? Those contracts have to either be revised and compensated (yeah good f’in luck), or a massive workaround must be implemented to compensate - at additional cost to the company.

Why does that matter to building labs?

Because any lab worth their salt would have raised immediate red flags and halted the entire ill-devised scope. Then they would use standardized and periodically revised for betterment:

• provide technical backing evidence
• scaling costs, IOP/s cost, power assessments, baseline to STDDEV ratio, then appropriation wear-cycle equations
• All that industry jargon that managerializes into the ether for all to repeat.
• “keep me honest” you may say, so then.. are you often lying? Ill-informed, unprepared, completely clueless?
• Maybe not, hopefully not, but analytical people will see you that way and eventually the Peter Principle catches up and BAM! You’re hit by a and your entire team is fired, and so you move on with your RSUs, talk yourself up, and try to ruin those who smote you from afar.

Congrats, Billy, you’ll never change - and that is why we test in labs - because things change.

The Contract Statement of Work

Always get the scope in writing with sign-off. Scope changes mid-stream, not awesome.

Statement of Work

Consultant Services Engagement

This Statement of Work ("SOW") is entered into between [Client Legal
Name] ("Client") and [Consultant Legal Name] ("Consultant"), effective
as of [Effective Date], and is governed by the [Master Consulting
Agreement / Professional Services Agreement] dated [Agreement Date] (the
"Agreement"). In the event of any conflict between this SOW and the
Agreement, the Agreement will control.

  -----------------------------------------------------------------------
  Client                              [Client Legal Name]
  ----------------------------------- -----------------------------------
  Consultant                          [Consultant Legal Name]

  SOW Effective Date                  [Effective Date]

  Initial Term                        Six (6) months from the SOW
                                      Effective Date

  Target Level of Effort              Forty (40) hours per week,
                                      approximately 1,040 hours over the
                                      initial term

  Primary Stakeholders                VP, OCTO, Eng-Org, App-Team, and
                                      Sales-Org

  Commercial Terms                    Billing rate, invoicing, payment
                                      terms, and approved expenses as set
                                      forth in the Agreement and/or
                                      applicable order form
  -----------------------------------------------------------------------

1. Purpose and Objectives

The Consultant will provide technical leadership, architecture,
implementation, documentation, mentoring, and subject matter expertise
to establish standardized HPC benchmarking, workload automation, and
telemetry/analytics capabilities, while also improving cross-functional
execution and the overall developer experience for CORP products and
associated collateral.

- Define, document, and deploy a modular "Industry Expectations
  Benchmark Suite" leveraging HPC, SPEC, Top500, AI/ML GPU leaderboards,
  and SNIA methodologies to support rigorous adherence and consistent
  results using standard performance testing tools.

- Define and deploy a standardized HPC "Workload Automation Pipeline"
  utilizing SLURM, Jenkins, Celery, RabbitMQ ("RMQ"), ClickHouse,
  Ansible, and related tooling.

- Define and deploy a standardized HPC "Telemetry + Analytics
  Aggregation + Data Visualization Processing Pipeline" utilizing
  Check_MK, SNMP, Elasticsearch + Kibana, Prometheus, InfluxDB, Grafana,
  and related tooling.

- Assess current organizational working patterns across Eng-Org,
  App-Team, and Sales-Org and provide a quarterly review to the VP and
  OCTO.

- Assess the current CORP collateral surface area, including SDKs,
  documentation, libraries, proofs of concept, and reference designs, as
  an ongoing initiative to improve the developer experience.

- Author white papers, research documents, and related technical
  materials, with a feedback loop to validate and improve internal and
  external documentation.

- Provide mentoring for junior through senior application and systems
  engineers, plus reasonable availability as an SME across storage,
  systems, database, and AI/ML domains.

- Provide ad hoc consultation to support Sales-Org customer scoping,
  implementation, and integration needs.

2. Term and Working Model

The engagement will begin on the SOW Effective Date and continue for an
initial six (6) month term. The Consultant will generally allocate forty
(40) hours per week to the engagement, subject to mutually agreed
priorities, holiday schedules, and reasonable scheduling adjustments.

The parties acknowledge that some workstreams in this SOW are ongoing or
iterative in nature. Accordingly, the Client and Consultant will jointly
prioritize and sequence the work so that the highest-value deliverables
are completed within the available time and level of effort.

Services may be provided remotely or through other mutually agreed
working arrangements. Any onsite work, travel, or work materially
outside the target level of effort will require prior written approval.

3. Scope of Services

3.1 Modular "Industry Expectations Benchmark Suite"

The Consultant will define, document, and deploy a modular benchmark
suite intended to measure representative performance, reproducibility,
and adherence to industry-standard methodologies across compute,
storage, and AI/ML use cases.

Illustrative deliverables:

- Benchmark taxonomy and workload catalog covering applicable HPC, SPEC,
  Top500-style, AI/ML GPU leaderboard-relevant, and SNIA-aligned
  methodologies.

- Benchmark execution standards, parameterization guidance, and runbooks
  designed to improve repeatability and result consistency.

- Result templates and reporting conventions for capturing baseline
  measurements and comparative findings.

- Initial implementation and/or deployment in designated Client
  environment(s), subject to infrastructure readiness and access.

- Validation summary describing observed results, known limitations, and
  next-step recommendations.

3.2 Standardized HPC "Workload Automation Pipeline"

The Consultant will define and deploy a standardized HPC workload
automation architecture using SLURM, Jenkins, Celery, RMQ/RabbitMQ,
ClickHouse, Ansible, and related tools as appropriate to the Client
environment.

Illustrative deliverables:

- Reference architecture and component interaction design for job
  submission, orchestration, execution, retry handling, and result
  capture.

- Deployment-ready configurations, automation artifacts, or initial
  implementation in designated environment(s).

- Operational workflows for benchmark or workload scheduling, execution,
  data collection, and reporting.

- Runbooks and handoff documentation sufficient to support repeatable
  operation and internal adoption.

3.3 Standardized HPC "Telemetry + Analytics Aggregation + Data
Visualization Processing Pipeline"

The Consultant will define and deploy a standardized observability and
analytics processing pipeline spanning infrastructure telemetry,
log/event aggregation, time-series monitoring, analytics storage, and
visualization.

Illustrative deliverables:

- Reference architecture covering Check_MK, SNMP, Elasticsearch +
  Kibana, Prometheus, InfluxDB, Grafana, and related integrations as
  applicable.

- Recommended data model, retention approach, dashboard structure, and
  operating practices for standardized reporting and analysis.

- Initial dashboards, visualizations, and/or deployment artifacts for
  designated environment(s).

- Documentation for data sources, ingestion paths, dashboards, and
  operational ownership considerations.

3.4 Cross-Functional Collaboration Assessment

The Consultant will assess current organizational working patterns
across Eng-Org, App-Team, and Sales-Org in order to identify friction
points, handoff gaps, role ambiguity, communication issues, and
opportunities to improve execution.

Illustrative deliverables:

- Current-state assessment and concise findings memo.

- Recommendations for cadence, decision ownership, communication flow,
  and escalation patterns.

- Quarterly review readout(s) presented to the VP and OCTO during the
  engagement term.

3.5 CORP Collateral Surface Area and Developer Experience

The Consultant will assess the current ‘surface area’ of CORP collateral,
including SDKs, documentation, libraries, proofs of concept, and
reference designs, as an iterative stretch initiative with the overall
goal of improving the developer experience.

Illustrative deliverables:

- Inventory and gap analysis of current CORP technical collateral.

- Prioritized recommendations and/or backlog themes to improve
  consistency, usability, completeness, and customer/integrator
  experience.

- Feedback loop for validating and improving internal and external
  documentation and supporting artifacts.

- Periodic progress updates and next-step roadmap recommendations within
  the engagement window.

3.6 White Papers, Research Documents, and Documentation Improvement

The Consultant will author white papers, research documents, technical
notes, and similar written materials as prioritized by the Client, and
will help create a feedback loop to validate and improve internal and
external documentation quality.

Illustrative deliverables:

- White papers, technical briefs, research documents, architecture
  notes, or similar written outputs as mutually prioritized.

- Document review comments, revision recommendations, and technical
  fact-checking input.

- Structured feedback loop to capture lessons learned and improve future
  documentation quality.

3.7 Mentoring and Knowledge Transfer

The Consultant will provide mentoring support for junior through senior
application and systems engineers, with an emphasis on practical
technical development and hands-on knowledge transfer.

Illustrative deliverables:

- Office hours, design reviews, pair-working sessions, workshops, or
  other mentoring interactions as appropriate.

- Guidance on benchmarking, automation, observability, storage, systems,
  database, and AI/ML topics relevant to the engagement.

- Knowledge transfer materials or summary notes where appropriate to
  support broader team adoption.

3.8 SME Availability and Sales-Org Consultation

The Consultant will maintain reasonable availability to organizational
staff in applicable subject-matter areas of focus and will provide ad
hoc consultation for Sales-Org customer scoping, implementation, and
integration needs, as capacity permits within the contracted level of
effort.

Illustrative deliverables:

- Advisory support for storage, systems, database, and AI/ML questions
  arising during the engagement.

- Participation in internal and customer-facing scoping discussions,
  solution reviews, or implementation planning sessions, when requested
  by the Client.

- Technical input intended to improve solution fit, implementation
  readiness, and integration clarity; provided as advisory support
  rather than as a standalone managed service or customer support
  commitment.

4. Indicative Delivery Plan

The following plan is illustrative and may be reprioritized by mutual
agreement based on Client needs, environment readiness, and emerging
business priorities.

  -----------------------------------------------------------------------
          Period          Primary Focus           Illustrative Outputs
  ----------------------- ----------------------- -----------------------
          Month 1         Discovery and Baseline  Stakeholder alignment,
                                                  current-state review,
                                                  environment access,
                                                  priority mapping,
                                                  benchmark/workload
                                                  definition, and
                                                  architecture framing.

        Months 2-3        Design and Initial      Benchmark suite v1,
                          Deployment              automation pipeline
                                                  design and initial
                                                  deployment artifacts,
                                                  telemetry pipeline
                                                  design, and initial
                                                  dashboards or data
                                                  paths.

        Months 4-5        Validation and          Validation runs,
                          Expansion               documentation
                                                  expansion,
                                                  collaboration
                                                  assessment findings,
                                                  collateral review,
                                                  white papers/research
                                                  outputs, and mentoring
                                                  support.

          Month 6         Handoff and Executive   Runbooks,
                          Review                  recommendations,
                                                  backlog or roadmap
                                                  items, knowledge
                                                  transfer, and
                                                  quarterly/executive
                                                  review presentation(s)
                                                  to the VP and OCTO.
  -----------------------------------------------------------------------

5. Governance and Reporting

- The Client will designate a primary engagement owner or point of
  contact responsible for prioritization, coordination, and consolidated
  feedback.

- The parties will maintain a regular working cadence, which may include
  weekly or biweekly syncs, technical reviews, design reviews, and
  status reporting as appropriate.

- The Consultant will provide concise updates on progress, risks,
  blockers, and recommended next actions.

- A quarterly review readout will be provided to the VP and OCTO during
  the engagement term.

6. Assumptions, Dependencies, and Constraints

- The Client will provide timely access to relevant systems,
  environments, credentials, documentation, repositories, data, and
  subject-matter stakeholders reasonably required for the services.

- The Client is responsible for providing or approving the hardware,
  software, licenses, network access, security approvals, and
  change-management windows required to implement or deploy
  deliverables.

- Any production deployment, change control, or release activity remains
  subject to Client approval processes and operational safeguards.

- Where this SOW references industry-standard benchmarks or
  leaderboard-adjacent methodologies, any formal external publication or
  third-party submission will remain subject to separate Client approval
  and third-party rules.

- The Consultant’s work product may include recommendations, reference
  architectures, configurations, code or scripts, runbooks, dashboards,
  presentations, reports, and live working sessions; not every
  workstream will result in a standalone written deliverable.

- Because certain activities are advisory and ongoing in nature, the
  parties will periodically rebalance priorities to remain within the
  contracted time and level of effort.

- Travel, onsite presence, after-hours support, and work materially
  beyond the initial term or weekly level of effort are excluded unless
  separately approved in writing.

7. Out of Scope

- Managed services, long-term production operations ownership, or 24x7
  operational support.

- Hardware procurement, datacenter installation, or unrelated
  infrastructure build-out not directly tied to the services described
  in this SOW.

- Binding commitments to end customers, contractual promises to third
  parties, or customer project delivery obligations not expressly
  authorized by the Client.

- Ongoing maintenance, enhancement, or support of deliverables after the
  end of the engagement term, except as separately agreed in writing.

8. Acceptance and Change Control

Commercial terms, invoicing, payment terms, intellectual property,
confidentiality, warranties, limitation of liability, and any formal
acceptance procedures will be governed by the Agreement.

Where the Agreement does not specify a separate acceptance procedure,
the Client will review deliverables promptly and provide consolidated
feedback within five (5) business days after delivery. Deliverables will
be deemed accepted when they materially conform to the scope described
in this SOW, subject to any documented punch-list items or agreed
revisions.

Any material change to scope, deliverables, timeline, or level of effort
will require written approval by both parties.

9. Signatures

The parties acknowledge and agree to this SOW as of the dates written
below.

By: ________________________________ 
Name: ______________________________ 


[Consultant Legal Name]
Title: _______________________________
Date: _______________________________
By: ________________________________ 

[Client Legal Name]
Name: ______________________________
Title: _______________________________
Date: _______________________________

More details later… sleepy.

 # NeoCortex Standards, Repo Storage, ZFS Dataset, M70 QAT Fast-Track Plan

  ## Summary

  Implement a non-destructive NeoCortex follow-up that locks
  these policies into code, tests, and docs:

  - Repos live under /opt/repos/<repo>; worktrees live under
    /opt/repos/worktrees/<repo>/<branch>.
  - /root is not a repo/worktree destination; /root/OMGFUCKED is
    temporary quarantine only.
  - New repos must be created from
    yukon-systems/YukonSYS-Standard-Definitions.
  - Every repo must use Git LFS and the standards repo
    .gitattributes byte-for-byte.
  - ZFS dataset creation for /opt/repos becomes reusable
    Ansible/policy logic, based on
    /root/bin/ZFS-M70-Forge_zroot-dataset_opt-repos.sh.
  - M70 QAT rollout uses canary first: build OpenSSL+QAT and
    OpenZFS/QAT binpkgs, validate on M70 canary, then promote.

  ## Key Changes

  - Standards and repo-placement policy
      - Update NeoCortex root policy docs and tests to forbid
        new repo/worktree paths under /root, except documented
        temporary quarantine paths under /root/OMGFUCKED.
      - Update tools/import-source-repos.py defaults from
        /root/<repo> to /opt/repos/<repo>, with
        /root/OMGFUCKED/<repo> accepted only as an explicit
        transitional override.
      - Add a repo-location audit script/test that fails active
        operational docs/scripts using /root/<repo> or
        /root/.config/superpowers/worktrees as live paths.
  - Git LFS and .gitattributes
      - Replace NeoCortex root .gitattributes with the standards
        repo version byte-for-byte.
      - Add a validation script that checks:
          - git lfs version works,
          - filter.lfs.required=true,
          - origin LFS locksverify=true,
          - root .gitattributes hash equals standards source,
          - LFS pre-push hook exists.
      - Document that non-compliant repos must be retrofitted
        before migration/import.
  - ZFS dataset automation
      - Convert
        /root/bin/ZFS-M70-Forge_zroot-dataset_opt-repos.sh into
        reusable NeoCortex Ansible/defaults for managed
        datasets.
      - First managed dataset profile: zroot/opt/repos mounted
        at /opt/repos with the script’s options, including
        compression=zstd-fast-1, dedup=sha256,verify,
        recordsize=256K, xattr=sa, POSIX ACLs, atime=off, and
        reservation=32M.
      - Add a second reusable pattern for per-user home
        datasets, but do not block on the NAS/NFS 777
        investigation; include a permission preflight that
        creates a test directory with umask 0027 and fails if
        mode becomes 0777.
  - M70 QAT binpkg fast-track
      - Extend the existing M70 canary stage4/binpkg lane to
        build a QAT package set:
          - QAT firmware/kernel module readiness package policy,
          - OpenSSL QAT engine/provider package path,
          - OpenZFS package built with QAT support,
          - rollback stock OpenSSL/OpenZFS binpkgs.
      - Add package/use/profile fragments under the existing
        Gentoo stage4 profile area instead of ad hoc host edits.
      - Add canary validation:
          - lspci -nnk sees QAT device,
          - qat_c3xxx and intel_qat load,
          - OpenZFS module parameters expose QAT controls,
          - openssl speed before/after artifacts are captured,
          - root pool imports and mounts after reboot,
          - rollback binpkg path is tested before wider
            promotion.
      - Do not promote to all M70 nodes until canary evidence is
        committed.

  ## Test Plan

  - Local static checks:
      - tests/shell/run-tests.sh
      - new repo-location standards test
      - new Git LFS standards test
      - new ZFS dataset defaults test
      - new M70 QAT package-policy test
      - YAML parse for all workflows/playbooks
      - git diff --check
  - Runtime/dry-run checks:
      - Ansible syntax-check for dataset roles/playbooks.
      - Dry-run dataset plan for /opt/repos confirms current
        zroot/opt/repos matches expected options.
      - M70 canary dry-run emits QAT binpkg build plan without
        mutating packages.
  - Canary acceptance:
      - QAT binpkgs build successfully.
      - M70 canary reboots with root pool intact.
      - QAT modules and OpenZFS QAT controls are present.
      - Benchmark and rollback evidence are recorded under
        NeoCortex audit docs.


  ## Assumptions

  - Canonical repo clone layout is /opt/repos/<repo>.
  - Worktree layout is /opt/repos/worktrees/<repo>/<branch>.
  - /root/OMGFUCKED remains temporary quarantine, not an
    approved steady-state repo location.
  - QAT rollout gate is canary first, not all-M70 immediate.
  - OpenZFS QAT implementation details must be verified against
    current OpenZFS/Gentoo package behavior during
    implementation; source basis includes OpenZFS QAT docs and
    module-parameter docs:
      - https://openzfs.org/wiki/ZFS_Hardware_Acceleration_with_QAT
      - https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html

─ Worked for 22m 41s
───────────────────────────────────────────────────────────
  Implement this plan?
  1. Yes, implement this plan          Switch to Default and
  start coding.
  2. Yes, clear context and implement  Fresh thread. Context:
  53% used.
› 3. No, stay in Plan mode             Continue planning with
the model.



-----------------------
  ## Assumptions

  - Canonical repo clone layout is /opt/repos/<repo>.
  - Worktree layout is /opt/repos/worktrees/<repo>/<branch>.
  - /root/OMGFUCKED remains temporary quarantine, not an
    approved steady-state repo location.
  - QAT rollout gate is canary first, not all-M70 immediate.
  - OpenZFS QAT implementation details must be verified against
    current OpenZFS/Gentoo package behavior during
    implementation; source basis includes OpenZFS
    QAT docs and module-parameter docs:
      - https://openzfs.org/wiki/ZFS_Hardware_Acceleration_with_QAT
      - https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html

─ Worked for 22m 41s
───────────────────────────────────────────────────────────

› 1) We also need to include the control plane fixes and
validations so that mutli-workers comms are fixed. 2) We need to
leverage the SLURM cluster nodes and
  additional distcc build hosts, 3) X12again & FMT2 are
  effectively idle and can be blasted into submission to fast
  track all of these changes. 4) Once the
  M70-canary passes, we need to roll it out to K10 (tear-it-down
  AAA) and validate that type of OS netbooting. 5) Add those
  aspects to the Plans and we're
  looking better. 6) Finally, wrap up ALL changes necessary to
  complete the NeoCortex monorepo migration.

───────────────────────────────────────────────────────────

• I’ll revise the plan around the expanded end-state, but first
I’m doing a read-only pass over NeoCortex’s control-plane,
SLURM/distcc, X12/FMT2/K10, and
  migration-status artifacts so the replacement plan is grounded
  instead of generic.

───────────────────────────────────────────────────────────

• Proposed Plan

  # NeoCortex Standards-Complete Monorepo Migration Plan

  ## Summary

  - Make /opt/repos/<repo> the only canonical repo location; no 
  new checkouts or random repo files under any home directory, 
  including /root.
  - Finish standards adoption: all new repos must originate from 
  YukonSYS-Standard-Definitions; NeoCortex gets retrofitted 
  instead of restarted unless
    retrofit verification fails.
  - Complete NeoCortex monorepo migration with standards baseline, 
  Git LFS policy, control-plane comms fixes, ZFS dataset policy, 
  SLURM/distcc acceleration, M70 QAT canary, FMT2/X12again build 
  capacity, and K10 netboot AAA rollout validation.

  ## Key Changes

  - Repository standards
      - Merge standards policy PR work, then make NeoCortex 
      root .gitattributes byte-for-byte identical to the standards 
      repo version.
      - Update active NeoCortex import/migration tooling to default 
      source paths to /opt/repos/<repo>.
      - Preserve historical /root/... references only in immutable 
      audit/provenance docs; active scripts, runbooks, tests, and 
      templates must not depend on
        home-directory repos.
      - Use worktrees under /opt/repos/worktrees/<repo>/<branch>.
  - NeoCortex monorepo completion
      - Finish all migration blockers already tracked in 
      NeoCortex: M70 stage4/QCOW validation, Kata/container 
      runtime, FMT2 ephemeral VM lane, Gentoo/OpenRC
        replacement for temporary Rocky bootstrap, Thor replacement 
        path, and optional history graft/freeze decision.
      - Treat NeoCortex as authoritative after completion: source 
      repos become frozen compatibility references or are 
      history-grafted into NeoCortex with
        documented provenance.
      - Add/repair migration validation so PR completion proves 
      standards baseline, Git LFS, repo location policy, shell 
      tests, YAML parsing, and migration
        manifests.
  - Control-plane and multi-worker comms
      - Bring all control-plane fixes into NeoCortex and validate 
      Forge/FCP worker communication end to end.
      - Add tests for FCP envelope validation, replay/nonce handling, 
      approval ceilings, routing scope, transport policy, ntfy bridge 
      behavior, and multi-worker request/response flows.
      - Replace temporary Rocky bootstrap control-plane host with the 
      compliant Gentoo/OpenRC image once that image passes validation.
  - ZFS, NFS, and storage policy
      - Use the provided /opt/repos ZFS dataset options as the canonical 
      dataset profile for repo storage.
      - Add reusable dataset/playbook logic for repo datasets and 
      per-user home datasets.
      - Add NFS/floating-home validation that detects the NAS NFSv4.2 
      0777 directory-mode bug under expected 0027 umask and blocks 
      insecure rollout.
  - Build acceleration and hardware rollout
      - Use SLURM plus distcc for M70 stage4/QAT/OpenZFS builds.
      - Treat X12again and FMT2 as available fast-track build/validation 
      capacity.
      - Build binpkg path for OpenSSL + QAT + OpenZFS on M70 canary first; 
      non-QAT nodes may consume the same binpkgs with QAT unused.
      - After M70 canary passes, roll the validated path to K10 and 
      run destructive AAA/netboot validation with rollback evidence 
      captured.

  ## Test Plan

  - Run NeoCortex shell/YAML validation, including migration, 
  standards-baseline, Git LFS, .gitattributes, and no-active-home-repo-path 
  checks.
  - Run control-plane/FCP tests for envelope schema, replay rejection, 
  worker routing, ntfy bridge, and multi-worker comms.
  - Run Ansible/playbook syntax checks for ZFS datasets, NFS home policy, 
  SLURM/distcc build orchestration, M70 canary, FMT2/X12again lanes, and 
  K10 netboot
    AAA.
  - Execute staged hardware validation:
      1. SLURM/distcc dry-run.
      2. M70 canary build and QCOW/stage validation.
      3. FMT2/X12again accelerated build/ephemeral VM smoke.
      4. K10 netboot/AAA destructive validation after M70 success.

  ## Assumptions

  - Retrofit NeoCortex rather than restart the repo unless standards 
  validation exposes unrecoverable divergence.
  - Historical audit files may retain old /root/... paths as provenance; 
  active operational content may not.
  - M70 canary is the release gate for QAT/OpenZFS/binpkg rollout.
  - K10 destructive AAA/netboot validation is in scope only after M70 
  canary passes and rollback evidence is captured.

─ Worked for 2m 18s ───────────────────────────────────────────────────────────

Adjusted Query: how much storage space would the user deploy to an existing multi-Petabyte array, with consideration to physical limitations in systems design which prioritize two common architectural decision targets: More or Faster?

(1) maximizing raw-block capacity
(2) maximizing I/O performance

TL;DR

Between 4-5PB is the simplest answer, but those are just numbers. Could be 10x either, but that’s not realistic - it’s conjecture. The full picture requires insight into physical limits of the transfer time, storage space, rack space, and rotational speeds involved; spacetime could be analyzed by the right minds if this were JPL ^_^ .. instead of limited to hardware I’ve acquired over a small handful of years.

Hypothetical or Reality

Let’s say that I contacted the datacenter and ordered additional power circuits to light-up additional drive shelves, which are already installed (minus the box of drive trays which are in a massive box on a parts shelf in my home office). Ok, reality checks out there.

The circuit drops would go to the central storage rack which is currently at 84% power limit. I know this because power is monitored and validated via a combination of Check_MK + Prometheus + SNMP exporters, which poll power stats remotely from the cabinet’s APC ATS, the rack’s per-port metered and switched outlet PDUs, and then if I really want to I can look at the DC’s circuit stats (via MRTG) which are tracked for the cabinet. Reality checks out there decently enough. Moving on…

The Hypothetical

First we’ll cover some raw numbers and theoretical maximums by looking at two high-level approaches required for “More or Faster”.

The astute reader may wonder why we’re not discussing >100TB QLC NVMe drives or ultra-dense E2 ruler-style 2U chassis, and the answer is that those calculations are generally similar in equation workflow (eg: how many things of X can we put into Y at A,B,C performance/size/latency), however those hardware types are not currently racked in my real-world systems at an interesting scale. However, migrating to denser NVMe arrangements will likely be part of an eventual down-scaling forklift operation whenever the SAS3 arrays are no longer useful for my personal labs or colo bills.

Production is another story, where large format SAS3 is still relevant and being deployed and improved over time; in the last several years we’re seen drive capacity double, along with some innovative designs. It’s not often considered exciting, but it lasts A LONG TIME, and the NSA loves archiving the internet on this medium over in their Utah storage complex (overheard, surely).

So, back to the math…

Decision: Optimize for Faster (prioritize IOPs + bw)

Aggregate per-rack w/ 10x shelves of raw 4K block = 3,824 TB == 3.72 PB

Decision: Optimize for RAW Storage Capacity

How about the same hardware focused on max-total raw space with less regard to per-drive IOPs (perhaps we offset the latency reduction per-drive via larger L1ARC and L2ARC buffers on the head-nodes, which becomes a loaded tangent)… then the rack could be upgraded to host 4.85PB @ $800/m MRC ($400/m cabinet + $400/m amperage)**.

We’ll also save the conversation about concessions made at time of contract signing where I might / maybe / surely have saved on recurring costs by locking-in a multi-year multi-rack contract. Sales team, thanks!

What is this MRC, MRR?

MRC in this situation is the ‘Monthly Recurring Cost’ for power + rack. This value does not include the cost of acquired hardware, which is variable on supply-chain sourcing and other factors. I’m also not going to describe potential MRC or MRR offsets which factor into profit margin potential and/or influence EBITDA.

Ok, what is MRR and EBID..? Fine, at least with MRR it’s ‘Monthly Recurring Revenue’, and one can read all about EBITDA elsewhere.

What about Flash-Cache or Optane or Non-Volatile blah blah blah

Sure, those are considerations, where applicable. Some footnote notes…

• It’s prudent to deploy storage controllers with SLC NVMe or PMem/NVDIMM persistent cache (which are often a baseline performance requirement). These are sized anywhere from cumulative 1-12TB per-controller, depending on available PCIe lanes and/or NV-DIMM slots.
• It’s a good idea to make scoping decisions like that ahead of time, instead of later realizing that the controllers’ lanes are maxed out or all DIMM slots are used (or you bought 128GB NVDIMMs instead of 512GB, thinking “8x 128GB should be fine for PMem” or the other fun one about ignoring (or being unaware) about GHz speed reduction by running 4-DPC in a 2-DPC max-perf system.
• Those determinations may be either workload dependent, or in my personal life sometimes it qualifies as the “because I wanted to” type of maximalist methodology, or the “this is relevant for future proofing my own rationalization on fun hardware”, or could be considered a baseline in pre-sales because “they always want more performance eventually; just bake it in from the start”. It varies, but remember where you started and where any future requirements for performance headroom exists.

Where’s the Math?

Validation on spec baselines can be tedious, but anyway… the DE3-24C and DE3-24P have very shiny and well made Dual-Redundant IOMs with 4x SAS3 SFF-8643 connectors.

Specs for our SAS3 Fabric with DE3-24 Shelves

• One SAS-3 lane (PHY): 12 Gbit/s ⇒ 1.5 GB/s (raw line-rate, decimal GB)
• External SAS x4 port connector: 4 PHY × 12 Gbit/s ⇒ 48 Gbit/s ⇒ 6 GB/s
• Each DE3-24{C/P} has 2× IOM, with each IOM having 4× SFF-8643 ports

Drive Specs - Seagate EXOS & Oracle SSD

Scenario A – Maximum RAW Block Space

Before going into the theoretical weeds, let’s look at some per-shelf media limits.

1) Oracle DE3-24P shelf w/ 24TB Spinners**:** 24 × 285 MB/s = 6.84 GB/s (media-limited)

2) Oracle DE3-24C shelf w/ SSDs:

• Read: 24 × 2150 MB/s = 51.60 GB/s → capped by fabric at 36 GB/s (N=3)
• Write: 24 × 1980 MB/s = 47.52 GB/s → capped by fabric at 36 GB/s (N=3)

Scenario B: Maximum Performance

Hardware has limits, and we’re looking at 8× DE3-24P w/ 18TB Mach.2 HDD + 2× DE3-24C w/ 7.68TB SSD (N=3)

Aggregate sequential bandwidth (N=3)

• Mach.2 18TB HDD shelf: 24 × 554 MB/s = 13.296 GB/s (media-limited; below 36 GB/s fabric cap)
• SSD shelf: remains fabric-capped at 36 GB/s read and write (N=3)

Aggregate Random R/W 4K IOPS (N=3)

Fabric-derived 4K IOPS cap per shelf (upper bound):
36 GB/s @ 4KB = approx 8.79M IOPS

• SSD shelf
  • Read: 24 × 450k = 10.8M IOPs → capped to 8.79M IOPs
  • Write: 24 × 95k = 2.28M IOPs → media-limited (below fabric cap)
• Mach.2 HDD shelf (4K @ QD16)
  • Read: 24 × 304 = 7,296 IOPs
  • Write: 24 × 560 = 13,440 IOPs

Let’s See the Deltas!

What’s “a delta”? Sometimes it’s the headwaters of a bay, where the river distributes across a flood-plane into many separately-unified channels, eventually giving way to deeper waters and…. no no not that kind.

Delta as a value in storage is often used as a marker to show the differential of two functions which indicates directional change. At least, that’s what comes from my brain while I sit here having an ice cream sandwich, but it has some alternate terminology which applies irrespective of ice cream hour:

Delta uppercase Δ, lowercase δ
Uppercase: a change of any changeable quantity
Lowercase: the central difference for a function

~ The discriminant of a polynomial equation or symmetric difference of two sets
~ The determinant of the matrix of coefficients of a set of linear equations

Scenario B vs Scenario A (with N=3)

• Total sequential BW: 126.72 → 178.368 GB/s (increase +51.648 GB/s)
  • Primary determinant: per-shelf BW 6.84 → 13.296 GB/s (Mach.2 dual-actuator).
• SSD tier remains fabric-capped at 36 GB/s per SSD shelf under N=3; increasing N (or adding more independent uplinks with additional HBAs) is what changes that cap.

1. Faster array = less space @ higher IOPs and BW == 178 GB/s @ 3.8PB
2. Larger array = more space @ lower IOPs and BW == 126 GB/s @ 4.9PB

Equations w/ decimal units: 1 TB = 1000 GB

• jaja usually we work in 1024 (but I’m tired today, so not right now)

t_1TB(s)      = 1000 / BW_GBps
t_full(s)     = (Capacity_TB * 1000) / BW_GBps
t_full(hours) = t_full(s) / 3600
BW_density    = BW_GBps / Capacity_TB   (GB/s per TB)
              = 1000 * BW_density       (MB/s per TB)

So… what’s the answer? More, Faster?

Is bigger is better? Sometimes. Sometimes you need it faster. Sometimes you want both.

People in the industry are playing hard and fast, and whether those qualities may be considered a good thing is up for endless debate, but not right now. Right now I’m going to show some End of Year snapshots which are relevant to the blog’s purpose: wtf am I doing here anyway?

2025 was mostly extremely challenging, and mostly in helpful ways, but also featured a repetition of lessons which it seems I need to reflect on for additional forward momentum.

Let’s take a look at some of my core qualities as told by the oft-loved and oft-maligned OpenAi’s Chat-GPT 💟.

Your Year, Painted in Pixels

Very close, nice work GPT. While I do not have a 400GbE switch on my desk, I do have a few 100GbE 32-port switches in the racks, and occasionally 200GbE NICs and optics will float around the test bench.

The Architect Archetype ~ 3.9% of ChatGPT Users

It’s true! Over the 25 years of this career I’ve held architecture specific roles across the domains of Hardware Systems, Infrastructure Automation, Databases, and HPC Storage realms. It’s what I’ve always wanted to do, going all the way back to 1985 when introduced to the 4.77MHz IBM PC, Model 5150.

Personality: Specialist, Planner, Conceptual

That’s fairly accurate, more so if we add “spatial reasoning” to a list of cognitive methods.

“Thinks in structures and systems. Uses ChatGPT to design elegant frameworks and long-term strategies within a domain.”

A Datacenter in the Living Room?

Close in accuracy, however the “living room datacenter” is more commonly located in a home-office room (when living in an apartment), or in a dedicated area of the garage with HVAC filtration + dedicated 208/220/240V power, and the requisite automated cooling systems (usually Tripp-Lite units with duct-blowers). For systems at home the machines are often bought as separate server components along with a 4-5U chassis + rails + multiple sub-50 decibel large-format 120-180mm fans. Systems with high RPM 40-80mm axial screamers belong in a proper colocation facility.

How about that Homelab - is it in a constant state of flux?

Yes, mostly. It’s often helpful for proof of concept tests, hypothesis validation, and running benchmarks without having to drive to the DC or go back and forth with Remote Hands requests. Plus, lots of fun going on with hardware at home, but sometimes results in broken nails 😔.

Messy cables? Sometimes. Labels? Sometimes.

The homelab is often rebuilt: storage devices, fiber, dac, cables, and test clusters revised.

Homelab, sure… but how about those colocation photos instead?

As we’ve seen, some of the server hardware lives at home in my 25U shorty-racks, some is across the bay at a datacenter where big-loud machines require CRAC style cooling, and some of it is spread across the globe at other colocation facilities where The Providers have megawatt and gigawatt infra capacity. My personal infrastructure is a hybrid design, utilizing everything from embedded systems to multi-GPU hosts to public-cloud virtual machines… so, let’s see a bit more…

• Recent datacenter photos: https://prose.winterschon.com/a-recent-datacenter-colo-visit/

Your Chat Style

The analysis says… well, it’s fairly accurate for a description of being in-person as well as at the keyboard during remote meetings or daily chats.

Technical or otherwise, usually this is consistent. I’m often chatty, verbose, attentive, talkative, opinionated, even positively bubbly at times. Unless you catch me on a day where those qualities are supplanted by the clouds of quietly recalcitrant moods - the type which are grounded on a dualistic view of existence best described as Stoicistic-Nihilism, having been sourced from far too many post-traumatic stress events endured.

Your Chat Style: Direct, technically precise, often layered with humor and a critical edge, mixing structured reasoning with conversational spontaneity and sharp observational wit.

Your 2025 Chat Stats

Hold on now. I’ve used em dashes since 6th grade English class—so if seeing those in my writings is giving an impression that I use LLMs for all of my authoring is quite incorrect. For all of those people who don’t like them I have a solution: go to the settings section and set your rules and move on with your life. 😏

• Total Chats: 720
• Messages sent: 4,861 (not tokens, messages)
• Chattiest day: September 5th (why? we’ll need to see…)
• Images generated: 3 (Sora kinda sucks)
• Em-Dashes “Exchanged”: 1,882
• Top Messages Sent: 1% (percentile)

Regardless of those stats, even with my use of ChatGPT’s advancements with their “Pro Account”, most of my Ai/ML occurs on self-made infrastructure. I don’t rely on closed source, I don’t like closed source, and I don’t like non-democratized intelligence services that are just in it for profit. My career was built on Open Source and this current infra uses tooling like Ollama, Open-WebUI, vLLM, llama.cpp, CUDA, PyTorch, ROCm, and many other examples of collaborative ingenuity - free to use, free to improve, so please contribute if you can.

Three Big Themes of 2025

1. Building Ultra-Low-Latency Systems (true)
2. Experimenting, Measuring, Refining (true)
3. Engineering Meets Everyday Life (true)

Thoughts on 2026, Ai Industry Trends != Rules

Working in the Ai/HPC/ML industry, an observable fact is that the majority of consumer-facing Ai companies are still trying to figure out this new landscape, how it works, why anyone should care, and how to monetize whatever it is that they’re focused on.

Most will repeat the errors of the past, most will fail, most will malign the tech while misunderstanding nearly everything about the topic; and that’s fine. That’s the routine in Silicon Valley, but it doesn’t have to be.

1. We cannot solve today’s problems with yesterday’s methods, and that is a simple fact. We need the core technologies involved with Ai in order to resolve the massive amount of tech debt from earlier generations, but we need to stop expecting the same success from the same methods from the past; this is not the same world as 10, 20, or even 5 years ago.
2. The current anti-Ai mentality in mass-media is occurring despite companies like IBM, Cray, Fujitsu, BullSequana, and a handful of others with Top-500 dominant postures being focused on Ai-enabled Supercomputing, HPC, and acceleration hardware domains for well over two decades. These clusters have been active at research facilities with names like CERN, Technion, and of course the DoD and Military labs. These clusters keep us safe, they advance human understanding, assist with solving otherwise unsolvable problems, and are used to maintain the systems and functions our current world relies on for security and the advancement of human potential.
3. Ai is not just chatbots, it’s not limited to multi-modal agentic buzz-words, but that’s a tangent for another day. Datacenters are not ruining the world like mass-destruction of rainforests just so people can eat more cows. Conversely, we have an entire section of the Supercomputing industry focused on green energy and resource efficiency. Medical advancements, brain research, climate science and modeling, cancer research, etc… all of this is and has been advanced by Ai - but it’s not from the consumer side and it’s not how the media presents the information. Gosh, I wonder what incentive the media has to engage in such maligning tactics?

How Do We Move Forward?

In spite of or despite anti-Ai sentiments, while the public-facing corporate marketing landscape fights for “Consumer Economy Dominance”, engineers and architects like myself are busy in the background innovating with (sometimes our own) Ai/ML systems and (sometimes our own RSU/ISO/BST* funded) heavy-compute big-data storage infrastructures.

People like myself do this because we love it (mostly, nothing is perfect), and because we want to improve the lives of those around us, not to simply make money and acquire material goods. These skills require compromise, dedication, attention to detail, and a deeply held desire to improve the human condition through personal investment of time, mentoring younger engineers, and the occasional runway.

TOGETHER WITH THE AIs WE WILL BUILD A BETTER ULTRON

Kidding, mostly. Ultron had some good philosophical points, but we’re not in Strawberry Fields or the BS about paperclips from unimaginative and uninformed bloggers; this is real life and The Terminator is not around the corner. Pass the espresso and let’s check the local-node TTFT and CHRs to see how SkyNet is doing. ❤️

So, where to begin… let’s see… we start with the POWER9 at home on my desk, and me looking a wreck in the morning…

Where is this wonderful place that brings me so much joy? Hurricane Electric of course.

For Silicon Valley datacenter nerds, Hurricane Electric’s Fremont and San Jose facilities are the spiritual home of budget-friendly colo: cabinet and partial-cabinet plans with same-day turn-up, straightforward BGP, and native v6 on a backbone that’s been aggressively peering since the early 2000s, making it a historically significant and still notably affordable place to park gear in the Bay Area.

And as such… it’s where most of my gear resides. What was once a HomeLab at home has become a situation of _“let’s move everything into the colo and tell PG$E to suck it on their $300-600/month apartment electric bills (which is physically impossible, they’re a proven CA Governor sponsored monopoly).

Tools and So Forth

How about a photo of my lovely Wera designed Datacenter tool bag? Yes! It’s rugged and strong and doesn’t distort with heavy items. Love it. At the top of the photo is whichever purse happened to be brought along that day; Kors or Burbs or Coach or whichever fit size requirements at the time.

Not shown: a squared-rasp-file occasionally required for “standardizing” the rail mounting holes in those old-ass blue racks. My right hand still has scars from years ago - before owning that rasp to fix the burrs.

Always Getting Injured, but that’s OK.

Now, about those old scars - there are surely new ones periodically. While getting ready for the colo, just standing at the sink with some sheers, cutting… cutting… and ohffs that’s my finger. Yep, it’s definitely deep! Apply pressure! Wrap it tight! Not too tight though… and what was at my disposal? Paper medical tape and clear plastic industrial packing tape.

FINE. It’s FINE. The bleeding mostly stopped, and off we go to the datacenter!

done cut my self real bad

Networking, Servers, Drives, DPUs, and all the other fun!

Ok, enough rambling. Here’s a photo gallery with annotated pics. Each rack has some major revisions to undergo, which requires planning and documentation updates and all the usual production readiness routines.

More Hardware - More ARM64!

Now you may wonder, where is all of my ARM64 equipment and the other clusters? Those are still in the 2x 25U racks at home – they’ll be migrated to the colo as well, once I convert them to use industrial Compact-PCI chassis blade mounts with integrated/redundant power and backplane. I bring you… the ADLINK cPCIS-2632R 3U Compact PCI chassis.

Industrial ADLINK cPCIS-2632R CompactPCI

SATA3… Really?

And we wrap up the day’s fun with… decisions on what to do with these SATA3 SSDs recovered from some old R420 systems… perhaps the LC922 boxes can use those + some 240GB Intel or Samsung boot drives. These days I never bother with SATA, only SAS or NVMe. HoHumBoringSataSoSlow.

A Tale of Two Labs - One is Real, The Other…

I love having my own hardware for my own labs. I love not having to rely on a corporation over-promising on lab resources for the architecture design process – real physical hardware which is absolutely required for “Proof of Concept Engineering”.

As a wise-one once related, not everything can be a Power Point Presentation. Engineers need physical hardware for validation workflows, otherwise it’s all just vaporware.

🙉 🙈 🙊

In preparation for a hardware refresh and much needed colocation visit, I’ve ordered additional Mellanox DPUs. Those require a few additional cables to augment the existing hardware stockpile. I already have some 100G to 4x 25G breakouts, but not enough, and not in the correct lengths. Yay for ebay, all acquired for under $100 as “new old stock”.

What do those DPUs look like?

Well, for starters they don’t look exactly like these old ConnectX-3 QDR Infiniband NICs but the DAC are similar. Mellanox changed their heatsink aesthetic along the way, and the heatsinks are far larger on the newer chipsets, with no less cooling required (~200+ LFM).

Mellanox ConnectX-3 Infiniband NICs and QDR DAC from ~2015, photo circa 2022

Once the DPUs arrive - which is supposed to be today - I’ll take some photos and clean all of the PCBs and traces and slot connectors. In the interim, here’s the eBay photo for reference.

The big question… spend precious time with the R630 cluster in cab68, remove their ConnectX-4 Dual-Port 100G NICs, or install the BF2 DPUs to the cluster of IBM LC922 POWER9 systems in cab70… hmmmm.. 🤔 This decision will not be completed today. So, let’s think about cable maps and rack units.

Here’s a lazy ASCII diagram

Showing three lengths of DAC being used for rack-height designated connections, each cable SKU being 0.5M longer/shorter to account for the destination system’s location. DAC is heavy, so any time we can make the cable runs shorter we’ll (perhaps marginally) reduce latency while reducing load on the rack-cabling organizers, and generally resulting in a cleaner layout. The following diagram is not to scale for either cab68 or cab70, it simply shows how the waterfall method uses length-based drops.

+----------------------------------------------------------+
| RU42 | [Leaf Switch, QSFP28/56]                          |
|      |  [P01..P16]                                       |
|      |     |                                             |
|      |     +-DAC-1 1.5m ——————————> [RU38] Server-A      |
|      |     +-DAC-2 2.0m ————————————> [RU32] Server-B    |
|      |     +-DAC-3 2.0m ————————————> [RU26] Server-C    |
|      |     +-DAC-4 2.5m ———————————————> [RU20] Server-D |
+----------------------------------------------------------+

Labeling scheme:
  Leaf ports: P01–P16 (logical)
  Designators: 4x 25G lanes per 100G QSFP28 port (physical)
  Servers: A,B,C,D with SFP28 1–4 (A-1, A-2, A-3, A-4)
  Cables: DAC-1..4 with length tag (DAC-3 2.0m)

Where are these new DAC?

On their way… hopefully sooner than the stated arrival.

[update] Guess What Showed Up?

One of the correct SKU with correct firmware and PCB revision (MBF2H332A-AECOT Rev-C1 2022-02-15), and three of the same SKU without the correct firmware or PCB revision. So, three of them will not work for this project, and in an ideal world the vendor will reship the correct ones quickly.