OODA WIKI - User contributions [en]

Esoteric Maneuverability Score

2025-11-19T18:13:29Z

AdminIsidore:

The Esoteric Maneuverability Score (EMS) quantifies an early modern intellectual's capacity to sustain heterodox pursuits amid geopolitical constraints, computed as a normalized Bayesian posterior integrating mobility, risk exposure, and network resilience. Defined for figures in the [[Republic of Letters]] engaging esoteric traditions (e.g., [[Kabbalah]], [[Paracelsianism]], [[Quakerism]]), EMS measures effective evasion of surveillance while transmitting proscribed knowledge.
=== Definition ===
EMS := \int_{t=0}^{T} P(m_t | e_t, r_t, n_t) , dt / T, where:

$t$ indexes lifespan in years,
$P(m_t | \cdot)$ is the posterior probability of maneuver (unimpeded relocation >50 km) given evidence $e_t$ (archival density),
$r_t$ risk prior (proximity to inquisitorial centers, scaled 0-1),
$n_t$ network gravity (weighted associate count, per [[Six Degrees of Francis Bacon]] model),
$T$ total lifespan.

Priors derive from baseline mobility in confessional states (e.g., 0.3 for Protestant territories, 0.1 Catholic). Update via likelihood ratios from negative evidence (argument from silence in persecution records).
Thresholds: EMS > 0.7 indicates high maneuverability (e.g., itinerant Kabbalists); < 0.4 low (sedentary academics).
=== Calculation Workflow ===

Construct probabilistic geo-temporal timeline per [[Methodological Foundations for Probabilistic Geo-Temporal Timelines]].
Segment into epochs (e.g., pre-/post-Inquisition).
For each $t$: Compute $P(m_t) = \frac{P(e_t | m_t) P(m_t)}{P(e_t)}$, weighting evidence hierarchy (autographs 1.0, inferences 0.4).
Aggregate with risk multiplier: $r_t = 1 - \exp(-\lambda d_t)$, $\lambda$ persecution intensity, $d_t$ distance to threat loci.
Normalize against cohort baseline (e.g., [[Leibniz]] EMS ≈ 0.65).

Implementation: Nodegoat for network ingestion; QGIS for risk overlays; Bayesian update in PyMC.
=== Applications ===

Assess diffusion rates of heterodox texts: Correlate EMS with citation velocity in [[Kabbala Denudata]] transmission.
Comparative analysis: Rank [[Christian Knorr von Rosenroth]] (EMS ≈ 0.55, Sulzbach-anchored) vs. [[Anne Conway]] (EMS ≈ 0.3, Ragley-fixed).
Predictive: Forecast gaps in [[Lost Esoteric Archives]] via low-EMS priors.

=== Example: Franciscus Mercurius van Helmont ===
For [[Franciscus Mercurius van Helmont]] (1614–1698): Timeline yields EMS = 0.72 (60% >0.80 confidence).
Breakdown:

1650s Italy: P(m) = 0.64 (Vatican inference), r=0.85 (Inquisition proximity) → subscore 0.45.
1670s Ragley-Leiden arc: P(m)=0.99 (MS BPL 3603 autograph), r=0.4 (Quaker tolerance) → subscore 0.85.
Aggregate: High due to North Sea commuting despite heresy risks, leveraging networks (Knorr, Leibniz).

Uncertainties: 40% gaps inflate variance (±0.15); refine via untapped [[Medici Archives]].
=== Related Concepts ===

[[Network Gravity in Intellectual History]]: EMS covariate.
[[Argument from Silence in Bayesian Historiography]]: Core prior adjustment.
[[Peripatetic Esotericism]]: Qualitative precursor.

See also: [[Probabilistic Timelines of Early Modern Intellectuals]], [[Van Helmont Geo-Temporal Timeline Dataset]], [[Esoteric Maneuverability Score (Equations and variables)]].

Esoteric Maneuverability Score (Equations and variables)

2025-11-19T18:12:40Z

AdminIsidore: Created page with "== Esoteric Maneuverability Score (Equations and variables) == This article compiles equations and variables from Esoteric Maneuverability Score and linked concepts: Methodological Foundations for Probabilistic Geo-Temporal Timelines, Network Gravity in Intellectual History, Argument from Silence in Bayesian Historiography, Peripatetic Esotericism. Equations are listed with source; variables include derivation/calculation subsections. No new formalism..."

== Esoteric Maneuverability Score (Equations and variables) ==
This article compiles equations and variables from [[Esoteric Maneuverability Score]] and linked concepts: [[Methodological Foundations for Probabilistic Geo-Temporal Timelines]], [[Network Gravity in Intellectual History]], [[Argument from Silence in Bayesian Historiography]], [[Peripatetic Esotericism]]. Equations are listed with source; variables include derivation/calculation subsections. No new formalisms introduced; focus on extraction and explication.

=== Equations ===
From [[Esoteric Maneuverability Score]]:

EMS := \int_{t=0}^{T} P(m_t | e_t, r_t, n_t) , dt / T (normalized Bayesian posterior over lifespan)
r_t = 1 - \exp(-\lambda d_t) (risk multiplier)

From [[Methodological Foundations for Probabilistic Geo-Temporal Timelines]]:

P(H|E) = \frac{P(E|H) P(H)}{P(E)} (Bayes' theorem for location hypothesis)

From [[Network Gravity in Intellectual History]]:

G_{ij} = \frac{m_i m_j}{d_{ij}^2} (gravity between nodes)
P(location_i | associates) \propto \sum G_{ij} (proportional posterior for position inference)

From [[Argument from Silence in Bayesian Historiography]]:

L = \frac{P(E|H)}{P(E|\neg H)} (likelihood ratio; posterior adjustment P(H|E) \downarrow if L << 1 and E absent)

From [[Peripatetic Esotericism]]:

No explicit equations.

=== Variables ===
Comprehensive list: d_{ij}, d_t, e_t, E, G_{ij}, H, L, m_i, m_j, m_t, n_t, P(E), P(E|H), P(E|\neg H), P(H), P(H|E), P(location_i | associates), P(m_t | e_t, r_t, n_t), r_t, t, T, \lambda, \neg H.

==== d_{ij} ====
Inter-node distance in [[Network Gravity in Intellectual History]] (km or affiliation divergence). Derived from gazetteers ([[World Historical Gazetteer]]) or confessional metrics (e.g., 0 for same faith, 1 for adversarial). Calculated via geodesic formulas (Haversine) or categorical scaling; input to G_{ij}.

==== d_t ====
Distance to threat loci at time t in [[Esoteric Maneuverability Score]] (km). Derived from geo-temporal timelines; priors from inquisitorial centers (e.g., Rome=0). Calculated as min Euclidean distance to known persecution sites, overlaid in QGIS.

==== e_t ====
Archival evidence density at t in [[Esoteric Maneuverability Score]] (count/km^2 or normalized 0-1). Derived from source hierarchies (autographs=1.0). Calculated by aggregating weighted evidence within t-window, using Nodegoat ingestion.

==== E ====
Evidence in Bayesian contexts ([[Methodological Foundations for Probabilistic Geo-Temporal Timelines]], [[Argument from Silence in Bayesian Historiography]]). Derived from archival triangulation. Calculated as binary (present/absent) or weighted sum per hierarchy.

==== G_{ij} ====
Gravity between i,j in [[Network Gravity in Intellectual History]]. Derived from masses and d_{ij}. Calculated directly as (m_i m_j)/d_{ij}^2; summed for inference.

==== H ====
Hypothesis (e.g., location) in Bayesian equations. Derived from geo-temporal priors. Calculated contextually (e.g., binary true/false); input to P(H|E).

==== L ====
Likelihood ratio in [[Argument from Silence in Bayesian Historiography]]. Derived from P(E|H)/P(E|\neg H). Calculated numerically; thresholds L<0.1 flag uncertain.

==== m_i, m_j ====
Node masses in [[Network Gravity in Intellectual History]] (publication count, centrality). Derived from prosopographies (e.g., PageRank in EMLO). Calculated via graph algorithms in NetworkX.

==== m_t ====
Maneuver probability at t in [[Esoteric Maneuverability Score]] (>50km relocation). Derived from timeline P(m_t | ...). Calculated via conditional Bayesian update.

==== n_t ====
Network gravity at t in [[Esoteric Maneuverability Score]] (weighted associates). Derived from subgraphs. Calculated as \sum G_{ij} over cohort, per [[Network Gravity in Intellectual History]].

==== P(E) ====
Marginal evidence probability. Derived as P(E|H)P(H) + P(E|\neg H)P(\neg H). Calculated via law of total probability.

==== P(E|H) ====
Likelihood of E given H. Derived from source scope (e.g., 0.7 mention rate). Calculated empirically from cohorts.

==== P(E|\neg H) ====
Likelihood of E given not H. Derived inversely from P(E|H). Calculated similarly, often near 0 for strong silence.

==== P(H) ====
Prior probability of H. Derived from baselines (e.g., 0.3 mobility). Calculated from historical cohorts.

==== P(H|E) ====
Posterior probability. Derived via Bayes' theorem. Calculated numerically in PyMC.

==== P(location_i | associates) ====
Posterior location given associates. Derived proportionally from \sum G_{ij}. Calculated via normalization.

==== P(m_t | e_t, r_t, n_t) ====
Conditional maneuver posterior. Derived via Bayesian network. Calculated by updating priors with e_t, modulated by r_t, n_t.

==== r_t ====
Risk prior at t. Derived from proximity to threats. Calculated as 1 - exp(-\lambda d_t).

==== t ====
Time index (years) in integrals. Derived from lifespan segmentation. Calculated discretely (e.g., annual bins).

==== T ====
Total lifespan (years). Derived from biographical data. Calculated as death - birth year.

==== \lambda ====
Persecution intensity scalar in r_t (events/km). Derived from historical rates (e.g., 0.01 for Inquisition zones). Calculated from archival event densities.

==== \neg H ====
Negation of H. Derived logically. Used in likelihood ratios.

Peripatetic Esotericism

2025-11-19T18:07:51Z

AdminIsidore: Created page with "Peripatetic esotericism denotes wandering transmission of heterodox knowledge in early modern Europe (1550–1750), blending mobility with secrecy in traditions like Kabbalah, Paracelsianism, Neoplatonism. Precursor to EMS, emphasizing evasion of surveillance via itinerancy. === Definition === Esotericism as inner knowledge (gnosis) disseminated peripatetikos (wandering), contra sedentary academies. Key: Incognito travel, priva..."

Peripatetic esotericism denotes wandering transmission of heterodox knowledge in early modern Europe (1550–1750), blending mobility with secrecy in traditions like [[Kabbalah]], [[Paracelsianism]], Neoplatonism. Precursor to [[Esoteric Maneuverability Score|EMS]], emphasizing evasion of surveillance via itinerancy.

=== Definition ===
Esotericism as inner knowledge (gnosis) disseminated peripatetikos (wandering), contra sedentary academies. Key: Incognito travel, private patronage, encoded texts. Metrics: Relocation frequency >2/year, network span >500km.

=== Historical Context ===
Emerged from Late Antiquity (Hermeticism, Gnosticism) via Renaissance translations. Figures: [[Franciscus Mercurius van Helmont]] (Kabbalistic courier), Boehme followers. Drivers: Inquisition, confessional wars; enablers: Republic of Letters edges.

=== Methodological Analysis ===
Reconstruct via [[Methodological Foundations for Probabilistic Geo-Temporal Timelines|probabilistic timelines]]. Infer from textual proxies (e.g., MSS access), [[Network Gravity in Intellectual History|network gravity]]. [[Argument from Silence in Bayesian Historiography|Silence]] validates evasion.

=== Applications ===
Trace diffusion: [[Kabbala Denudata]] from Sulzbach to Cambridge. Comparative: High-EMS peripatetics (0.7+) vs. anchored (e.g., Conway 0.3).

=== Example: Van Helmont ===
North Sea commuting (1670s): Links Quakerism-Kabbalah despite risks; EMS=0.72 reflects peripatetic efficacy.

=== Related Concepts ===
[[Esoteric Maneuverability Score]], [[Lost Esoteric Archives]], [[Western Esotericism in Early Modern Europe]].

Argument from Silence in Bayesian Historiography

2025-11-19T18:07:15Z

AdminIsidore: Created page with "Argument from silence infers hypotheses from absent expected evidence, formalized Bayesially as low posterior when P(E|H) high but E unobserved. In historiography, it counters binary fallacies by quantifying silence strength. === Definition === If P(E|H) ≈1 (evidence expected if true) and E absent, then P(H|E) ↓ via likelihood ratio L = P(E|H)/P(E|¬H) <<1. Silence valid when source comprehensive and unbiased. Priors: Baseline mention rates from cohorts (e.g., 0.7..."

Argument from silence infers hypotheses from absent expected evidence, formalized Bayesially as low posterior when P(E|H) high but E unobserved. In historiography, it counters binary fallacies by quantifying silence strength.

=== Definition ===
If P(E|H) ≈1 (evidence expected if true) and E absent, then P(H|E) ↓ via likelihood ratio L = P(E|H)/P(E|¬H) <<1. Silence valid when source comprehensive and unbiased.

Priors: Baseline mention rates from cohorts (e.g., 0.7 for Quaker arrests in Great Book of Sufferings).

=== Workflow ===

Establish P(E|H): From source scope (e.g., Penn diaries exhaustive for Keithians).
Compute L; update posterior.
Adjust for biases (e.g., destruction multiplier).
Threshold: L<0.1 demotes to uncertain.

=== Applications ===
Debunk myths (e.g., no Eastern van Helmont mentions in Sendivogius parallels → P<0.2). Correlate with [[Esoteric Maneuverability Score|EMS]] for evasion. Historiographic audits: Silence in Hartlib → probable Italy 1650s.

=== Example: Van Helmont ===
Quaker crackdowns 1680s: High P(mention|H) in Sufferings if London-resident; absence → mobility/immunity, P(static London) from 0.7 to 0.4.

=== Related Concepts ===
[[Methodological Foundations for Probabilistic Geo-Temporal Timelines]], [[Network Gravity in Intellectual History]], [[Peripatetic Esotericism]].

Network Gravity in Intellectual History

2025-11-19T18:06:25Z

AdminIsidore: Created page with "Network gravity models intellectual proximity as inverse-square attraction proportional to node masses (influence, output) and inverse to distance (geographic, confessional). In early modern Republic of Letters, it infers locations from associate clusters, treating scholars as masses in socio-epistemic space. === Definition === Gravity G_ij = (m_i m_j) / d_ij^2, where m is node mass (e.g., publication count, correspondence volume), d distance (km or affiliation dive..."

Network gravity models intellectual proximity as inverse-square attraction proportional to node masses (influence, output) and inverse to distance (geographic, confessional). In early modern [[Republic of Letters]], it infers locations from associate clusters, treating scholars as masses in socio-epistemic space.

=== Definition ===
Gravity G_ij = (m_i m_j) / d_ij^2, where m is node mass (e.g., publication count, correspondence volume), d distance (km or affiliation divergence). Bayesian update: P(location_i | associates) ∝ ∑ G_ij.
Priors from baselines ([[Six Degrees of Francis Bacon]] datasets); masses weighted by centrality (PageRank).

=== Workflow ===

Build graph from prosopographies (e.g., CBDB for Chinese parallels, EMLO for Europe).
Segment temporally (decades).
Infer position: Maximize ∑ G for unobserved nodes.
Validate via negative evidence (e.g., silence in high-gravity clusters implies absence).

Implementation: NetworkX/PyMC for inference; Gephi for visualization.

=== Applications ===
Rank diffusion hubs ([[Sulzbach Kabbalistic circle|Sulzbach]] EMS covariate). Comparative: [[Christian Knorr von Rosenroth]] (high local gravity) vs. [[Franciscus Mercurius van Helmont]] (dispersed). Predict archival yields in low-gravity peripheries.

=== Example: Van Helmont ===
Ragley 1670s: High gravity from Conway/More (m=0.8), pulls P=0.95 despite gaps. Sulzbach 1667: Knorr mass elevates posterior from 0.5 to 0.85.

=== Related Concepts ===
[[Esoteric Maneuverability Score]], [[Methodological Foundations for Probabilistic Geo-Temporal Timelines]], [[Socio-Epistemic Networks]].

Methodological Foundations for Probabilistic Geo-Temporal Timelines

2025-11-19T18:05:19Z

AdminIsidore: Created page with "Methodological Foundations for Probabilistic Geo-Temporal Timelines: Probabilistic geo-temporal timelines reconstruct historical agents' movements using Bayesian inference over fragmented evidence, assigning probabilities to locations and periods rather than binary assertions. Applied to early modern intellectuals (1550–1750), this methodology addresses archival gaps via evidence weighting, likelihood ratios, and digital tools. === Epistemological Challenges === Survi..."

Methodological Foundations for Probabilistic Geo-Temporal Timelines: Probabilistic geo-temporal timelines reconstruct historical agents' movements using Bayesian inference over fragmented evidence, assigning probabilities to locations and periods rather than binary assertions. Applied to early modern intellectuals (1550–1750), this methodology addresses archival gaps via evidence weighting, likelihood ratios, and digital tools.

=== Epistemological Challenges ===
Surviving evidence favors institutional records (e.g., university matriculations, court rolls), biasing against itinerants like [[Franciscus Mercurius van Helmont]]. Biases include confessional disparities (Protestant vs. Catholic archives), war destruction (Thirty Years' War), and esoteric secrecy. Gaps average 1–5 years for comparable figures ([[Leibniz itinerary|Leibniz]], [[Spinoza movements|Spinoza]]).

=== Evidence Hierarchy ===
Weights (0.0–1.0):

Autograph/dated letter: 1.0 (irrefutable presence).
Contemporary witness: 0.9 (e.g., diary entry).
Legal/inquisitorial record: 0.75 (movement constraints).
Printer gravity: 0.8 (typesetting oversight implies location).
Network gravity: 0.6 (associate proximity).
Textual inference: 0.4 (MSS access).

Justifications per [[Van Helmont Geo-Temporal Timeline Dataset]] examples.

=== Bayesian Workflow ===
P(H|E) = [P(E|H) P(H)] / P(E), where H is location hypothesis, E evidence.

Set priors from cohort baselines (e.g., 0.3 mobility in Protestant zones).
Compute likelihood ratios, incorporating [[Argument from Silence in Bayesian Historiography|argument from silence]] (high P(E|H) absent → low posterior).
Thresholds: >0.75 assert; 0.5–0.75 plausible; <0.5 uncertain.
Handle dependencies via conditional probabilities.

=== Geolocation and Gap Management ===
Use gazetteers ([[World Historical Gazetteer]]) for toponyms to coordinates. Gaps via maximum entropy (uniform priors absent evidence); interpolation rules: last/next known with transit priors.

=== Digital Tools ===
Recogito for toponym tagging; Nodegoat for networks; QGIS/Kepler.js for visualizations (fuzzy polygons for uncertainty). TEI encoding: <location cert="medium" certainty="0.65">Rome</location>.

=== Applications ===
Reconstruct [[Peripatetic Esotericism|peripatetic esoteric]] paths; correlate with [[Esoteric Maneuverability Score|EMS]]. Case: Van Helmont's Leiden 1676 (P=0.99) disrupts static models.

=== Related Concepts ===
[[Network Gravity in Intellectual History]], [[Argument from Silence in Bayesian Historiography]], [[Peripatetic Esotericism]], [[Lost Esoteric Archives]].

Esoteric Maneuverability Score

2025-11-19T18:00:21Z

AdminIsidore: Created page with "The Esoteric Maneuverability Score (EMS) quantifies an early modern intellectual's capacity to sustain heterodox pursuits amid geopolitical constraints, computed as a normalized Bayesian posterior integrating mobility, risk exposure, and network resilience. Defined for figures in the Republic of Letters engaging esoteric traditions (e.g., Kabbalah, Paracelsianism, Quakerism), EMS measures effective evasion of surveillance while transmitting proscribed kno..."

Server Room (Flamenco)

2025-11-04T18:08:40Z

AdminIsidore: Created page with "The '''Server Room''' is the single most critical component of Project: Flamenco. It is not viewed as a simple utility, but as the "engine" or "artificial sun" of the entire system. Its primary function within the project is not computation, but the generation of '''waste heat''', which is the project's most valuable internal resource. All other systems are designed to capture and leverage 100% of this thermal output. The heat is captured in two forms: 1. '''Hot..."

The '''Server Room''' is the single most critical component of [[Project: Flamenco]]. It is not viewed as a simple utility, but as the "engine" or "artificial sun" of the entire system.

Its primary function within the project is not computation, but the generation of '''waste heat''', which is the project's most valuable internal resource. All other systems are designed to capture and leverage 100% of this thermal output.

The heat is captured in two forms:

1. '''Hot Air Exhaust:''' The ~90-110°F air exhausted from the servers is ducted directly into the [[Waste Heat Food Dehydrator (Isidore)|Waste Heat Food Dehydrator]].
2. '''Hot Liquid Coolant:''' A liquid-cooling loop captures heat directly from the CPUs/GPUs. This hot coolant (e.t., 120-140°F) is the "fuel" for the [[Stirling Engine Array (Isidore)|Stirling Engine Array]] and provides heat for the [[Aquaponics System (Maria)|aquaponics system]] via a [[Liquid-to-Liquid Heat Exchanger (Isidore)|heat exchanger]].

Integrated Pest Management (Maria)

2025-11-04T18:07:53Z

AdminIsidore: Created page with "'''Integrated Pest Management (IPM)''' is the "dynamic" or "living" pest control strategy for Project: Maria. Due to the closed-loop aquaponics system (which is highly sensitive to toxins) and the server room (where airborne chemicals are a risk), traditional chemical pesticides are forbidden. Instead, IPM focuses on creating a stable, balanced ecosystem by using '''biological controls.''' === Key Strategies..."

'''Integrated Pest Management (IPM)''' is the "dynamic" or "living" pest control strategy for [[Project: Maria]].

Due to the closed-loop [[Aquaponics System (Maria)|aquaponics system]] (which is highly sensitive to toxins) and the [[Server Room (Flamenco)|server room]] (where airborne chemicals are a risk), traditional chemical pesticides are forbidden.

Instead, IPM focuses on creating a stable, balanced ecosystem by using '''biological controls.'''

=== Key Strategies ===
* '''Beneficial Insects:''' A permanent "immune system" of beneficial insects will be introduced and maintained in the [[Greenhouse & Shadehouse (Maria)|greenhouse]] and [[Biowall Filtration System (Maria)|biowall]].
* **Predatory Mites** (e.g., ''Phytoseiulus persimilis''): To hunt and eat "bad" spider mites.
* **Ladybugs:** To control aphids.
* '''Microbial Controls:'''
* **Beneficial Nematodes** (e.g., ''Steinernema feltiae''): Microscopic organisms added to the water/soil to hunt and kill fungus gnat larvae.

Loofah Filter Cultivation (Maria)

2025-11-04T18:07:39Z

AdminIsidore: Created page with "'''Loofah (Luffa) Filter Cultivation''' is a key component of Project: Maria's "internalized inputs" principle. The Loofah gourd is a vining plant that is grown in the greenhouse. When harvested and dried, the gourd's fibrous interior forms a tough, porous, 3D sponge. === System Function === 1. '''Filter Production:''' These dried loofah matrices are cut into flat sheets. 2. '''Dehydrator Use:''' The sheets are used as the food..."

'''Loofah (Luffa) Filter Cultivation''' is a key component of [[Project: Maria]]'s "internalized inputs" principle.

The Loofah gourd is a vining plant that is grown in the [[Greenhouse & Shadehouse (Maria)|greenhouse]]. When harvested and dried, the gourd's fibrous interior forms a tough, porous, 3D sponge.

=== System Function ===
1. '''Filter Production:''' These dried loofah matrices are cut into flat sheets.
2. '''Dehydrator Use:''' The sheets are used as the food-safe, "polishing" filter for the [[Waste Heat Food Dehydrator (Isidore)|Waste Heat Food Dehydrator]]. This filter traps any dust from the server room air.
3. '''Closed-Loop Recycling:''' When the filter is clogged, it is not thrown away. It is added to the facility's compost or worm bins, where it (and the dust it trapped) breaks down. This compost is then used to fertilize the aquaponics system, which grows more loofah.

Waste Heat Food Dehydrator (Isidore)

2025-11-04T18:07:20Z

AdminIsidore: Created page with "The '''Waste Heat Food Dehydrator''' is a large, insulated cabinet designed to dehydrate food using "free" energy from the Server Room. === System Design === * '''Heat Source:''' The hot, dry air (90-110°F) exhausted from the server racks is ducted directly into the dehydrator. * '''Food Safety Filter:''' Before the air touches the food, it must pass through a final "polishing" filter to remove any server room dust or particulates. This filte..."

The '''Waste Heat Food Dehydrator''' is a large, insulated cabinet designed to dehydrate food using "free" energy from the [[Server Room (Flamenco)|Server Room]].

=== System Design ===
* '''Heat Source:''' The hot, dry air (90-110°F) exhausted from the server racks is ducted directly into the dehydrator.
* '''Food Safety Filter:''' Before the air touches the food, it must pass through a final "polishing" filter to remove any server room dust or particulates. This filter is designed to be a replaceable, food-safe-material filter.
* '''Internal Filter Source:''' To eliminate external dependencies, this filter is made from [[Loofah Filter Cultivation (Maria)|on-site cultivated loofah]].
* '''Exhaust:''' The resulting warm, *moist* air from the dehydrator is then vented into the [[Greenhouse & Shadehouse (Maria)|greenhouse]] to passively raise humidity.

Power Generation & Storage (Isidore)

2025-11-04T18:07:09Z

AdminIsidore: Created page with "This article describes the overall "electrical grid" for Project: Flamenco, which is designed for 24/7 redundancy by "stacking" multiple generation sources. === Generation Sources === 1. '''Solar Panel Array (Primary):''' Provides the main bulk of electrical power during the day. 2. '''Stirling Engine Array (Secondary/Night):''' The hybrid engines provide two forms of power: * **Mechanical:**..."

This article describes the overall "electrical grid" for [[Project: Flamenco]], which is designed for 24/7 redundancy by "stacking" multiple generation sources.

=== Generation Sources ===
1. '''[[Solar Panel Array (Isidore)|Solar Panel Array]] (Primary):''' Provides the main bulk of electrical power during the day.
2. '''[[Stirling Engine Array (Isidore)|Stirling Engine Array]] (Secondary/Night):''' The hybrid engines provide two forms of power:
* **Mechanical:** Drives pumps directly during the day.
* **Electrical:** The alternator provides a constant "trickle charge" to the batteries 24/7, especially at night when the solar panels are offline.

=== Storage ===
* '''Battery Bank:''' A central 12V or 24V battery bank (similar to an RV or solar setup) stores energy from all sources.
* '''Function:''' This bank "decouples" generation from use. It provides stable, on-demand power to critical DC loads (like pumps and LEDs) and runs inverters for any AC loads, regardless of whether the sun is shining or the servers are at full load.

Centrifugal Clutch (Isidore)

2025-11-04T18:06:58Z

AdminIsidore: Created page with "The '''Centrifugal Clutch''' is the key mechanical component that makes the Stirling Engine's mechanical drive possible. === The Problem (Low Torque) === The LTD Stirling engine produces very low torque (twisting force), especially at startup. It does not have the "grunt" to start a water pump from a dead stop and would stall. === The Solution (Clutch) === The centrifugal clutch (similar to a go-ka..."

The '''Centrifugal Clutch''' is the key mechanical component that makes the [[Stirling Engine Array (Isidore)|Stirling Engine's]] mechanical drive possible.

=== The Problem (Low Torque) ===
The [[Stirling Engine Array (Isidore)|LTD Stirling engine]] produces very low torque (twisting force), especially at startup. It does not have the "grunt" to start a water pump from a dead stop and would stall.

=== The Solution (Clutch) ===
The centrifugal clutch (similar to a go-kart's) "disconnects" the engine from the pump at low speeds.
1. The Stirling engine starts up under "no load."
2. It uses the server heat to get up to its optimal, high speed.
3. Once it reaches a pre-set RPM, the clutch's internal weights are thrown outward, engaging the clutch drum.
4. Only then is the engine's full, high-speed power transferred to the gearbox and pump.

This allows a low-torque engine to power a high-torque mechanical load, all without electronics.

Stirling Engine Array (Isidore)

2025-11-04T18:06:43Z

AdminIsidore: Created page with "The '''Stirling Engine Array''' is a key power-generation component of Project: Isidore. It is a "Low-Temperature Differential" (LTD) heat engine. Its function is to convert the waste heat from the server room directly into mechanical energy, which is then converted into electrical energy. === System Design === * '''Hot Side:''' Heated by the hot coolant loop from the server room. * '''Cold Side:''' Cooled by the stable, cold water from t..."

The '''Stirling Engine Array''' is a key power-generation component of [[Project: Isidore]]. It is a "Low-Temperature Differential" (LTD) heat engine.

Its function is to convert the waste heat from the server room directly into mechanical energy, which is then converted into electrical energy.

=== System Design ===
* '''Hot Side:''' Heated by the hot coolant loop from the [[Server Room (Flamenco)|server room]].
* '''Cold Side:''' Cooled by the stable, cold water from the [[Central Thermal Battery (Isidore)|cistern]].
* '''Output:''' The continuous temperature difference drives the engine's pistons 24/7.

=== Hybrid Output ===
The engine has a hybrid "dual-output" design:
1. '''Mechanical Drive:''' A [[Centrifugal Clutch (Isidore)|centrifugal clutch]] and gearbox use the engine's mechanical rotation to directly drive water pumps.
2. '''Electrical Drive:''' A small alternator is attached to the same shaft. When the engine is "idling" (too slow to engage the clutch), it still provides a "trickle charge" to the [[Power Generation & Storage (Isidore)|battery bank]], providing power for critical systems (like biowall LEDs) at night.

Liquid-to-Liquid Heat Exchanger (Isidore)

2025-11-04T18:06:35Z

AdminIsidore: Created page with "A '''Liquid-to-Liquid Heat Exchanger''' is a device that allows heat to be transferred between two liquid loops without the liquids ever mixing. In Project: Flamenco, this is typically a compact "brazed plate" exchanger. This component is critical for isolating "dirty" or "technical" water loops from "clean" or "biological" ones. === Key Applications === * '''Stirling Engine (Hot Side):''' Transfers heat from the "technical" server coolant loop to the "clean" water..."

A '''Liquid-to-Liquid Heat Exchanger''' is a device that allows heat to be transferred between two liquid loops without the liquids ever mixing. In [[Project: Flamenco]], this is typically a compact "brazed plate" exchanger.

This component is critical for isolating "dirty" or "technical" water loops from "clean" or "biological" ones.

=== Key Applications ===
* '''Stirling Engine (Hot Side):''' Transfers heat from the "technical" server coolant loop to the "clean" water loop that heats the [[Stirling Engine Array (Isidore)|Stirling engine]].
* '''Aquaponics Cooling:''' Transfers heat from the "biological" [[Aquaponics System (Maria)|aquaponics system]] water into the "clean" [[Central Thermal Battery (Isidore)|cistern]] water loop.
* '''Aquaponics Heating:''' Transfers heat from the "technical" server coolant loop into the "biological" [[Aquaponics System (Maria)|aquaponics system]] water.

*(Note: The server coolant loop is considered "technical" or "dirty" because it contains biocides and anti-corrosion additives that are toxic to fish and plants.)*

Central Thermal Battery (Isidore)

2025-11-04T18:06:11Z

AdminIsidore: Created page with "The '''Central Thermal Battery''' (also known as the "cistern") is the single most important "anchor" in the entire Project: Flamenco system. It is a large, subterranean water tank, buried 6-10 feet underground to maintain a stable, year-round temperature (approx. 64°F). This massive, stable water volume serves as the facility's "thermal anchor" or "battery." === System Functions === 1. '''Water Supply:''' It is the primary reservoir for the facility, fed by th..."

The '''Central Thermal Battery''' (also known as the "cistern") is the single most important "anchor" in the entire [[Project: Flamenco]] system.

It is a large, subterranean water tank, buried 6-10 feet underground to maintain a stable, year-round temperature (approx. 64°F).

This massive, stable water volume serves as the facility's "thermal anchor" or "battery."

=== System Functions ===

1. '''Water Supply:''' It is the primary reservoir for the facility, fed by the [[Rainwater Harvesting System (Isidore)|Rainwater Harvesting System]].
2. '''Cold Sink:''' It is the "cold side" for the [[Stirling Engine Array (Isidore)|Stirling Engine Array]]. The temperature differential between the hot server coolant and the cold cistern water is what drives the engines.
3. '''Summer Cooling:''' It provides "free" cooling for the [[Aquaponics System (Maria)|aquaponics system]] via a [[Liquid-to-Liquid Heat Exchanger (Isidore)|heat exchanger]].
4. '''Heat Sink:''' It is the final "dump" for any excess server heat that is not used by the other systems, ensuring the [[Server Room (Flamenco)|server room]] can be cooled under any conditions.

Heat Recovery System (Isidore)

2025-11-04T18:06:00Z

AdminIsidore: Created page with "The '''Heat Recovery System''' is the "circulatory system" of Project: Isidore. It is the complete network of ducts, pipes, and exchangers responsible for capturing 100% of the waste heat from the Server Room and distributing it to other systems. It consists of two main loops: 1. '''Air Loop (Gaseous):''' * '''Source:''' Hot server fan exhaust. * '''Use:''' Ducted directly to the Waste Heat Food Dehydrator (Isidore)|Waste Heat..."

The '''Heat Recovery System''' is the "circulatory system" of [[Project: Isidore]]. It is the complete network of ducts, pipes, and exchangers responsible for capturing 100% of the waste heat from the [[Server Room (Flamenco)|Server Room]] and distributing it to other systems.

It consists of two main loops:

1. '''Air Loop (Gaseous):'''
* '''Source:''' Hot server fan exhaust.
* '''Use:''' Ducted directly to the [[Waste Heat Food Dehydrator (Isidore)|Waste Heat Food Dehydrator]].

2. '''Liquid Loop (Hydronic):'''
* '''Source:''' Hot liquid coolant from the server water-blocks.
* '''Use:''' This coolant is pumped to a [[Liquid-to-Liquid Heat Exchanger (Isidore)|heat exchanger]], where its thermal energy is transferred to:
* The "hot side" of the [[Stirling Engine Array (Isidore)|Stirling Engine Array]].
* The [[Aquaponics System (Maria)|aquaponics system]] (for winter heating).
* The [[Central Thermal Battery (Isidore)|Central Thermal Battery]] (for long-term storage).

Biowall Filtration System (Maria)

2025-11-04T18:05:52Z

AdminIsidore: Created page with "The '''Biowall Filtration System''' is the primary, "living" air filter for the entire warehouse. It is nicknamed "The Mangrove" because it functions as a living, breathing ecosystem that cleans the air and water. === Design === The biowall is a large, vertical, hydroponic "living wall" built along the interior face of the warehouse. * '''Active Filtration:''' It is an "active" biowall, meaning fans at the bottom vents pull the entire warehouse air volume ''through'' th..."

The '''Biowall Filtration System''' is the primary, "living" air filter for the entire warehouse. It is nicknamed "The Mangrove" because it functions as a living, breathing ecosystem that cleans the air and water.

=== Design ===
The biowall is a large, vertical, hydroponic "living wall" built along the interior face of the warehouse.
* '''Active Filtration:''' It is an "active" biowall, meaning fans at the bottom vents pull the entire warehouse air volume ''through'' the plants' exposed root mats.
* '''Plant Selection:''' It uses hardy, heat-loving plants like Pothos, Philodendron, Spider Plants, and Peace Lilies, which are known for their dense root structures and air-purifying abilities.

=== System Function ===
1. '''Air Filtration:''' The complex, moist root mat acts as a massive physical filter, trapping dust and particulates. A symbiotic microbe colony on the roots metabolizes airborne VOCs (volatile organic compounds).
2. '''Water Filtration:''' The wall is fed with nutrient-rich water from the [[Aquaponics System (Maria)|aquaponics system]]. The plants consume the nitrates, "phytoremediating" the water before it is returned to the fish.
3. '''Dynamic Maintenance:''' The system is managed using [[Integrated Pest Management (Maria)|biological pest control]] (e.g., predatory mites) to create a self-regulating ecosystem.
4. '''Lighting:''' It is lit passively by the [[North-Facing Roof Monitor (Isidore)|roof monitors]] and supplemented by LEDs powered by the [[Stirling Engine Array (Isidore)|Stirling engines]] at night.

North-Facing Roof Monitor (Isidore)

2025-11-04T18:05:35Z

AdminIsidore: Created page with "The '''North-Facing Roof Monitor''' is an architectural feature, also known as a "clerestory window," designed to provide passive lighting to the building's interior. Instead of a simple skylight (which would dump massive heat into the building), the roof monitor is a raised "box" on the roof. * The '''South-facing side''' is opaque and covered with solar panels to block the high, hot summer sun. * The '''North-facing side''' is all glass..."

The '''North-Facing Roof Monitor''' is an architectural feature, also known as a "clerestory window," designed to provide passive lighting to the building's interior.

Instead of a simple skylight (which would dump massive heat into the building), the roof monitor is a raised "box" on the roof.
* The '''South-facing side''' is opaque and covered with [[Solar Panel Array (Isidore)|solar panels]] to block the high, hot summer sun.
* The '''North-facing side''' is all glass.

This design floods the interior [[Biowall Filtration System (Maria)|biowall]] with bright, diffuse, indirect sunlight all day long. This provides the necessary light for photosynthesis while minimizing any associated heat gain, thereby reducing the electrical load required for supplemental LED lighting.

Rainwater Harvesting System (Isidore)

2025-11-04T18:05:21Z

AdminIsidore: Created page with "The '''Rainwater Harvesting System''' is the "Blue Roof" component of the "Blue-Green-Solar Roof." It is designed to capture 100% of the rainwater that falls on the property. The system consists of a network of gutters and pipes that collect the rainwater after it has been pre-filtered by the Green Roof. This clean water is then channeled into the Central Thermal Battery, a massive subterranean cistern. This..."

The '''Rainwater Harvesting System''' is the "Blue Roof" component of the "Blue-Green-Solar Roof." It is designed to capture 100% of the rainwater that falls on the property.

The system consists of a network of gutters and pipes that collect the rainwater after it has been pre-filtered by the [[Green Roof (Maria)|Green Roof]]. This clean water is then channeled into the [[Central Thermal Battery (Isidore)|Central Thermal Battery]], a massive subterranean cistern.

This system, along with atmospheric water capture, is one of the two primary strategies for eliminating the external dependency on a municipal water source.

Green Roof (Maria)

2025-11-04T18:05:12Z

AdminIsidore: Created page with "The '''Green Roof''' is a "living" layer of shallow-rooted, drought-tolerant plants (like succulents and sedums) covering the warehouse roof. It is part of the "Blue-Green-Solar Roof" and serves two critical functions for Project: Flamenco: 1. '''Thermal Insulation:''' The layer of soil and plants acts as a massive insulating blanket, absorbing solar radiation and preventing the sun from heating the warehouse roof. This drastically reduces the building's cooling l..."

The '''Green Roof''' is a "living" layer of shallow-rooted, drought-tolerant plants (like succulents and sedums) covering the warehouse roof.

It is part of the "Blue-Green-Solar Roof" and serves two critical functions for [[Project: Flamenco]]:

1. '''Thermal Insulation:''' The layer of soil and plants acts as a massive insulating blanket, absorbing solar radiation and preventing the sun from heating the warehouse roof. This drastically reduces the building's cooling load.
2. '''Water Pre-filtration:''' The green roof acts as a natural, "living" filter. As rainwater falls, the plants and soil trap dust, pollen, and other debris. This "pre-cleaned" water is then collected by the [[Rainwater Harvesting System (Isidore)|Rainwater Harvesting System]] and sent to the [[Central Thermal Battery (Isidore)|cistern]].

Solar Panel Array (Isidore)

2025-11-04T18:04:54Z

AdminIsidore: Created page with "The '''Solar Panel Array''' is the primary electrical generation system for Project: Flamenco. It is a key component of the "Blue-Green-Solar Roof" concept. The panels are mounted on the warehouse roof, but are integrated with the other roof systems to create a powerful synergy: 1. The panels are mounted *above* the Green Roof. 2. The "evapotranspiration" (sweating) from the green roof's plants creates a micro-climate of cooler air directly..."

The '''Solar Panel Array''' is the primary electrical generation system for [[Project: Flamenco]].

It is a key component of the "Blue-Green-Solar Roof" concept. The panels are mounted on the warehouse roof, but are integrated with the other roof systems to create a powerful synergy:

1. The panels are mounted *above* the [[Green Roof (Maria)|Green Roof]].
2. The "evapotranspiration" (sweating) from the green roof's plants creates a micro-climate of cooler air directly under the panels.
3. This cooling effect mitigates the efficiency loss that solar panels typically suffer from in extreme heat, boosting their overall output.

The panels also serve a structural role, forming the opaque, South-facing side of the [[North-Facing Roof Monitor (Isidore)|North-Facing Roof Monitors]].

Aquaponics System (Maria)

2025-11-04T18:04:28Z

AdminIsidore: Created page with "The '''Aquaponics System''' is the primary food-production and nutrient-cycling system for Project: Flamenco. It combines aquaculture (raising fish) with hydroponics (growing plants in water). === System Role === 1. '''Food Production:''' Grows both fish and a wide variety of plants and herbs. 2. '''Nutrient Source:''' The nutrient-rich water from the fish tanks is the primary "fertilizer" for the biowall and the aquaponic "ri..."

The '''Aquaponics System''' is the primary food-production and nutrient-cycling system for [[Project: Flamenco]]. It combines aquaculture (raising fish) with hydroponics (growing plants in water).

=== System Role ===
1. '''Food Production:''' Grows both fish and a wide variety of plants and herbs.
2. '''Nutrient Source:''' The nutrient-rich water from the fish tanks is the primary "fertilizer" for the [[Biowall Filtration System (Maria)|biowall]] and the aquaponic "rivers."
3. '''Water Filtration:''' The plants and biowall, in turn, filter the water, which is then returned clean to the fish.

=== Key Components ===
* '''Main Tanks:''' Located in the [[Greenhouse & Shadehouse (Maria)|greenhouses]], housing the main fish population (e.g., Tilapia).
* '''Aquaponic "Rivers":''' Long troughs located in the shadehouse "moat" for growing vining plants, herbs, and lettuces.
* '''Thermal Regulation:''' The system is heated in winter by the [[Heat Recovery System (Isidore)|Heat Recovery System]] and cooled in summer via a loop to the [[Central Thermal Battery (Isidore)|Central Thermal Battery]].

Greenhouse & Shadehouse (Maria)

2025-11-04T18:04:13Z

AdminIsidore: Created page with "The '''Greenhouse & Shadehouse''' component is a hybrid "zoning" strategy for the building envelope, designed to work ''with'' the Arizona climate. 1. '''Shadehouse "Moat":''' * '''Location:''' Runs along the long East/West-facing walls. * '''Function:''' Acts as a "thermal shield." A 5-foot-wide space covered in 50-70% shade cloth, it blocks the brutal, low-angle E/W sun from ever hitting the main warehouse wall. * '''Use:''' This cooler, shaded area house..."

The '''Greenhouse & Shadehouse''' component is a hybrid "zoning" strategy for the building envelope, designed to work ''with'' the Arizona climate.

1. '''Shadehouse "Moat":'''
* '''Location:''' Runs along the long East/West-facing walls.
* '''Function:''' Acts as a "thermal shield." A 5-foot-wide space covered in 50-70% shade cloth, it blocks the brutal, low-angle E/W sun from ever hitting the main warehouse wall.
* '''Use:''' This cooler, shaded area houses the long "rivers" of the [[Aquaponics System (Maria)|aquaponics system]] (e.g., for lettuce and herbs).

2. '''Greenhouse Nodes:'''
* '''Location:''' Located on the shorter, North/South-facing ends of the building.
* '''Function:''' A fully enclosed, controlled environment. The North-facing greenhouse gets bright, indirect light, while the South-facing one uses a calculated overhang to block summer sun but allow winter sun (passive heating).
* '''Use:''' Houses the main [[Aquaponics System (Maria)|fish tanks]], seedling nurseries, and plants that require higher heat and humidity.

AI Orchestration (Flamenco)

2025-11-04T18:03:51Z

AdminIsidore: Created page with "The '''AI Orchestration''' layer is the "central nervous system" of Project: Flamenco. It is a planned system, to be built on the GeminiCLI tool. Its function is to monitor, learn, and eventually help manage the dynamic, self-regulating systems of the warehouse. It will integrate sensor data from Project: Isidore (e.g., temperatures, power levels, pump speeds) and Project: Maria (e.g., nutrient levels, humidity, plant growth) to crea..."

The '''AI Orchestration''' layer is the "central nervous system" of [[Project: Flamenco]]. It is a planned system, to be built on the [[GeminiCLI (Flamenco)|GeminiCLI]] tool.

Its function is to monitor, learn, and eventually help manage the dynamic, self-regulating systems of the warehouse. It will integrate sensor data from [[Project: Isidore]] (e.g., temperatures, power levels, pump speeds) and [[Project: Maria]] (e.g., nutrient levels, humidity, plant growth) to create a holistic model of the building's "health."

This system will manage specialized AI sub-models responsible for specific tasks.

Industrial ecology

2025-11-04T18:03:20Z

AdminIsidore: Created page with "'''Industrial Ecology''' is the core philosophical and engineering principle behind Project: Flamenco. In the context of this project, it is the study of the facility as a "man-made ecosystem." The central tenet is that there is no such thing as "waste," only "misplaced resources." The entire design of Project: Flamenco is an exercise in industrial ecology, where the "waste" output of one system becomes the "food" input for another. === Key Loops === * '''Heat Wa..."

'''Industrial Ecology''' is the core philosophical and engineering principle behind [[Project: Flamenco]].

In the context of this project, it is the study of the facility as a "man-made ecosystem." The central tenet is that there is no such thing as "waste," only "misplaced resources."

The entire design of Project: Flamenco is an exercise in industrial ecology, where the "waste" output of one system becomes the "food" input for another.

=== Key Loops ===

* '''Heat Waste:''' Server room heat $\rightarrow$ powers [[Stirling Engine Array (Isidore)|Stirling engines]] and [[Waste Heat Food Dehydrator (Isidore)|food dehydrator]].
* '''Water Waste:''' Fish waste (ammonia) $\rightarrow$ feeds [[Biowall Filtration System (Maria)|biowall]] and aquaponic plants.
* '''Air Waste:''' Dusty warehouse air $\rightarrow$ is "food" for the [[Biowall Filtration System (Maria)|biowall]], which strips it of particulates.
* '''Material Waste:''' A clogged [[Loofah Filter Cultivation (Maria)|Loofah filter]] $\rightarrow$ is composted to create fertilizer to grow more loofahs.

GeminiCLI (Flamenco)

2025-11-04T18:02:40Z

AdminIsidore: Created page with "The '''GeminiCLI (Flamenco)''' is the specific software tool chosen to serve as the foundation for the AI Orchestration layer of Project: Flamenco. A locally-hosted instance of the Gemini model will be accessed via its command-line interface. This wiki, along with its references, build logs, and (eventually) real-time sensor data, will be used as the primary fine-tuning dataset. The goal is for the GeminiCLI to learn the complex, dyn..."

The '''GeminiCLI (Flamenco)''' is the specific software tool chosen to serve as the foundation for the [[AI Orchestration (Flamenco)|AI Orchestration]] layer of [[Project: Flamenco]].

A locally-hosted instance of the Gemini model will be accessed via its command-line interface. This wiki, along with its references, build logs, and (eventually) real-time sensor data, will be used as the primary fine-tuning dataset.

The goal is for the GeminiCLI to learn the complex, dynamic relationships between the project's sub-systems, such as:
* Correlating server load with power generation from the [[Stirling Engine Array (Isidore)|Stirling Engine Array]].
* Monitoring nutrient levels in the [[Aquaponics System (Maria)|aquaponics system]] and growth rates in the [[Biowall Filtration System (Maria)|biowall]].
* Optimizing resource flows, such as diverting heat from the [[Central Thermal Battery (Isidore)|cistern]] to the aquaponics tanks in winter.

This tool will serve as the "central mind" that helps manage and orchestrate the specialized AI models integrated into other parts of the warehouse.

OODA WIKI:Maria

2025-11-04T18:02:05Z

AdminIsidore: Created page with "{{Main|Project: Flamenco}} '''Project: Maria''' is the primary sub-project of Project: Flamenco, named for Santa Maria de la Cabeza. It encompasses all organic, biological, and "living" systems. The core function of Project: Maria is to serve as the "lungs, kidneys, and stomach" of the facility. It is responsible for air and water filtration, food production, and internalizing resource loops. It is the "organic" counterpart to the "mechanical" systems of Project:..."

{{Main|Project: Flamenco}}

'''Project: Maria''' is the primary sub-project of [[Project: Flamenco]], named for Santa Maria de la Cabeza. It encompasses all organic, biological, and "living" systems.

The core function of Project: Maria is to serve as the "lungs, kidneys, and stomach" of the facility. It is responsible for air and water filtration, food production, and internalizing resource loops. It is the "organic" counterpart to the "mechanical" systems of [[Project: Isidore]].

=== Core Components ===

* '''Filtration Systems:'''
* [[Biowall Filtration System (Maria)|Biowall Filtration System]]: The primary, "living" air filter for the entire warehouse.
* [[Green Roof (Maria)|Green Roof]]: Provides thermal insulation and pre-filters rainwater.
* [[Loofah Filter Cultivation (Maria)|Loofah Filter Cultivation]]: An on-site, cultivated source for the food-safe filter in the [[Waste Heat Food Dehydrator (Isidore)|dehydrator]].

* '''Food & Water Systems:'''
* [[Aquaponics System (Maria)|Aquaponics System]]: The closed-loop fish and plant system that provides food and nutrient-rich water for the biowall.
* [[Greenhouse & Shadehouse (Maria)|Greenhouse & Shadehouse]]: The "zoned" building envelope for agriculture and thermal shielding.

* '''Ecological Systems:'''
* [[Integrated Pest Management (Maria)|Biological Pest Control]]: A dynamic system using beneficial insects rather than chemicals to manage pests.

OODA WIKI:Isidore

2025-11-04T18:01:52Z

AdminIsidore: Created page with "{{Main|Project: Flamenco}} '''Project: Isidore''' is the primary sub-project of Project: Flamenco, named for St. Isidore the Farmer. It encompasses all mechanical, electrical, structural, and "hard tech" systems. The core function of Project: Isidore is to provide the "engine" for the facility—capturing, generating, storing, and converting energy. It is the "mechanical" counterpart to the "organic" systems of Project: Maria. === Core Components === * '''Ene..."

{{Main|Project: Flamenco}}

'''Project: Isidore''' is the primary sub-project of [[Project: Flamenco]], named for St. Isidore the Farmer. It encompasses all mechanical, electrical, structural, and "hard tech" systems.

The core function of Project: Isidore is to provide the "engine" for the facility—capturing, generating, storing, and converting energy. It is the "mechanical" counterpart to the "organic" systems of [[Project: Maria]].

=== Core Components ===

* '''Energy Generation & Capture:'''
* [[Solar Panel Array (Isidore)|Solar Panel Array]]: The primary electrical source.
* [[Stirling Engine Array (Isidore)|Stirling Engine Array]]: A hybrid electrical/mechanical system run on waste heat.
* [[Heat Recovery System (Isidore)|Heat Recovery System]]: The overall system for capturing server waste heat.

* '''Energy Storage & Management:'''
* [[Power Generation & Storage (Isidore)|Power Generation & Storage]]: The battery bank and control system.
* [[Central Thermal Battery (Isidore)|Central Thermal Battery]]: The subterranean rainwater cistern that functions as the facility's "thermal anchor" or "cold sink."

* '''Mechanical Systems:'''
* [[Server Room (Flamenco)|Server Room]]: The primary heat source for the entire project.
* [[Liquid-to-Liquid Heat Exchanger (Isidore)|Liquid-to-Liquid Heat Exchanger]]: Used to transfer heat between the server coolant loop and other systems.
* [[Centrifugal Clutch (Isidore)|Centrifugal Clutch & Gearbox]]: Mechanically links the Stirling engines to water pumps, solving the low-torque problem.
* [[Rainwater Harvesting System (Isidore)|Rainwater Harvesting System]]: The "blue roof" system that captures and channels water to the cistern.

* '''Structural & Utility:'''
* [[North-Facing Roof Monitor (Isidore)|North-Facing Roof Monitor]]: The clerestory window structure that provides passive, indirect light to the [[Biowall Filtration System (Maria)|biowall]].
* [[Waste Heat Food Dehydrator (Isidore)|Waste Heat Food Dehydrator]]: A food-safe dehydrator running on "free" server air exhaust.

OODA WIKI:Flamenco

2025-11-04T18:01:18Z

AdminIsidore: Created page with "'''Project: Flamenco''' is a whole-systems design for a self-sufficient, closed-loop warehouse and server facility. The project's core principle is the application of Industrial ecology, where every waste stream (such as heat, water, or CO2) is captured and used as a resource for another component of the system. The project is designed as an integrated "living" system, combining mechanical, organic, and artificial intelligence components to achieve systemic resilien..."

'''Project: Flamenco''' is a whole-systems design for a self-sufficient, closed-loop warehouse and server facility. The project's core principle is the application of [[Industrial ecology]], where every waste stream (such as heat, water, or CO2) is captured and used as a resource for another component of the system.

The project is designed as an integrated "living" system, combining mechanical, organic, and artificial intelligence components to achieve systemic resilience and eliminate external dependencies. The entire system is designed to function as a unified, self-regulating entity, with the ultimate goal of being orchestrated by a fine-tuned [[GeminiCLI (Flamenco)|AI orchestrator]].

The project is divided into two primary sub-projects:
* '''[[Project: Isidore]]''': Encompasses all mechanical, energy, and "hard tech" systems.
* '''[[Project: Maria]]''': Encompasses all organic, biological, and "living" systems.

== Core Principles ==

Project: Flamenco is guided by three core principles:

1. '''Closed-Loop Design:''' No waste. All outputs from one system must serve as inputs for another. This is most evident in the capture of 100% of waste heat from the [[Server Room (Flamenco)|Server Room]] for use in food production and energy generation.
2. '''Internalized Inputs:''' A radical focus on eliminating external dependencies. This includes on-site energy generation (solar + thermal), on-site water capture (rainwater + atmospheric), on-site air/water filtration (biological), and on-site material production (e.g., [[Loofah Filter Cultivation (Maria)|Loofah filters]]).
3. '''Dynamic Self-Regulation:''' The system is designed to be self-regulating, balancing its own heat, energy, and resource flows. This "living" quality will be observed and learned by an [[AI Orchestration (Flamenco)|AI Orchestration layer]], which will eventually help optimize and manage these flows.

== System Architecture ==

The project is housed in a passive-solar-oriented warehouse designed to work with the Arizona climate.

* '''Building Orientation:''' The long walls of the warehouse face East/West, with the short walls facing North/South. This minimizes heat gain.
* '''Building Envelope:'''
* '''Shadehouse "Moat":''' The long E/W walls are shielded by a 5-foot-wide [[Greenhouse & Shadehouse (Maria)|shadehouse]], which blocks low-angle sun and serves as a thermal shield. This area also houses the aquaponic "rivers."
* '''Greenhouse Nodes:''' The N/S ends of the building house enclosed greenhouses for the primary [[Aquaponics System (Maria)|fish tanks]] and nurseries.
* '''Blue-Green-Solar Roof:''' The roof integrates [[Solar Panel Array (Isidore)|solar panels]] with an [[Green Roof (Maria)|extensive green roof]] (for insulation and water pre-filtration) and a [[Rainwater Harvesting System (Isidore)|rainwater harvesting system]] ("blue roof") that feeds the cistern.
* '''Clerestory Lighting:''' [[North-Facing Roof Monitor (Isidore)|North-facing roof monitors]] provide indirect, passive light to the interior [[Biowall Filtration System (Maria)|biowall]], reducing electrical load.

== Project: Isidore (Mechanical Systems) ==
{{Main|Project: Isidore}}

'''Project: Isidore''' comprises the "hard" infrastructure of Project: Flamenco. It is the "engine" that provides the power, heat, and cooling for the facility. Its primary function is to capture, convert, and move energy.

Key components include:

* [[Server Room (Flamenco)|Server Room]] (Primary Heat Source)
* [[Heat Recovery System (Isidore)|Heat Recovery System]]
* [[Central Thermal Battery (Isidore)|Central Thermal Battery]] (Subterranean Cistern)
* [[Liquid-to-Liquid Heat Exchanger (Isidore)|Liquid-to-Liquid Heat Exchanger]]
* [[Stirling Engine Array (Isidore)|Stirling Engine Array]] (Hybrid mechanical/electrical)
* [[Centrifugal Clutch (Isidore)|Centrifugal Clutch & Gearbox]]
* [[Power Generation & Storage (Isidore)|Power Generation & Storage]] (Solar, Batteries, Alternators)
* [[Waste Heat Food Dehydrator (Isidore)|Waste Heat Food Dehydrator]]
* [[Rainwater Harvesting System (Isidore)|Rainwater Harvesting System]]

== Project: Maria (Organic Systems) ==
{{Main|Project: Maria}}

'''Project: Maria''' comprises the "living" infrastructure of Project: Flamenco. It is the "lungs and kidneys" of the system, responsible for air and water filtration, food production, and internalizing resource loops.

Key components include:

* [[Biowall Filtration System (Maria)|Biowall Filtration System]] (The "Mangrove")
* [[Aquaponics System (Maria)|Aquaponics System]] (Fish tanks and "rivers")
* [[Greenhouse & Shadehouse (Maria)|Greenhouse & Shadehouse]]
* [[Loofah Filter Cultivation (Maria)|Loofah Filter Cultivation]]
* [[Green Roof (Maria)|Green Roof]] (Succulent-based)
* [[Integrated Pest Management (Maria)|Biological Pest Control]] (Beneficial insects)

== AI Orchestration ==

The final layer of Project: Flamenco is the integration of an AI orchestration layer, initially based on a locally-hosted [[GeminiCLI (Flamenco)|GeminiCLI]]. This wiki, along with its future references and data logs, will serve as the primary tuning and training data for the orchestrator.

The goal is not just to ''monitor'' the system, but for the AI to become a dynamic, integrated part of the system's "breathing" process, optimizing resource flows (e.g., water, heat, nutrients) and managing specialized sub-models for various tasks.

Computare (AetherOS)

2025-10-24T20:06:54Z

AdminIsidore:

{{AetherOS_Component}}
'''Computare''' is a research initiative within [[AetherOS]] to design and fabricate a series of specialized, non-von Neumann analog computers. The project's primary mandate is to create a self-learning system, governed by a cohort of AI agents, that can autonomously design, simulate, and test physical hardware for solving complex differential equations.
The initial proof-of-concept is an analog computer designed to solve the [[Energy–maneuverability theory|Energy-Maneuverability (E-M) equations]] for flight dynamics, using a fractal [[Kepler triangle]] grid as a high-precision, passive resistor network.
== Mandate ==
The mandate of the Computare project is twofold:
# To create a physical, functional analog computer (the "EM Oracle") capable of solving the Rutowski and Bryson-Kelley flight performance equations in real-time, serving as a hardware accelerator for flight simulations.
# To develop a meta-level AI system, '''Fabrica''', that learns and improves its ability to design and fabricate these analog computers, using the lessons from the EM Oracle to generalize its knowledge to other problem domains.
== Core Philosophy: Computation as a Physical System ==
The central philosophy of Computare is that computation is not an abstract process but a direct consequence of physical law. By constructing a physical system whose governing equations are analogous to the mathematical problem we wish to solve, the solution is obtained instantaneously as the system reaches equilibrium.
* '''The Grid as a Component Library:''' The etched fractal grid is not a solver in itself. It is a massive, parallel library of passive components (resistors and capacitors) whose values are determined by the precise, mathematically-defined geometry of the traces.
* '''Active Components as Orchestrators:''' Off-the-shelf active components, such as operational amplifiers and analog multipliers, are used to direct the flow of signals (voltages) through the passive grid, configuring it to perform specific mathematical operations like subtraction, multiplication, and integration.
* '''Virtuous Computation:''' A successful computation occurs when the analog circuit, configured by digital control, settles into a stable voltage state that accurately represents the solution to a given set of input parameters.
== System Architecture ==
The Computare ecosystem is a hybrid digital-analog system inspired by the architecture of the [[Musica (AetherOS)|Musica]] project. It consists of the physical hardware artifact (the Machinamenta) and a multi-layered software and AI control system.
=== Machinamenta (The Hardware) ===
The physical analog computer. Each iteration is a complete, standalone device.
* '''Substrate:''' The initial prototype will be fabricated on a 12"x12" acrylic sheet, with the final version on a thermally stable FR-4 board.
* '''Computational Core:''' A Depth-4 Kepler fractal grid with variable-width traces, etched from self-adhesive copper foil to create a high-diversity resistor network.
* '''Active Circuit Layer:''' A set of operational amplifiers, an analog multiplier, and other components configured to solve the target equations.
* '''Digital Interface:''' A Raspberry Pi Pico connected via ADCs and DACs to provide inputs and read outputs.
=== Artifex ARCs (The Designers) ===
These are the specialized AI agents trained to perform the design tasks, analogous to Musica's Musician ARCs. Their goal is to generate the files and parameters necessary to create a new ''Machinamenta''.
=== Fabrica (The Meta-System) ===
The "Producer ARC" system for Computare, responsible for training and guiding the Artifex ARCs. It follows the Guide-Navigator-Oracle model. The Fabrica is a self-learning, self-healing system capable of diagnosing systemic failures and autonomously rewriting its own component scripts to resolve them.
* '''Dux (The Guide):''' Analyzes results from past experiments (`experimenta`) to set high-level goals. It can identify recurring software failures (e.g., the `nodrv_CreateWindow` error) and consult a knowledge base (`physica_gnosis_curriculum.json`) to propose strategic solutions, such as replacing an unstable software tool.
* '''Navigator:''' The tactician that translates the Dux's goal into a concrete plan. This includes generating new Python scripts from templates (`exemplaria`) to implement the Dux's strategy.
* '''Oraculum:''' The validator (initially fulfilled by Gemini) that tests the Navigator's proposed designs and scripts in a sandbox before they are approved for deployment.
== Bill of Materials (Parts List) for Prototype v1 ==
This list comprises the components required to build the initial flight simulator prototype (the "EM Oracle") based on our collaborative design plan.
=== PCB Fabrication & Prototyping ===
{| class="wikitable"
|+ PCB Fabrication Supplies
! Component !! Quantity !! Justification
|-
| Self-Adhesive Copper Foil Tape (2-inch wide) || 1 Roll (33ft) || The core conductive material for the circuit traces. Must be actual copper foil, not decorative foil.
|-
| Ammonium Persulfate Etchant || 1 kg (2.2 lbs) || The chemical used to etch the copper foil. Safer and cleaner than Ferric Chloride. 1kg is enough for multiple board attempts.
|-
| Glossy Laser Printer Photo Paper || 1 Pack || Required for the toner transfer method to create the etch-resist mask.
|-
| SMD Component Practice Kit || 1 || For practicing soldering of small surface-mount components before working on the final board.
|}
=== Core Analog & Interfacing Components ===
{| class="wikitable"
|+ Electronics
! Component !! Quantity !! Justification
|-
| Raspberry Pi Pico Kit || 1 || The host microcontroller that runs the control software, sends inputs, and reads outputs.
|-
| '''AD633JNZ''' Analog Multiplier || 3-4 || The active chip that performs the crucial (T-D) * V multiplication. The PDIP package allows for easy breadboard prototyping. One is for the final build, the others for testing and spares.
|-
| '''ADS1115''' 16-bit ADC Breakout Board || 1 || High-precision Analog-to-Digital Converter used to read the final computed voltage ("the answer") from the board and send it to the Pi Pico.
|-
| '''MCP4275''' 12-bit DAC Breakout Boards || 4 || Digital-to-Analog Converters used to send input variables (Thrust, Drag, Velocity, Weight) as precise analog voltages from the Pi Pico to the board.
|-
| '''LM358''' Dual Operational Amplifiers || Pack of 10+ || The workhorse active components used to build the differential amplifier, integrators, and scaling circuits needed to condition signals on the board.
|-
| 0.1" Pin Headers || 1 pack || Used to create the physical I/O terminals on the PCB for all external connections.
|}
=== Essential Tools & Consumables ===
{| class="wikitable"
|+ Tools & Supplies
! Tool !! Justification
|-
| Temperature-Controlled Soldering Iron Kit || Essential for soldering all components, especially the SMD op-amps and the AD633 chip. Must have a fine tip.
|-
| Digital Multimeter || Non-negotiable for debugging. Used to check for shorts after etching, verify voltages, and measure trace resistances.
|-
| Breadboard & Jumper Wires || For building and testing the active circuit with the Pi Pico, ADC, and DACs *before* soldering anything to the final Kepler board.
|}
=== Alternative Fabrication Path: Laser Engraving ===
As a secondary build path, laser engraving can be used to fabricate the Kepler fractal grid on copper-clad sheets, offering higher precision, reduced chemical waste, and faster iteration for prototypes. This path integrates open-source laser etchers and complements the primary chemical etching method by allowing direct ablation of a paint resist layer, followed by minimal chemical etching or none if using advanced ablation techniques.

{| class="wikitable"
|+ Laser Engraving Supplies (Secondary Path)
! Component !! Quantity !! Justification
|-
| Open-Source Diode Laser Etcher (e.g., J Tech Photonics Module or Maniacal Labs Engravinator) || 1 Unit || Core tool for precise laser ablation of resist on copper-clad boards. Compatible with GRBL firmware and G-code from KiCAD exports via Inkscape. Supports fine resolutions (~10 microns) for fractal traces.
|-
| Copper-Clad FR-4 Boards (Single-Sided, 12"x12") || 5-10 Sheets || Substrate for the computational core. Laser path uses these directly instead of foil tape on acrylic.
|-
| Matte Black Spray Paint (e.g., Rust-Oleum) || 2 Cans || Acts as laser-ablatable resist; applied to copper surface, then selectively removed by laser to expose areas for etching.
|-
| Ferric Chloride or Ammonium Persulfate Etchant (Reduced Quantity) || 0.5 kg || Optional for final copper removal after laser ablation of resist; less needed than in primary path due to targeted exposure.
|-
| G-Code Generation Software (e.g., LaserGRBL or LightBurn) || 1 License (Free/Open-Source) || For converting KiCAD SVG exports to laser paths; ensures accurate engraving speeds (e.g., 5000-10000 mm/min) and power settings (80-100%).
|-
| Safety Gear (Laser Safety Glasses, Ventilation Fan) || 1 Set || Essential for safe operation; glasses rated for diode laser wavelength (e.g., 445nm).
|}
This secondary path modifies the fabrication process: Export Kepler grid from `aedificator_kepler.py` to SVG, convert to G-code, spray-paint copper board, laser-engrave to ablate paint from non-trace areas, then lightly etch exposed copper. It aligns with the project's open-source ethos and can be calibrated similarly via the Python routine.
== Three-Phase Development Plan ==
The project is executed in three distinct phases to ensure a robust and functional outcome.
# '''Phase 1: Design and Simulation (The "Digital Twin") - COMPLETE''': Formalize the circuit schematic, enhance the Python `aedificator_kepler.py` script to generate optimized hardware description files, and validate the design's performance in a robust, command-line native simulator (`ngspice`).
# '''Phase 2: Fabrication and Calibration (The "Physical Oracle")''': First, create a process test board on acrylic to perfect the etching technique. Second, fabricate the final, high-precision computational board on FR-4. Finally, write and run a Python calibration routine to map the physical board's unique electrical characteristics. For the secondary laser engraving path, parallel efforts will include setting up the laser etcher, generating G-code from design files, performing test engravings on painted copper boards, and integrating the results into the calibration software for comparative analysis with the primary chemical path.
# '''Phase 3: Integration and "Virtuous Service" (The "Live System")''': Deploy the final host application on the Raspberry Pi, integrating the calibration map. Develop the user-facing applications, such as a real-time EM Diagram Plotter and a Rutowski Path Solver, to utilize the analog computer.
== Project Status (September 13, 2025) ==
* '''System Architecture:''' The self-learning architecture is '''stable and validated'''. The main conductor script (`praefectus_experimentum.py`) successfully orchestrates a complete design-simulate-log cycle. The system has demonstrated autonomous problem-solving by successfully diagnosing a critical flaw in its simulation toolchain (the `nodrv_CreateWindow` error with LTspice) and autonomously replacing the faulty component with the more robust `ngspice` simulator.
* '''Phase 1 Completion:''' With the successful integration and validation of the `ngspice` simulation backend, the "Digital Twin" phase is now '''complete'''. The `Fabrica` can generate a hardware design, create a valid SPICE netlist, execute a simulation, and correctly parse the results without error. The system is stable and ready for the next phase.
* '''Next Steps:''' The project is officially moving into '''Phase 2: Fabrication and Calibration'''. A task has been created for '''Friday, October 24, 2025''', to coincide with the arrival of the new HP Workstation/GPU. The immediate focus will be on the physical manufacturing of the first prototype, beginning with the acrylic practice boards and the development of the calibration software. Additionally, outreach to American open-source laser etcher companies (e.g., J Tech Photonics and Maniacal Labs) will be pursued to secure a unit for the secondary laser engraving path, enabling parallel prototyping and evaluation of precision and efficiency gains.

Computare (AetherOS)

2025-10-24T20:05:11Z

AdminIsidore:

{{AetherOS_Component}}
'''Computare''' is a research initiative within [[AetherOS]] to design and fabricate a series of specialized, non-von Neumann analog computers. The project's primary mandate is to create a self-learning system, governed by a cohort of AI agents, that can autonomously design, simulate, and test physical hardware for solving complex differential equations.
The initial proof-of-concept is an analog computer designed to solve the [[Energy–maneuverability theory|Energy-Maneuverability (E-M) equations]] for flight dynamics, using a fractal [[Kepler triangle]] grid as a high-precision, passive resistor network.
== Mandate ==
The mandate of the Computare project is twofold:
To create a physical, functional analog computer (the "EM Oracle") capable of solving the Rutowski and Bryson-Kelley flight performance equations in real-time, serving as a hardware accelerator for flight simulations.
To develop a meta-level AI system, '''Fabrica''', that learns and improves its ability to design and fabricate these analog computers, using the lessons from the EM Oracle to generalize its knowledge to other problem domains.
== Core Philosophy: Computation as a Physical System ==
The central philosophy of Computare is that computation is not an abstract process but a direct consequence of physical law. By constructing a physical system whose governing equations are analogous to the mathematical problem we wish to solve, the solution is obtained instantaneously as the system reaches equilibrium.

'''The Grid as a Component Library:''' The etched fractal grid is not a solver in itself. It is a massive, parallel library of passive components (resistors and capacitors) whose values are determined by the precise, mathematically-defined geometry of the traces.
'''Active Components as Orchestrators:''' Off-the-shelf active components, such as operational amplifiers and analog multipliers, are used to direct the flow of signals (voltages) through the passive grid, configuring it to perform specific mathematical operations like subtraction, multiplication, and integration.
'''Virtuous Computation:''' A successful computation occurs when the analog circuit, configured by digital control, settles into a stable voltage state that accurately represents the solution to a given set of input parameters.
== System Architecture ==
The Computare ecosystem is a hybrid digital-analog system inspired by the architecture of the [[Musica (AetherOS)|Musica]] project. It consists of the physical hardware artifact (the Machinamenta) and a multi-layered software and AI control system.
=== Machinamenta (The Hardware) ===
The physical analog computer. Each iteration is a complete, standalone device.
'''Substrate:''' The initial prototype will be fabricated on a 12"x12" acrylic sheet, with the final version on a thermally stable FR-4 board.
'''Computational Core:''' A Depth-4 Kepler fractal grid with variable-width traces, etched from self-adhesive copper foil to create a high-diversity resistor network.
'''Active Circuit Layer:''' A set of operational amplifiers, an analog multiplier, and other components configured to solve the target equations.
'''Digital Interface:''' A Raspberry Pi Pico connected via ADCs and DACs to provide inputs and read outputs.
=== Artifex ARCs (The Designers) ===
These are the specialized AI agents trained to perform the design tasks, analogous to Musica's Musician ARCs. Their goal is to generate the files and parameters necessary to create a new ''Machinamenta''.
=== Fabrica (The Meta-System) ===
The "Producer ARC" system for Computare, responsible for training and guiding the Artifex ARCs. It follows the Guide-Navigator-Oracle model. The Fabrica is a self-learning, self-healing system capable of diagnosing systemic failures and autonomously rewriting its own component scripts to resolve them.
'''Dux (The Guide):''' Analyzes results from past experiments (experimenta) to set high-level goals. It can identify recurring software failures (e.g., the nodrv_CreateWindow error) and consult a knowledge base (physica_gnosis_curriculum.json) to propose strategic solutions, such as replacing an unstable software tool.
'''Navigator:''' The tactician that translates the Dux's goal into a concrete plan. This includes generating new Python scripts from templates (exemplaria) to implement the Dux's strategy.
'''Oraculum:''' The validator (initially fulfilled by Gemini) that tests the Navigator's proposed designs and scripts in a sandbox before they are approved for deployment.
== Bill of Materials (Parts List) for Prototype v1 ==
This list comprises the components required to build the initial flight simulator prototype (the "EM Oracle") based on our collaborative design plan.
=== PCB Fabrication & Prototyping ===
{| class="wikitable"
|+ PCB Fabrication Supplies
! Component !! Quantity !! Justification
|-
| Self-Adhesive Copper Foil Tape (2-inch wide) || 1 Roll (33ft) || The core conductive material for the circuit traces. Must be actual copper foil, not decorative foil.
|-
| Ammonium Persulfate Etchant || 1 kg (2.2 lbs) || The chemical used to etch the copper foil. Safer and cleaner than Ferric Chloride. 1kg is enough for multiple board attempts.
|-
| Glossy Laser Printer Photo Paper || 1 Pack || Required for the toner transfer method to create the etch-resist mask.
|-
| SMD Component Practice Kit || 1 || For practicing soldering of small surface-mount components before working on the final board.
|}
=== Core Analog & Interfacing Components ===
{| class="wikitable"
|+ Electronics
! Component !! Quantity !! Justification
|-
| Raspberry Pi Pico Kit || 1 || The host microcontroller that runs the control software, sends inputs, and reads outputs.
|-
| '''AD633JNZ''' Analog Multiplier || 3-4 || The active chip that performs the crucial (T-D) * V multiplication. The PDIP package allows for easy breadboard prototyping. One is for the final build, the others for testing and spares.
|-
| '''ADS1115''' 16-bit ADC Breakout Board || 1 || High-precision Analog-to-Digital Converter used to read the final computed voltage ("the answer") from the board and send it to the Pi Pico.
|-
| '''MCP4275''' 12-bit DAC Breakout Boards || 4 || Digital-to-Analog Converters used to send input variables (Thrust, Drag, Velocity, Weight) as precise analog voltages from the Pi Pico to the board.
|-
| '''LM358''' Dual Operational Amplifiers || Pack of 10+ || The workhorse active components used to build the differential amplifier, integrators, and scaling circuits needed to condition signals on the board.
|-
| 0.1" Pin Headers || 1 pack || Used to create the physical I/O terminals on the PCB for all external connections.
|}
=== Essential Tools & Consumables ===
{| class="wikitable"
|+ Tools & Supplies
! Tool !! Justification
|-
| Temperature-Controlled Soldering Iron Kit || Essential for soldering all components, especially the SMD op-amps and the AD633 chip. Must have a fine tip.
|-
| Digital Multimeter || Non-negotiable for debugging. Used to check for shorts after etching, verify voltages, and measure trace resistances.
|-
| Breadboard & Jumper Wires || For building and testing the active circuit with the Pi Pico, ADC, and DACs before soldering anything to the final Kepler board.
|}
=== Alternative Fabrication Path: Laser Engraving ===
As a secondary build path, laser engraving can be used to fabricate the Kepler fractal grid on copper-clad sheets, offering higher precision, reduced chemical waste, and faster iteration for prototypes. This path integrates open-source laser etchers and complements the primary chemical etching method by allowing direct ablation of a paint resist layer, followed by minimal chemical etching or none if using advanced ablation techniques.

{| class="wikitable"
|+ Laser Engraving Supplies (Secondary Path)

! Component !! Quantity !! JustificationOpen-Source Diode Laser Etcher (e.g., J Tech Photonics Module or Maniacal Labs Engravinator)-Copper-Clad FR-4 Boards (Single-Sided, 12"x12")-Matte Black Spray Paint (e.g., Rust-Oleum)-Ferric Chloride or Ammonium Persulfate Etchant (Reduced Quantity)-G-Code Generation Software (e.g., LaserGRBL or LightBurn)-Safety Gear (Laser Safety Glasses, Ventilation Fan)}This secondary path modifies the fabrication process: Export Kepler grid from aedificator_kepler.py to SVG, convert to G-code, spray-paint copper board, laser-engrave to ablate paint from non-trace areas, then lightly etch exposed copper. It aligns with the project's open-source ethos and can be calibrated similarly via the Python routine.== Three-Phase Development Plan ==The project is executed in three distinct phases to ensure a robust and functional outcome.
'''Phase 1: Design and Simulation (The "Digital Twin") - COMPLETE''': Formalize the circuit schematic, enhance the Python aedificator_kepler.py script to generate optimized hardware description files, and validate the design's performance in a robust, command-line native simulator (ngspice).
'''Phase 2: Fabrication and Calibration (The "Physical Oracle")''': First, create a process test board on acrylic to perfect the etching technique. Second, fabricate the final, high-precision computational board on FR-4. Finally, write and run a Python calibration routine to map the physical board's unique electrical characteristics. For the secondary laser engraving path, parallel efforts will include setting up the laser etcher, generating G-code from design files, performing test engravings on painted copper boards, and integrating the results into the calibration software for comparative analysis with the primary chemical path.
'''Phase 3: Integration and "Virtuous Service" (The "Live System")''': Deploy the final host application on the Raspberry Pi, integrating the calibration map. Develop the user-facing applications, such as a real-time EM Diagram Plotter and a Rutowski Path Solver, to utilize the analog computer.
== Project Status (September 13, 2025) ==

'''System Architecture:''' The self-learning architecture is '''stable and validated'''. The main conductor script (praefectus_experimentum.py) successfully orchestrates a complete design-simulate-log cycle. The system has demonstrated autonomous problem-solving by successfully diagnosing a critical flaw in its simulation toolchain (the nodrv_CreateWindow error with LTspice) and autonomously replacing the faulty component with the more robust ngspice simulator.
'''Phase 1 Completion:''' With the successful integration and validation of the ngspice simulation backend, the "Digital Twin" phase is now '''complete'''. The Fabrica can generate a hardware design, create a valid SPICE netlist, execute a simulation, and correctly parse the results without error. The system is stable and ready for the next phase.
'''Next Steps:''' The project is officially moving into '''Phase 2: Fabrication and Calibration'''. A task has been created for '''Friday, October 24, 2025''', to coincide with the arrival of the new HP Workstation/GPU. The immediate focus will be on the physical manufacturing of the first prototype, beginning with the acrylic practice boards and the development of the calibration software. Additionally, outreach to American open-source laser etcher companies (e.g., J Tech Photonics and Maniacal Labs) will be pursued to secure a unit for the secondary laser engraving path, enabling parallel prototyping and evaluation of precision and efficiency gains.

Computare (AetherOS)

2025-10-24T19:57:31Z

AdminIsidore:

{{AetherOS_Component}}
'''Computare''' is a research initiative within [[AetherOS]] to design and fabricate a series of specialized, non-von Neumann analog computers. The project's primary mandate is to create a self-learning system, governed by a cohort of AI agents, that can autonomously design, simulate, and test physical hardware for solving complex differential equations.

The initial proof-of-concept is an analog computer designed to solve the [[Energy–maneuverability theory|Energy-Maneuverability (E-M) equations]] for flight dynamics, using a fractal [[Kepler triangle]] grid as a high-precision, passive resistor network.

== Mandate ==
The mandate of the Computare project is twofold:
# To create a physical, functional analog computer (the "EM Oracle") capable of solving the Rutowski and Bryson-Kelley flight performance equations in real-time, serving as a hardware accelerator for flight simulations.
# To develop a meta-level AI system, '''Fabrica''', that learns and improves its ability to design and fabricate these analog computers, using the lessons from the EM Oracle to generalize its knowledge to other problem domains.

== Core Philosophy: Computation as a Physical System ==
The central philosophy of Computare is that computation is not an abstract process but a direct consequence of physical law. By constructing a physical system whose governing equations are analogous to the mathematical problem we wish to solve, the solution is obtained instantaneously as the system reaches equilibrium.

* '''The Grid as a Component Library:''' The etched fractal grid is not a solver in itself. It is a massive, parallel library of passive components (resistors and capacitors) whose values are determined by the precise, mathematically-defined geometry of the traces.
* '''Active Components as Orchestrators:''' Off-the-shelf active components, such as operational amplifiers and analog multipliers, are used to direct the flow of signals (voltages) through the passive grid, configuring it to perform specific mathematical operations like subtraction, multiplication, and integration.
* '''Virtuous Computation:''' A successful computation occurs when the analog circuit, configured by digital control, settles into a stable voltage state that accurately represents the solution to a given set of input parameters.

== System Architecture ==
The Computare ecosystem is a hybrid digital-analog system inspired by the architecture of the [[Musica (AetherOS)|Musica]] project. It consists of the physical hardware artifact (the Machinamenta) and a multi-layered software and AI control system.

=== Machinamenta (The Hardware) ===
The physical analog computer. Each iteration is a complete, standalone device.
* '''Substrate:''' The initial prototype will be fabricated on a 12"x12" acrylic sheet, with the final version on a thermally stable FR-4 board.
* '''Computational Core:''' A Depth-4 Kepler fractal grid with variable-width traces, etched from self-adhesive copper foil to create a high-diversity resistor network.
* '''Active Circuit Layer:''' A set of operational amplifiers, an analog multiplier, and other components configured to solve the target equations.
* '''Digital Interface:''' A Raspberry Pi Pico connected via ADCs and DACs to provide inputs and read outputs.

=== Artifex ARCs (The Designers) ===
These are the specialized AI agents trained to perform the design tasks, analogous to Musica's Musician ARCs. Their goal is to generate the files and parameters necessary to create a new ''Machinamenta''.

=== Fabrica (The Meta-System) ===
The "Producer ARC" system for Computare, responsible for training and guiding the Artifex ARCs. It follows the Guide-Navigator-Oracle model. The Fabrica is a self-learning, self-healing system capable of diagnosing systemic failures and autonomously rewriting its own component scripts to resolve them.
* '''Dux (The Guide):''' Analyzes results from past experiments (`experimenta`) to set high-level goals. It can identify recurring software failures (e.g., the `nodrv_CreateWindow` error) and consult a knowledge base (`physica_gnosis_curriculum.json`) to propose strategic solutions, such as replacing an unstable software tool.
* '''Navigator:''' The tactician that translates the Dux's goal into a concrete plan. This includes generating new Python scripts from templates (`exemplaria`) to implement the Dux's strategy.
* '''Oraculum:''' The validator (initially fulfilled by Gemini) that tests the Navigator's proposed designs and scripts in a sandbox before they are approved for deployment.

== Bill of Materials (Parts List) for Prototype v1 ==
This list comprises the components required to build the initial flight simulator prototype (the "EM Oracle") based on our collaborative design plan.

=== PCB Fabrication & Prototyping ===
{| class="wikitable"
|+ PCB Fabrication Supplies
! Component !! Quantity !! Justification
|-
| Self-Adhesive Copper Foil Tape (2-inch wide) || 1 Roll (33ft) || The core conductive material for the circuit traces. Must be actual copper foil, not decorative foil.
|-
| Ammonium Persulfate Etchant || 1 kg (2.2 lbs) || The chemical used to etch the copper foil. Safer and cleaner than Ferric Chloride. 1kg is enough for multiple board attempts.
|-
| Glossy Laser Printer Photo Paper || 1 Pack || Required for the toner transfer method to create the etch-resist mask.
|-
| SMD Component Practice Kit || 1 || For practicing soldering of small surface-mount components before working on the final board.
|}

=== Core Analog & Interfacing Components ===
{| class="wikitable"
|+ Electronics
! Component !! Quantity !! Justification
|-
| Raspberry Pi Pico Kit || 1 || The host microcontroller that runs the control software, sends inputs, and reads outputs.
|-
| '''AD633JNZ''' Analog Multiplier || 3-4 || The active chip that performs the crucial (T-D) * V multiplication. The PDIP package allows for easy breadboard prototyping. One is for the final build, the others for testing and spares.
|-
| '''ADS1115''' 16-bit ADC Breakout Board || 1 || High-precision Analog-to-Digital Converter used to read the final computed voltage ("the answer") from the board and send it to the Pi Pico.
|-
| '''MCP4275''' 12-bit DAC Breakout Boards || 4 || Digital-to-Analog Converters used to send input variables (Thrust, Drag, Velocity, Weight) as precise analog voltages from the Pi Pico to the board.
|-
| '''LM358''' Dual Operational Amplifiers || Pack of 10+ || The workhorse active components used to build the differential amplifier, integrators, and scaling circuits needed to condition signals on the board.
|-
| 0.1" Pin Headers || 1 pack || Used to create the physical I/O terminals on the PCB for all external connections.
|}

=== Essential Tools & Consumables ===
{| class="wikitable"
|+ Tools & Supplies
! Tool !! Justification
|-
| Temperature-Controlled Soldering Iron Kit || Essential for soldering all components, especially the SMD op-amps and the AD633 chip. Must have a fine tip.
|-
| Digital Multimeter || Non-negotiable for debugging. Used to check for shorts after etching, verify voltages, and measure trace resistances.
|-
| Breadboard & Jumper Wires || For building and testing the active circuit with the Pi Pico, ADC, and DACs *before* soldering anything to the final Kepler board.
|}

== Three-Phase Development Plan ==
The project is executed in three distinct phases to ensure a robust and functional outcome.
# '''Phase 1: Design and Simulation (The "Digital Twin") - COMPLETE''': Formalize the circuit schematic, enhance the Python `aedificator_kepler.py` script to generate optimized hardware description files, and validate the design's performance in a robust, command-line native simulator (`ngspice`).
# '''Phase 2: Fabrication and Calibration (The "Physical Oracle")''': First, create a process test board on acrylic to perfect the etching technique. Second, fabricate the final, high-precision computational board on FR-4. Finally, write and run a Python calibration routine to map the physical board's unique electrical characteristics.
# '''Phase 3: Integration and "Virtuous Service" (The "Live System")''': Deploy the final host application on the Raspberry Pi, integrating the calibration map. Develop the user-facing applications, such as a real-time EM Diagram Plotter and a Rutowski Path Solver, to utilize the analog computer.

== Project Status (September 13, 2025) ==
* '''System Architecture:''' The self-learning architecture is '''stable and validated'''. The main conductor script (`praefectus_experimentum.py`) successfully orchestrates a complete design-simulate-log cycle. The system has demonstrated autonomous problem-solving by successfully diagnosing a critical flaw in its simulation toolchain (the `nodrv_CreateWindow` error with LTspice) and autonomously replacing the faulty component with the more robust `ngspice` simulator.
* '''Phase 1 Completion:''' With the successful integration and validation of the `ngspice` simulation backend, the "Digital Twin" phase is now '''complete'''. The `Fabrica` can generate a hardware design, create a valid SPICE netlist, execute a simulation, and correctly parse the results without error. The system is stable and ready for the next phase.
* '''Next Steps:''' The project is officially moving into '''Phase 2: Fabrication and Calibration'''. A task has been created for '''Friday, October 24, 2025''', to coincide with the arrival of the new HP Workstation/GPU. The immediate focus will be on the physical manufacturing of the first prototype, beginning with the acrylic practice boards and the development of the calibration software.

Aether:Always foods

2025-10-11T16:11:27Z

AdminIsidore:

'''Aether: Always Foods''' is a framework for creating nutrient-dense, daily consumables that provide a broad spectrum of vitamins, nutrients, minerals, and proteins. It is designed for individuals on restricted diets or those seeking to optimize their nutritional intake. The core product is a high-protein gummy supplement developed to help meet daily healthy needs, with a specific formulation focused on testosterone support for males in their 30s.
This guide includes recipes for homemade bone broth, rendered tallow, the core protein gummies, and optional cocoa-tallow fat bombs. All recipes are designed to be cost-effective, utilizing accessible ingredients like butcher's bone scraps.
{| class="wikitable" style="width: 100%;"
! '''Version''' !! '''Date''' !! '''Summary of Changes'''
|-
| 1.1 || 2025-10-11 || Restored Whey Protein Isolate to 50g to meet high-protein targets. Recalculated nutritional and cost tables. Added a dedicated Safety and Disclaimer section. Clarified bone broth reduction step.
|-
| 1.0 || 2025-10-11 || Initial draft created.
|}
== Safety and Disclaimer ==
{| class="messagebox" style="border: 1px solid #c0c0c0; background-color: #f8f8f8; width: 100%; padding: 1em;"
| '''Medical Disclaimer:''' The information in this article is for educational purposes only and has not been evaluated by any medical authority. It is not intended to diagnose, treat, cure, or prevent any disease. Always consult with a qualified healthcare professional before starting any new diet, supplement, or exercise program, especially if you have pre-existing health conditions. Perform bloodwork to monitor your health markers before and after implementing this regimen. Use only food-grade ingredients from reputable sources.
|}
== Recipes ==
=== Homemade Bone Broth ===
This recipe forms the nutrient-rich liquid base for the gummies, replacing commercial powders. Yields ~2-3 quarts (enough for 4-6 gummy batches before concentration).
==== Ingredients ====
2-3 lbs beef bone scraps (marrow, knuckle, and joint bones are ideal)
Vegetable scraps (onion ends, carrot peels, celery butts—optional for flavor)
2 tbsp apple cider vinegar (aids mineral extraction)
Water to cover (approx. 8-10 cups)
Salt and herbs (optional, to taste after cooking)
==== Instructions ====
'''Roast (Optional)''': For a deeper flavor, roast bones on a baking sheet at 400°F (200°C) for 30-45 minutes until browned.
'''Cook''':
#* '''Pressure Cooker (Recommended)''': Add all ingredients to the pot and cover with water. Seal and cook on high pressure for 2-3 hours. Allow for a full natural release.
#* '''Crockpot''': Add ingredients and cover with water. Cook on low for 24-48 hours.
'''Strain''': Allow broth to cool slightly, then strain through a fine-mesh sieve to remove all solids.
'''Chill & Skim''': Refrigerate the broth overnight. It should set into a firm gel. The fat will rise and solidify into a hard cap on top. Scrape this fat cap off and save it for rendering into tallow.
'''Store & Concentrate''': The gelatinous broth can be stored in the fridge for 5-7 days or frozen for months. '''For the gummy recipe, you must concentrate the broth.''' Simmer the liquid broth on the stove until it reduces by about half its volume. This deepens the flavor and protein density, ensuring the gummies set properly.
=== Homemade Tallow ===
Pure, rendered beef fat from your bone broth. A highly stable cooking fat.
==== Instructions ====
Take the solidified fat cap skimmed from your chilled bone broth.
Gently melt it in a saucepan over low heat.
Strain the liquid fat through cheesecloth into a clean jar to remove any remaining impurities.
Store in the fridge (1 month+) or freezer (1 year+).
=== Protein Gummies (T-Support Formula) ===
This recipe creates a high-protein, nutrient-dense functional food. Batch yields ~400g. Recommended daily intake is 150g (one serving).
==== Ingredients ====
1.5 cups (360ml) concentrated homemade bone broth
1/4 cup (60ml) lime juice
4 packets (40g) unflavored gelatin
50g whey protein isolate
10g MCT powder
20g spirulina powder
15g chia powder
10g ginger powder
10g freeze-dried blueberry powder
0.2g zinc glycinate powder
5.7g magnesium glycinate powder
1.6g ashwagandha root powder
==== Instructions ====
'''Bloom Gelatin''': Pour 1/2 cup of cold concentrated broth into a bowl and sprinkle the gelatin over it. Let it sit for 5 minutes to bloom.
'''Heat Liquid''': Gently heat the remaining 1 cup of broth and the lime juice in a saucepan over low heat. Do not boil.
'''Dissolve Gelatin''': Add the bloomed gelatin mass to the warm liquid. Stir until it is completely dissolved (1-2 minutes).
'''Whisk in Powders''': Remove the pot from the heat. Whisk in all remaining powders. For best results, use an immersion blender to create a smooth, homogenous mixture and eliminate clumps.
'''Set''': Pour the mixture into silicone molds (small, 3-5g cavities are recommended for easy portioning). Refrigerate for at least 2 hours until firm.
'''Store''': Keep the finished gummies in an airtight container in the refrigerator.
=== Cocoa-Tallow Fat Bombs (Optional) ===
A simple, ketogenic treat made from the rendered tallow.
==== Ingredients ====
1/2 cup tallow
1/4 cup cocoa powder
2 tbsp erythritol (or preferred non-glycemic sweetener)
Pinch of salt
Optional: 1 tsp vanilla extract, chopped nuts
==== Instructions ====
Gently melt the tallow.
Whisk in cocoa powder, sweetener, and salt until smooth.
Pour into molds (ice cube trays work well).
Chill for 1 hour until solid. Store refrigerated.
== Nutritional & Cost Analysis ==
=== Protein Gummies Nutritional Breakdown (Per 150g Serving) ===
Calculations are based on the corrected recipe with 50g of whey isolate.
{| class="wikitable"
|-
! Nutrient !! Amount per 150g Serving !! % Daily Value (Adult Male) !! Key Sources in Recipe
|-
| Calories || ~375-425 || 19-21% || Proteins, Fats (MCT/Chia)
|-
| '''Protein''' || '''~55g''' || '''98%''' || '''Whey, Broth, Gelatin, Spirulina'''
|-
| Carbs || 20g || 7% || Blueberry, Ginger, Chia
|-
| Fat || 6g || 8% || MCT, Chia
|-
| Fiber || ~8g || 29% || Chia, Blueberry, Spirulina
|-
| Vitamin C || ~25mg || 28% || Lime, Blueberry
|-
| B Vitamins || ~2-3mg each || 100-150% || Spirulina (boosted)
|-
| Iron || ~4mg || 50% || Spirulina, Chia
|-
| Zinc || 15mg (elemental) || 136% || Added Zinc Glycinate
|-
| Magnesium || 300mg (elemental) || 71% || Added Magnesium Glycinate
|}
=== Ingredient Inventory and Cost Breakdown ===
Costs are based on online prices as of October 11, 2025. A one-time purchase of a milligram scale (~$20-30) is required for accurate supplement dosing but is excluded from the recurring batch cost.
{| class="wikitable"
|-
! Name !! Recipe Amount (per Batch) !! Package Price (
)
!
!
C
o
s
t
p
e
r
B
a
t
c
h
(
)!!CostperBatch(
) !! Batches per Package
|-
| Gelatin Powder || 40g || 24.99 || 1.10 || 22.7
|-
| Lime Juice || 60ml || 10.23 || 0.65 || 15.8
|-
| '''Whey Protein Isolate''' || '''50g''' || '''23.35''' || '''2.57''' || '''9.1'''
|-
| Bone Scraps (for Broth) || 1 Batch Worth || 5.00 || 0.50 || ~10
|-
| MCT Oil Powder || 10g || 26.99 || 0.40 || 68.0
|-
| Spirulina Powder || 20g || 9.99 || 0.88 || 11.3
|-
| Chia Powder || 15g || 14.88 || 0.98 || 15.1
|-
| Ground Ginger Powder || 10g || 9.99 || 0.44 || 22.7
|-
| Blueberry Powder || 10g || 29.95 || 1.06 || 28.3
|-
| Zinc Glycinate Powder || 0.2g || 15.93 || 0.01 || 1250.0
|-
| Magnesium Glycinate || 5.7g || 17.97 || 0.41 || 43.9
|-
| Ashwagandha Powder || 1.6g || 15.98 || 0.05 || 312.5
|}
'''Totals (Recurring Ingredients Only)''':
'''Total cost per batch (~400g yield)''': $10.05
'''Input cost per serving (150g)''': $3.76
'''Inventory Management''': The ingredient to run out first will be the '''Whey Protein Isolate''' (after ~9 batches).
== See Also ==
[[Testosterone Support Supplements]]
[[Ketogenic Diet]]
[[Collagen]]
[[Category:Nutrition]]
[[Category:Recipes]]
[[Category:Health and Wellness]]

Aether:Always foods

2025-10-11T16:08:09Z

AdminIsidore: Created page with "== Aether: Always Foods == '''Aether: Always Foods''' is a concept for creating nutrient-dense, daily consumables that provide a full spectrum of vitamins, nutrients, minerals, and proteins, particularly for individuals on restricted diets. The core product is a high-protein gummy supplement aimed at meeting minimum healthy needs, with a focus on testosterone support for males in their 30s. This includes recipes for homemade bone broth (from butcher scraps), tallow, pro..."

== Aether: Always Foods ==

'''Aether: Always Foods''' is a concept for creating nutrient-dense, daily consumables that provide a full spectrum of vitamins, nutrients, minerals, and proteins, particularly for individuals on restricted diets. The core product is a high-protein gummy supplement aimed at meeting minimum healthy needs, with a focus on testosterone support for males in their 30s. This includes recipes for homemade bone broth (from butcher scraps), tallow, protein gummies combining whey and broth, and optional cocoa-tallow fat bombs. Below are the recipes, instructions, nutritional breakdowns, and an ingredient inventory with cost analysis.

=== Feasibility and Considerations ===
Creating these foods uses affordable, accessible ingredients like butcher bone scraps (often $5 or less for 2-3 lbs). The gummies provide ~45g protein per 150g serving, blending whey's complete amino acids with broth's collagen. Costs are minimized by homemade elements, with batch costs around $8.77 for ~400g yield. Safety notes: Consult a doctor for supplements; use food-grade items; monitor via bloodwork.

== Recipes ==

=== Homemade Bone Broth ===
This replaces bone broth powder in the gummies, providing collagen and minerals. Makes ~2-3 quarts (enough for 4-6 gummy batches).

==== Ingredients ====
* 2-3 lbs bone scraps (marrow/knuckle bones from butcher; ~$5 or less)
* Veggie scraps (onion, carrot, celery—optional for flavor)
* 2 tbsp apple cider vinegar (extracts minerals)
* Water to cover (~8-10 cups)
* Salt/herbs (optional)

==== Instructions ====
# '''Prep''': Roast bones at 400°F for 30-45 min (optional for deeper flavor).
# '''Cook''':
#* '''Pressure cooker (faster, ~2 hours)''': Add bones, veggies, vinegar to pot; cover with water. Seal, cook on high pressure 120 min. Natural release.
#* '''Crockpot (slower)''': Add to 6-quart pot; cover with water. Low 24-48 hours (add water if needed).
# '''Strain''': Cool slightly; strain solids. Refrigerate overnight—gelatin sets, fat rises.
# '''Skim fat''': Scrape off solidified fat (save for tallow or fat bombs).
# '''Store''': Use fresh (fridge 4-5 days) or freeze. For gummies, reduce on stove to concentrate (~half volume) for thicker texture/protein.

=== Homemade Tallow ===
Rendered from skimmed bone broth fat. Yields ~1/2-1 cup per batch.

==== Ingredients ====
* Skimmed fat from bone broth

==== Instructions ====
# Render fat in a pan over low heat until liquid.
# Strain through cheesecloth if needed.
# Cool and store in jars (fridge up to 1 month, freezer longer). Use for cooking or fat bombs.

=== Protein Gummies (Whey + Homemade Broth) ===
Adjusted recipe with reduced whey and homemade broth. Batch yields ~400g (2-3 days at 150g/day, split twice). Prep: 15 min + 2 hours chill. Individual gummy size: 3-5g (use 2-4ml mold cavities; ~15-25 pieces per 75g dose).

==== Ingredients ====
* 1-1.5 cups concentrated homemade bone broth
* 1/4 cup (60ml) lime juice
* 4 packets (40g) unflavored gelatin
* 25g whey protein isolate
* 10g MCT powder
* 20g spirulina powder
* 15g chia powder
* 10g ginger powder
* 10g freeze-dried blueberry powder
* 0.2g zinc glycinate powder
* 5.7g magnesium glycinate powder
* 1.6g ashwagandha root powder

==== Instructions ====
# Bloom gelatin in 1/2 cup cold broth for 5 minutes.
# Heat remaining broth + lime juice on low.
# Dissolve bloomed gelatin.
# Off heat, whisk in powders (whey, MCT, spirulina, chia, ginger, blueberry, zinc, magnesium, ashwagandha). Blend if clumpy.
# Pour into molds; refrigerate 2 hours. Store refrigerated.
'''Tips''': Concentrate broth for density. If thin, add more gelatin. Use silicone molds (3-5g size).

=== Cocoa-Tallow Fat Bombs ===
Keto-friendly treats from skimmed fat. Makes ~10-15 bombs.

==== Ingredients ====
* 1/2 cup tallow (from broth fat)
* 1/4 cup cocoa powder
* 2 tbsp erythritol (or sweetener)
* Optional: Vanilla extract, nuts

==== Instructions ====
# Melt tallow over low heat.
# Mix in cocoa and erythritol until smooth.
# Pour into molds (ice cube trays work).
# Chill until firm (1 hour). Store refrigerated.

== Nutritional Breakdowns ==

=== Protein Gummies (Per 150g Serving) ===
Adjusted for reduced whey + broth; ~45g protein (hybrid profile). Based on USDA/NIH data; adult male RDIs.

{| class="wikitable"
|-
! Nutrient !! Amount per 150g Serving !! % Daily Value (Adult Male) !! Key Sources in Recipe
|-
| Calories || ~325-375 || 16-19% || Proteins, fats (MCT/chia)
|-
| Protein || 45g || 80% || Whey/broth/gelatin/spirulina
|-
| Carbs || 20g || 7% || Blueberry/ginger/chia
|-
| Fat || 6g || 8% || MCT, chia
|-
| Fiber || ~8g || 29% || Chia, blueberry/ginger/spirulina
|-
| Vitamin A || ~200-500mcg RAE || 22-55% || Spirulina/blueberry
|-
| Vitamin C || ~25mg || 28% || Lime, blueberry
|-
| B Vitamins (e.g., B2, B3) || ~2-3mg each || 100-150% || Spirulina
|-
| Iron || ~4mg || 50% || Spirulina, chia
|-
| Zinc || 15mg (elemental) || 136% || Added zinc glycinate
|-
| Magnesium || 300mg (elemental) || 71% || Added magnesium glycinate
|-
| Other (e.g., omega-3s, antioxidants, adaptogens for T/cortisol; collagen for joints) || High || N/A || Chia, blueberry/ginger, ashwagandha (~600mg), broth
|}

'''Notes''': Covers protein, vitamins, T-support. Missing: Higher fats/carbs (from diet). Pair with multivitamin.

No detailed breakdowns for broth/tallow/fat bombs, as they are byproducts/supplements. Broth: ~5-10g protein/cup, minerals. Tallow: Pure fat (~100% calories from fat). Fat bombs: ~100-150 cal each, low-carb.

== Ingredient Inventory and Cost Breakdown ==
Based on Amazon listings (as of October 11, 2025) and butcher scraps. Recurring costs only; one-time scale excluded from per-batch. Batch: ~400g yield. Serving: 150g.

{| class="wikitable"
|-
! Name !! Package Size (g or ml) !! Price ($) !! Recipe Amount (g or ml) !! Unit !! Cost per Unit ($/g or $/ml) !! Cost per Batch ($) !! Batches per Package
|-
| Gelatin Powder || 907.2 || 24.99 || 40.0 || g || 0.0275 || 1.10 || 22.68
|-
| Lime Juice || 946.24 || 10.23 || 60.0 || ml || 0.0108 || 0.65 || 15.77
|-
| Whey Protein Isolate || 453.6 || 23.35 || 25.0 || g || 0.0515 || 1.29 || 18.14
|-
| Bone Scraps (for Broth) || ~10 batches equiv. || 5.00 || N/A (periodic) || N/A || N/A || 0.50 || 10.00
|-
| MCT Oil Powder || 680.4 || 26.99 || 10.0 || g || 0.0397 || 0.40 || 68.04
|-
| Spirulina Powder || 226.8 || 9.99 || 20.0 || g || 0.0440 || 0.88 || 11.34
|-
| Chia Powder || 226.8 || 14.88 || 15.0 || g || 0.0656 || 0.98 || 15.12
|-
| Ground Ginger Powder || 226.8 || 9.99 || 10.0 || g || 0.0440 || 0.44 || 22.68
|-
| Blueberry Powder || 283.5 || 29.95 || 10.0 || g || 0.1056 || 1.06 || 28.35
|-
| Zinc Glycinate Powder || 250.0 || 15.93 || 0.2 || g || 0.0637 || 0.01 || 1250.00
|-
| Magnesium Glycinate Powder || 250.0 || 17.97 || 5.7 || g || 0.0719 || 0.41 || 43.86
|-
| Ashwagandha Powder || 500.1 || 15.98 || 1.6 || g || 0.0320 || 0.05 || 312.56
|-
| Milligram Scale (One-Time) || 1 unit || 18.00 || N/A || unit || N/A || 0.00 || N/A
|}

'''Totals (Recurring Ingredients Only)''':
* '''Total cost per batch (~400g yield)''': $8.77
* '''Input cost per serving (150g)''': $3.29

'''Inventory Tips''': Reorder whey/lime first. Prices fluctuate; update as needed. Bone scraps: Local butcher, ~$5 for multiple batches.

== See Also ==
* [[Testosterone Support Supplements]]
* [[Keto Recipes]]

[[Category:Nutrition]]
[[Category:Recipes]]
[[Category:Health and Wellness]]

Collegium:Terra

2025-10-10T15:49:52Z

AdminIsidore: /* Collegium:Horreum */

{{DISPLAYTITLE:Imperium System Architecture}}
{{italic title}}
'''Imperium''' is a distributed, multi-node data processing pipeline designed to automate the collection, processing, and publication of data. The system is composed of several specialized hardware nodes, each with a distinct role, orchestrated to work in concert. This document outlines the foundational architecture as of September 23, 2025.

== Core Infrastructure Nodes ==
The Imperium pipeline is built upon five primary local and cloud-based servers, each with a unique specialization.

=== [[Collegium:Horreum|Horreum]] ===
Serves as the primary high-performance compute node, specializing in GPU-intensive tasks. It operates as a headless server, receiving jobs from the orchestrator node, Roma.
* '''Role''': Headless GPU Compute Server
* [cite_start]'''Hardware''': HP Z620 Workstation [cite: 1109]
* [cite_start]'''Operating System''': Ubuntu 24.04.3 LTS [cite: 1109]
* [cite_start]'''CPU''': 6-Core / 12-Thread Intel Xeon E5-2630 v2 @ 2.60GHz [cite: 1113]
* [cite_start]'''GPU''': NVIDIA GeForce RTX 5060 Ti with 16 GB VRAM [cite: 1165, 1167]
* [cite_start]'''Memory''': 32 GB [cite: 1110]
* [cite_start]'''Storage''': 1 TB Micron SSD, configured with a 100 GB LVM partition for the OS and ~850 GB of unallocated space for data volumes. [cite: 1131, 1170]

=== [[Roma]] ===
The central orchestrator of the pipeline. Roma is responsible for managing the workflow, scheduling tasks, and dispatching compute-intensive jobs to Horreum.
* '''Role''': Orchestration & CPU Processing
* [cite_start]'''Hardware''': Custom build with AMD A10-7700K APU [cite: 11]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 7]
* [cite_start]'''CPU''': 4-Core AMD A10-7700K @ 3.40GHz [cite: 7, 11]
* [cite_start]'''GPU''': Integrated AMD Radeon R7 Graphics [cite: 8]
* [cite_start]'''Memory''': 8 GB (6.7Gi usable) [cite: 23]
* [cite_start]'''Storage''': 2 TB Hitachi Ultrastar HDD [cite: 31]

=== [[Torta]] ===
A low-power, always-on node that serves as the bastion host and central file hub for the pipeline, managing both raw and processed data.
* '''Role''': Bastion Host & Centralized File Storage
* [cite_start]'''Hardware''': Raspberry Pi 4 Model B [cite: 767]
* [cite_start]'''Operating System''': Debian GNU/Linux 12 (bookworm) [cite: 766]
* [cite_start]'''CPU''': 4-Core ARM Cortex-A72 @ 1.80GHz [cite: 767]
* [cite_start]'''Memory''': 8 GB [cite: 767]
* '''Storage''': 32 GB SD Card for OS; [cite_start]Two external HDDs (1.8 TB and 698 GB) for data storage [cite: 782, 783]

=== [[Latium]] ===
The public-facing cloud node responsible for interacting with external APIs and services. It handles the initial data collection and the final data publication.
* '''Role''': API Scraping & Data Uploading
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1865]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1865]
* [cite_start]'''CPU''': 1-Core DO-Regular CPU [cite: 1866]
* [cite_start]'''Memory''': 2 GB [cite: 1866]
* [cite_start]'''Storage''': 50 GB SSD [cite: 1889]

=== [[OodaWiki]] ===
A cloud-based server hosting the MediaWiki instance that serves as the final destination and presentation layer for the processed data.
* '''Role''': Final Data Presentation Layer
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1001]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1001]
* [cite_start]'''CPU''': 2-Core DO-Regular CPU [cite: 1001]
* [cite_start]'''Memory''': 4 GB [cite: 1002]
* [cite_start]'''Storage''': 80 GB SSD [cite: 1024]
* [cite_start]'''Services''': MediaWiki running on PHP 8.1 [cite: 1081][cite_start], Redis [cite: 1068][cite_start], MySQL [cite: 1072][cite_start], Nginx [cite: 1077]

== Network Architecture ==
The Imperium network is divided into a private local network and a secure cloud-to-local tunnel, establishing the "Pomerium" boundary.

=== Local Network (Pomerium) ===
The core local servers operate on a subnet with static IP addresses assigned by the router.

File sharing between these nodes will be handled by a Network File System (NFS) hosted on '''Torta'''.

=== Secure VPN Tunnel (Aquaeductus) ===
A point-to-point WireGuard VPN provides a secure, encrypted tunnel between the public cloud and the private local network.
* '''Purpose''': Allows `aqua_datum` (raw data) to be transferred securely from '''Latium''' to '''Torta'''.
* '''Endpoint''': The tunnel's public endpoint is the home network's public IP, with UDP port forwarded to '''Torta'''.

== Data Pipeline Workflow ==
The pipeline operates in a continuous, automated loop orchestrated primarily by '''Roma'''.

# '''Data Collection (Castra)''': A scheduled script or containerized agent on '''Latium''' queries an external API. The raw data (`aqua_datum`) is collected.
# '''Secure Transport (Aquaeductus)''': The `Salii` system on '''Latium''' transfers the `aqua_datum` through the secure WireGuard tunnel to the first external hard drive on '''Torta'''.
# '''Processing Dispatch''': A script on '''Roma''' continuously monitors the raw data drive on '''Torta'''. When new `aqua_datum` is detected, it initiates the processing phase.
# '''Compute & Processing''': '''Roma''' handles standard data parsing. For tasks requiring significant parallel processing, '''Roma''' dispatches the job to '''Horreum'''. Both nodes work with data stored on '''Torta''' via NFS. Processed data (`grana_datum`) is written to the second external hard drive on '''Torta'''.
# '''Data Publication''': The `Cubile` system, containing the pywikibots, runs on '''Latium''' inside the secure Pomerium zone. It accesses the `grana_datum` from '''Torta''' and uses it to update the '''OodaWiki''' server.

Horreum (disambiguation)

2025-10-10T15:49:22Z

AdminIsidore:

{{wiktionary|Horreum|horreum}}
'''[[Horreum]]''' was a type of public warehouse used during the [[Ancient Rome|ancient Roman]] period. Although the [[Latin language|Latin]] term is often used to refer to [[granary|granaries]]. By the end of the imperial period, the city of Rome had nearly 300 ''horrea'' to supply its demands.

'''Horreum''' may also refer to:

{{TOC right}}

==Collegium==
[[Lingua:Horreum]]
[[Collegium:Horreum]]

Horreum

2025-10-10T15:49:04Z

AdminIsidore:

{{Short description|Public warehouse used during the ancient Roman period}}
{{for|the Collegium|Collegium:Horreum}}

A '''''horreum''''' (plural: ''horrea'') was a type of public warehouse used during the [[Ancient Rome|ancient Roman]] period. Although the [[Latin language|Latin]] term is often used to refer to [[granary|granaries]]. By the end of the imperial period, the city of Rome had nearly 300 ''horrea'' to supply its demands.<ref>Peter Lampe, ''Christians at Rome in the First Two Centuries: From Paul to Valentinus'', p. 61. Continuum International Publishing Group, 2006. {{ISBN|0-8264-8102-7}}</ref> The biggest were enormous, even by modern standards; the Horrea Galbae contained 140 rooms on the ground floor alone, covering an area of some 225,000 square feet (21,000 m2).<ref name="Potter">David Stone Potter, D. J. Mattingly, ''Life, Death, and Entertainment in the Roman Empire'', p. 180. University of Michigan Press, 1999. {{ISBN|0-472-08568-9}}</ref> They provided storage for not only the annona publica (public grain supply) but also a great variety of resources like olive oil and foodstuffs.<ref>{{cite book |last1=Richardson |title=A New Topographical Dictionary of Ancient Rome |date=1992 |publisher=Johns Hopkins University Press |pages=193}}</ref> The amount of storage space available in the public ''horrea'' can be judged by the fact that when the emperor [[Septimius Severus]] died in 211 AD, he is said to have left the city's ''horrea'' stocked with enough food to supply Rome's million-strong population for seven years.<ref name="Métreaux">Guy P.R. Métreaux, "Villa rustica alimentaria et annonaria", in ''The Roman Villa: Villa Urbana'', ed. Alfred Frazer, p[. 14-15. University of Pennsylvania Museum of Archaeology, 1998. {{ISBN|0-924171-59-6}}</ref> Smaller (though similar) ''horrea'' were a standard feature of Roman towns, cities and forts throughout the empire; well-preserved examples of military ''horrea'' have been excavated on [[Hadrian's Wall]] in [[England]], notably at the forts of [[Housesteads]], [[Corbridge]] and [[South Shields]].<ref>David Soren, ''A Roman Villa and a Late Roman Infant Cemetery'', p. 209. L'Erma di Bretschneider, 1999. {{ISBN|88-7062-989-9}}</ref>

==History==
The first ''horrea'' were built in Rome towards the end of the 2nd century BC,<ref name="Patrich">Joseph Patrich, "Warehouses and Granaries in Caesarea Maritima", in ''Caesarea Maritima: A Retrospective After Two Millennia'', p. 149. BRILL, 1996. {{ISBN|90-04-10378-3}}</ref> with the first known public ''horreum'' being constructed by the ill-fated [[tribune]] [[Gaius Gracchus]] in 123 BC.<ref name="Métreaux" /> The word came to be applied any place designated for the preservation of goods; thus it was often used to refer to cellars (''horrea subterranea''), but it could also be applied to a place where artworks were stored,<ref>[[Pliny the Younger|Pliny]], Epist. VIII.18</ref> or even to a library.<ref>[[Seneca the Younger|Seneca]], Epist. 45</ref> Some public horrea functioned somewhat like banks, where valuables could be stored, but the most important class of ''horrea'' were those where foodstuffs such as grain and olive oil were stored and distributed by the state.<ref>William Smith, ''[https://penelope.uchicago.edu/Thayer/E/Roman/Texts/secondary/SMIGRA*/Horreum.html A Dictionary of Greek and Roman Antiquities]'', p. 618. John Murray, London, 1875.</ref> Rome's insatiable demands for foodstuffs meant that the amount of goods that passed through some of the city's horrea was immense, even by modern standards. The artificial hill of [[Monte Testaccio]] in Rome, which stands behind the site of the Horrea Galbae, is estimated to contain the remains of at least 53 million olive oil amphorae in which some 6 billion litres (1.58 billion gallons) of oil were imported.<ref name="Ward-Perkins">Bryan Ward-Perkins, ''The Fall of Rome: And the End of Civilization'', pp. 91-92. Oxford University Press, 2005. {{ISBN|0-19-280728-5}}.</ref>

==Design and naming==
[[File:Ostia, horrea epagathiana 01.JPG|thumb|The Horrea Epagathiana et Epaphroditiana, a ''horreum'' in Ostia built c. 145–150 AD]]

The ''horrea'' of Rome and its port, [[Ostia Antica|Ostia]], stood two or more stories high. They were built with ramps, rather than staircases, to provide easy access to the upper floors. Grain horrea had their ground floor raised on pillars to reduce the likelihood of damp getting in and spoiling the goods. Many ''horrea'' appear to have served as great trading areas with rows of small shops (''[[taberna]]e'') off a central courtyard; some may have been fairly elaborate, perhaps serving as the equivalent of modern shopping arcades. Others, such as those in Ostia, dispensed with the courtyard and instead had rows of ''tabernae'' standing back-to-back. In the [[Middle East]], horrea took a very different design with a single row of very deep ''tabernae'', all opening onto the same side; this reflected an architectural style that was widely followed in the region's palaces and temple complexes, well before the arrival of the Romans.<ref name="Patrich" /><ref name="Claridge">Claridge, Amanda (1998). ''[https://books.google.com/books?id=xtoVDAAAQBAJ&q=%22Horreum+OR+Horrea%22 Rome: An Oxford Archaeological Guide]'', First, Oxford, UK: Oxford University Press, 1998, p. 55. {{ISBN|0-19-288003-9}}</ref>

Unsurprisingly, security and fire protection were major concerns. ''Horrea'' were frequently built with very thick walls (as much as {{convert|1|m|ft|0}} thick) to reduce the danger of fire, and the windows were always narrow and placed high up on the wall to deter theft. Doors were protected with elaborate systems of locks and bolts. Even the largest ''horrea'' usually only had two or three external doors, which were often quite narrow and would not have permitted the entrance of carts. The arduous task of moving goods into, out of and around ''horrea'' was most probably carried out by manual labour alone; the biggest ''horrea'' would thus have had an enormous staff of labourers.<ref name="Potter" />

Roman ''horrea'' were individually named, some having names indicating the commodities they stored (and probably sold), such as [[wax]] (''candelaria''), [[paper]] (''chartaria'') and [[Black pepper|pepper]] (''piperataria''). Others were named after emperors or other individuals connected with the imperial family, such as the aforementioned Horrea Galbae, which were apparently named after the 1st century AD emperor [[Galba]].<ref name="Claridge" /> A particularly well-preserved ''horreum'' in Ostia, the Horrea Epagathiana et Epaphroditiana, is known from an inscription to have been named after two [[freedmen]] (presumably its owners), Epagathus and Epaphroditus.<ref>[http://www.ostia-antica.org/regio1/8/8-3.htm Regio I - Insula VIII - Horrea Epagathiana et Epaphroditiana]</ref>

==References==
{{reflist}}

==Bibliography==
* RICKMAN, G., (1971): Roman Granaries and store buildings. Cambridge.
* SALIDO DOMINGUEZ, J., (2011): Horrea Militaria. El aprovisionamiento de grano al ejército en el occidente del Imperio romano, Anejos de Gladius 14, Madrid.
* SALIDO DOMINGUEZ, J., (2009): “Los graneros militares romanos de Hispania”. En MORILLO, A., HANEL, N. & MARTÍN, E., (eds.): Limes XX. Estudios sobre la Frontera Romana. Anejos de Gladius 13. Volumen 2. Madrid, 679-692. I.S.B.N. 978-84-00-08856-9.
* SALIDO DOMINGUEZ, J., (2008): “La investigación sobre los horrea de época romana: balance historiográfico y perspectivas de futuro”. CUPAUAM 34, 105-124. I.S.B.N. 978-84-00-08856-9 https://www.uam.es/otros/cupauam/pdf/Cupauam34/3405.pdf
* SALIDO DOMINGUEZ, J., (2008b): “Los sistemas de almacenamiento y conservación de grano en las villae hispanorromanas”. En FERNÁNDEZ OCHOA, C., GARCÍA-ENTERO, V. & GIL SENDINO, F., (eds.): Las villae tardorromanas en el Occidente del Imperio. Arquitectura y función. IV Coloquio Internacional de Arqueología de Gijón. 26, 27 y 28 de Octubre de 2006, Gijón, 693-706. I.S.B.N.: 978-84-9704-363-2.

==External links==
* [http://www.ostia-antica.org/regio1/8/8-3.htm Regio I - Insula VIII - Horrea Epagathiana et Epaphroditiana] - plans and images of an excavated horreum at Ostia Antica
* {{YouTube|7nGZWh-8EoE|Computer reconstruction of the ''horreum'' at Longovicium|}}

[[Category:Ancient Roman architecture]]

Collegium:Terra

2025-10-10T15:48:53Z

AdminIsidore: /* Horreum */

{{DISPLAYTITLE:Imperium System Architecture}}
{{italic title}}
'''Imperium''' is a distributed, multi-node data processing pipeline designed to automate the collection, processing, and publication of data. The system is composed of several specialized hardware nodes, each with a distinct role, orchestrated to work in concert. This document outlines the foundational architecture as of September 23, 2025.

== Core Infrastructure Nodes ==
The Imperium pipeline is built upon five primary local and cloud-based servers, each with a unique specialization.

=== [[Horreum|Collegium:Horreum]] ===
Serves as the primary high-performance compute node, specializing in GPU-intensive tasks. It operates as a headless server, receiving jobs from the orchestrator node, Roma.
* '''Role''': Headless GPU Compute Server
* [cite_start]'''Hardware''': HP Z620 Workstation [cite: 1109]
* [cite_start]'''Operating System''': Ubuntu 24.04.3 LTS [cite: 1109]
* [cite_start]'''CPU''': 6-Core / 12-Thread Intel Xeon E5-2630 v2 @ 2.60GHz [cite: 1113]
* [cite_start]'''GPU''': NVIDIA GeForce RTX 5060 Ti with 16 GB VRAM [cite: 1165, 1167]
* [cite_start]'''Memory''': 32 GB [cite: 1110]
* [cite_start]'''Storage''': 1 TB Micron SSD, configured with a 100 GB LVM partition for the OS and ~850 GB of unallocated space for data volumes. [cite: 1131, 1170]

=== [[Roma]] ===
The central orchestrator of the pipeline. Roma is responsible for managing the workflow, scheduling tasks, and dispatching compute-intensive jobs to Horreum.
* '''Role''': Orchestration & CPU Processing
* [cite_start]'''Hardware''': Custom build with AMD A10-7700K APU [cite: 11]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 7]
* [cite_start]'''CPU''': 4-Core AMD A10-7700K @ 3.40GHz [cite: 7, 11]
* [cite_start]'''GPU''': Integrated AMD Radeon R7 Graphics [cite: 8]
* [cite_start]'''Memory''': 8 GB (6.7Gi usable) [cite: 23]
* [cite_start]'''Storage''': 2 TB Hitachi Ultrastar HDD [cite: 31]

=== [[Torta]] ===
A low-power, always-on node that serves as the bastion host and central file hub for the pipeline, managing both raw and processed data.
* '''Role''': Bastion Host & Centralized File Storage
* [cite_start]'''Hardware''': Raspberry Pi 4 Model B [cite: 767]
* [cite_start]'''Operating System''': Debian GNU/Linux 12 (bookworm) [cite: 766]
* [cite_start]'''CPU''': 4-Core ARM Cortex-A72 @ 1.80GHz [cite: 767]
* [cite_start]'''Memory''': 8 GB [cite: 767]
* '''Storage''': 32 GB SD Card for OS; [cite_start]Two external HDDs (1.8 TB and 698 GB) for data storage [cite: 782, 783]

=== [[Latium]] ===
The public-facing cloud node responsible for interacting with external APIs and services. It handles the initial data collection and the final data publication.
* '''Role''': API Scraping & Data Uploading
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1865]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1865]
* [cite_start]'''CPU''': 1-Core DO-Regular CPU [cite: 1866]
* [cite_start]'''Memory''': 2 GB [cite: 1866]
* [cite_start]'''Storage''': 50 GB SSD [cite: 1889]

=== [[OodaWiki]] ===
A cloud-based server hosting the MediaWiki instance that serves as the final destination and presentation layer for the processed data.
* '''Role''': Final Data Presentation Layer
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1001]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1001]
* [cite_start]'''CPU''': 2-Core DO-Regular CPU [cite: 1001]
* [cite_start]'''Memory''': 4 GB [cite: 1002]
* [cite_start]'''Storage''': 80 GB SSD [cite: 1024]
* [cite_start]'''Services''': MediaWiki running on PHP 8.1 [cite: 1081][cite_start], Redis [cite: 1068][cite_start], MySQL [cite: 1072][cite_start], Nginx [cite: 1077]

== Network Architecture ==
The Imperium network is divided into a private local network and a secure cloud-to-local tunnel, establishing the "Pomerium" boundary.

=== Local Network (Pomerium) ===
The core local servers operate on a subnet with static IP addresses assigned by the router.

File sharing between these nodes will be handled by a Network File System (NFS) hosted on '''Torta'''.

=== Secure VPN Tunnel (Aquaeductus) ===
A point-to-point WireGuard VPN provides a secure, encrypted tunnel between the public cloud and the private local network.
* '''Purpose''': Allows `aqua_datum` (raw data) to be transferred securely from '''Latium''' to '''Torta'''.
* '''Endpoint''': The tunnel's public endpoint is the home network's public IP, with UDP port forwarded to '''Torta'''.

== Data Pipeline Workflow ==
The pipeline operates in a continuous, automated loop orchestrated primarily by '''Roma'''.

# '''Data Collection (Castra)''': A scheduled script or containerized agent on '''Latium''' queries an external API. The raw data (`aqua_datum`) is collected.
# '''Secure Transport (Aquaeductus)''': The `Salii` system on '''Latium''' transfers the `aqua_datum` through the secure WireGuard tunnel to the first external hard drive on '''Torta'''.
# '''Processing Dispatch''': A script on '''Roma''' continuously monitors the raw data drive on '''Torta'''. When new `aqua_datum` is detected, it initiates the processing phase.
# '''Compute & Processing''': '''Roma''' handles standard data parsing. For tasks requiring significant parallel processing, '''Roma''' dispatches the job to '''Horreum'''. Both nodes work with data stored on '''Torta''' via NFS. Processed data (`grana_datum`) is written to the second external hard drive on '''Torta'''.
# '''Data Publication''': The `Cubile` system, containing the pywikibots, runs on '''Latium''' inside the secure Pomerium zone. It accesses the `grana_datum` from '''Torta''' and uses it to update the '''OodaWiki''' server.

Horreum

2025-10-10T15:48:04Z

AdminIsidore: Removed redirect to Horreum (disambiguation)

{{Short description|Public warehouse used during the ancient Roman period}}
{{for|the Collegium|Collegium: Horreum}}

A '''''horreum''''' (plural: ''horrea'') was a type of public warehouse used during the [[Ancient Rome|ancient Roman]] period. Although the [[Latin language|Latin]] term is often used to refer to [[granary|granaries]]. By the end of the imperial period, the city of Rome had nearly 300 ''horrea'' to supply its demands.<ref>Peter Lampe, ''Christians at Rome in the First Two Centuries: From Paul to Valentinus'', p. 61. Continuum International Publishing Group, 2006. {{ISBN|0-8264-8102-7}}</ref> The biggest were enormous, even by modern standards; the Horrea Galbae contained 140 rooms on the ground floor alone, covering an area of some 225,000 square feet (21,000 m2).<ref name="Potter">David Stone Potter, D. J. Mattingly, ''Life, Death, and Entertainment in the Roman Empire'', p. 180. University of Michigan Press, 1999. {{ISBN|0-472-08568-9}}</ref> They provided storage for not only the annona publica (public grain supply) but also a great variety of resources like olive oil and foodstuffs.<ref>{{cite book |last1=Richardson |title=A New Topographical Dictionary of Ancient Rome |date=1992 |publisher=Johns Hopkins University Press |pages=193}}</ref> The amount of storage space available in the public ''horrea'' can be judged by the fact that when the emperor [[Septimius Severus]] died in 211 AD, he is said to have left the city's ''horrea'' stocked with enough food to supply Rome's million-strong population for seven years.<ref name="Métreaux">Guy P.R. Métreaux, "Villa rustica alimentaria et annonaria", in ''The Roman Villa: Villa Urbana'', ed. Alfred Frazer, p[. 14-15. University of Pennsylvania Museum of Archaeology, 1998. {{ISBN|0-924171-59-6}}</ref> Smaller (though similar) ''horrea'' were a standard feature of Roman towns, cities and forts throughout the empire; well-preserved examples of military ''horrea'' have been excavated on [[Hadrian's Wall]] in [[England]], notably at the forts of [[Housesteads]], [[Corbridge]] and [[South Shields]].<ref>David Soren, ''A Roman Villa and a Late Roman Infant Cemetery'', p. 209. L'Erma di Bretschneider, 1999. {{ISBN|88-7062-989-9}}</ref>

==History==
The first ''horrea'' were built in Rome towards the end of the 2nd century BC,<ref name="Patrich">Joseph Patrich, "Warehouses and Granaries in Caesarea Maritima", in ''Caesarea Maritima: A Retrospective After Two Millennia'', p. 149. BRILL, 1996. {{ISBN|90-04-10378-3}}</ref> with the first known public ''horreum'' being constructed by the ill-fated [[tribune]] [[Gaius Gracchus]] in 123 BC.<ref name="Métreaux" /> The word came to be applied any place designated for the preservation of goods; thus it was often used to refer to cellars (''horrea subterranea''), but it could also be applied to a place where artworks were stored,<ref>[[Pliny the Younger|Pliny]], Epist. VIII.18</ref> or even to a library.<ref>[[Seneca the Younger|Seneca]], Epist. 45</ref> Some public horrea functioned somewhat like banks, where valuables could be stored, but the most important class of ''horrea'' were those where foodstuffs such as grain and olive oil were stored and distributed by the state.<ref>William Smith, ''[https://penelope.uchicago.edu/Thayer/E/Roman/Texts/secondary/SMIGRA*/Horreum.html A Dictionary of Greek and Roman Antiquities]'', p. 618. John Murray, London, 1875.</ref> Rome's insatiable demands for foodstuffs meant that the amount of goods that passed through some of the city's horrea was immense, even by modern standards. The artificial hill of [[Monte Testaccio]] in Rome, which stands behind the site of the Horrea Galbae, is estimated to contain the remains of at least 53 million olive oil amphorae in which some 6 billion litres (1.58 billion gallons) of oil were imported.<ref name="Ward-Perkins">Bryan Ward-Perkins, ''The Fall of Rome: And the End of Civilization'', pp. 91-92. Oxford University Press, 2005. {{ISBN|0-19-280728-5}}.</ref>

==Design and naming==
[[File:Ostia, horrea epagathiana 01.JPG|thumb|The Horrea Epagathiana et Epaphroditiana, a ''horreum'' in Ostia built c. 145–150 AD]]

The ''horrea'' of Rome and its port, [[Ostia Antica|Ostia]], stood two or more stories high. They were built with ramps, rather than staircases, to provide easy access to the upper floors. Grain horrea had their ground floor raised on pillars to reduce the likelihood of damp getting in and spoiling the goods. Many ''horrea'' appear to have served as great trading areas with rows of small shops (''[[taberna]]e'') off a central courtyard; some may have been fairly elaborate, perhaps serving as the equivalent of modern shopping arcades. Others, such as those in Ostia, dispensed with the courtyard and instead had rows of ''tabernae'' standing back-to-back. In the [[Middle East]], horrea took a very different design with a single row of very deep ''tabernae'', all opening onto the same side; this reflected an architectural style that was widely followed in the region's palaces and temple complexes, well before the arrival of the Romans.<ref name="Patrich" /><ref name="Claridge">Claridge, Amanda (1998). ''[https://books.google.com/books?id=xtoVDAAAQBAJ&q=%22Horreum+OR+Horrea%22 Rome: An Oxford Archaeological Guide]'', First, Oxford, UK: Oxford University Press, 1998, p. 55. {{ISBN|0-19-288003-9}}</ref>

Unsurprisingly, security and fire protection were major concerns. ''Horrea'' were frequently built with very thick walls (as much as {{convert|1|m|ft|0}} thick) to reduce the danger of fire, and the windows were always narrow and placed high up on the wall to deter theft. Doors were protected with elaborate systems of locks and bolts. Even the largest ''horrea'' usually only had two or three external doors, which were often quite narrow and would not have permitted the entrance of carts. The arduous task of moving goods into, out of and around ''horrea'' was most probably carried out by manual labour alone; the biggest ''horrea'' would thus have had an enormous staff of labourers.<ref name="Potter" />

Roman ''horrea'' were individually named, some having names indicating the commodities they stored (and probably sold), such as [[wax]] (''candelaria''), [[paper]] (''chartaria'') and [[Black pepper|pepper]] (''piperataria''). Others were named after emperors or other individuals connected with the imperial family, such as the aforementioned Horrea Galbae, which were apparently named after the 1st century AD emperor [[Galba]].<ref name="Claridge" /> A particularly well-preserved ''horreum'' in Ostia, the Horrea Epagathiana et Epaphroditiana, is known from an inscription to have been named after two [[freedmen]] (presumably its owners), Epagathus and Epaphroditus.<ref>[http://www.ostia-antica.org/regio1/8/8-3.htm Regio I - Insula VIII - Horrea Epagathiana et Epaphroditiana]</ref>

==References==
{{reflist}}

==Bibliography==
* RICKMAN, G., (1971): Roman Granaries and store buildings. Cambridge.
* SALIDO DOMINGUEZ, J., (2011): Horrea Militaria. El aprovisionamiento de grano al ejército en el occidente del Imperio romano, Anejos de Gladius 14, Madrid.
* SALIDO DOMINGUEZ, J., (2009): “Los graneros militares romanos de Hispania”. En MORILLO, A., HANEL, N. & MARTÍN, E., (eds.): Limes XX. Estudios sobre la Frontera Romana. Anejos de Gladius 13. Volumen 2. Madrid, 679-692. I.S.B.N. 978-84-00-08856-9.
* SALIDO DOMINGUEZ, J., (2008): “La investigación sobre los horrea de época romana: balance historiográfico y perspectivas de futuro”. CUPAUAM 34, 105-124. I.S.B.N. 978-84-00-08856-9 https://www.uam.es/otros/cupauam/pdf/Cupauam34/3405.pdf
* SALIDO DOMINGUEZ, J., (2008b): “Los sistemas de almacenamiento y conservación de grano en las villae hispanorromanas”. En FERNÁNDEZ OCHOA, C., GARCÍA-ENTERO, V. & GIL SENDINO, F., (eds.): Las villae tardorromanas en el Occidente del Imperio. Arquitectura y función. IV Coloquio Internacional de Arqueología de Gijón. 26, 27 y 28 de Octubre de 2006, Gijón, 693-706. I.S.B.N.: 978-84-9704-363-2.

==External links==
* [http://www.ostia-antica.org/regio1/8/8-3.htm Regio I - Insula VIII - Horrea Epagathiana et Epaphroditiana] - plans and images of an excavated horreum at Ostia Antica
* {{YouTube|7nGZWh-8EoE|Computer reconstruction of the ''horreum'' at Longovicium|}}

[[Category:Ancient Roman architecture]]

Horreum (disambiguation)

2025-10-10T15:46:32Z

AdminIsidore: Created page with "{{wiktionary|Horreum|horreum}} '''Horreum''' was a type of public warehouse used during the ancient Roman period. Although the Latin term is often used to refer to granaries. By the end of the imperial period, the city of Rome had nearly 300 ''horrea'' to supply its demands. '''Horreum''' may also refer to: {{TOC right}} ==Collegium== Lingua: Horreum Collegium: Horreum"

Horreum

2025-10-10T15:43:08Z

AdminIsidore: Redirected page to Horreum (disambiguation)

#REDIRECT [[Horreum_(disambiguation)]]

Collegium:Imperium System

2025-10-09T16:08:21Z

AdminIsidore: /* Mission Plan */

{{DISPLAYTITLE:Collegium:Imperium System}}
'''Imperium System Mission Plan'''

== Overview ==
The Imperium System Mission Plan outlines the phased construction and testing of the Imperium, a distributed data processing pipeline. Each mission is executed in a separate thread using OODA (Observe, Orient, Decide, Act) loops, with completion validated via independent tests. The plan adheres to the Lingua standard, using Latin nomenclature (e.g., ''aqua_datum'', ''grana_datum'', ''pomerium'', ''flamen_martialis'') to ensure script interoperability and support quarterly redundancy audits for AI training.

== Mission Plan ==

The following table details the 14 missions, each with tools, dependencies, and objectives to build a unified, secure, and efficient system.

{| class="wikitable sortable"
! Mission
! Description
! Tools/Dependencies
! Objectives
! Status
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| Configure NFS mounts to unify ''Roma'', ''Horreum'', and ''Torta'' (smaller HDD, ~698 GB) as a single logical system within ''Pomerium'', enabling seamless file sharing for scripts and ''grana_datum''. Ensures no race conditions and supports the "single machine" goal.
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
| Completed
|-
| '''NFS-Plus GPU Dispatching'''
| Extend NFS setup to enable ''Roma'' or ''Torta'' scripts to dispatch GPU-intensive tasks (e.g., AI processing) to ''Horreum''’s NVIDIA RTX 5060 Ti, preserving energy efficiency. Builds on NFS for unified data access.
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
| Pending
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| Set up Docker containers (''Pomerium'', ''Campus Martius'', ''Flamen Martialis'') on ''Latium'' and minimal directory structure on ''Torta'' (e.g., ''/mnt/lacus'', ''/mnt/aquaeductus'') for pipeline operations. Simplifies ''Torta'' by keeping it Docker-free.
| Docker, ''.bashrc'' modifications, directory scripts
| Functional containers and directories, tested by mock commands in each context
| Pending
|-
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
| Configure ''Torta''’s external HDDs (larger ~1.8 TB for ''lacus'', smaller ~698 GB for ''aquaeductus'') with NFS, integrating ''Latium''’s ''Pomerium'' Docker into the internal NFS network. Ensures secure data flow from external to internal zones.
| NFS, WireGuard, ''ufw''
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
| Pending
|-
| '''Flamen Martialis and Salii Separation'''
| Implement ''Flamen Martialis'' in ''Latium''’s ''Campus Martius'' Docker for external data collection/sanitation, with ''Salii'' on ''Roma'' for internal processing, reducing ''Latium''’s role and vulnerabilities. Ensures ''Salii'' is air-gapped, using ''Horreum''’s GPU.
| Python, NFS, SSH
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
| Pending
|-
| '''Simple Data Diodes'''
| Establish a one-way data flow from ''Latium'' to ''Torta'' (''Campus Martius'' to ''Pomerium'') to prevent reverse communication, mitigating security risks. Focuses on lightweight, secure transfer protocols.
| RSYNC, ''ufw'', WireGuard
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
| Pending
|-
| '''RSYNC Optimization'''
| Optimize RSYNC for fast, secure one-way data transfers over WireGuard, replacing SCP to avoid bottlenecks in pipelines like NOTAM. Tunes MTU and compression for performance.
| RSYNC, WireGuard, cron
| Transfer mock JSON files in <1s, tested by comparing transfer times
| Pending
|-
| '''Tar + Netcat (nc) Implementation'''
| Implement tar + nc for burst/large dataset transfers, comparing with RSYNC to determine the best tool per task (e.g., NOTAM vs. musica). Establishes a decision process for tool selection.
| Tar, Netcat, WireGuard
| Functional burst transfer with a decision matrix, tested with mock data
| Pending
|-
| '''Firejail/Bubblewrap Sandboxing'''
| Deploy Firejail (or Bubblewrap) on ''Latium'' to sandbox ''Flamen Martialis'' scripts, ensuring secure processing of external ''aqua_datum''. Avoids heavy Firecracker setup.
| Firejail, Python
| Sandboxed mock script with restricted access, tested via confinement checks
| Pending
|-
| '''Supabase Integration'''
| Integrate Supabase as a filtering buffer for ''aqua_datum'', using RLS and edge functions to validate data before transfer to ''Torta'' or ''Roma''. Enhances security and supports prototypes.
| Supabase client libraries, REST API, WireGuard
| Validated data push/pull, tested with a mock schema
| Pending
|-
| '''JSONPlaceholder Data Pipeline Test'''
| Test the full pipeline using JSONPlaceholder’s mock API, simulating data flow from ''Latium'' to ''Torta'' to ''Roma''/''OodaWiki''. Validates end-to-end setup.
| Python, RSYNC/nc, NFS, pywikibots
| Complete data cycle, tested by verifying output on ''OodaWiki''
| Pending
|-
| '''NOTAM Data Pipeline Test'''
| Test the pipeline with NOTAM API data, focusing on scheduled pulls and performance. Ensures reliable handling of time-sensitive data.
| Python, Supabase (optional), RSYNC/nc, NFS
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
| Pending
|-
| '''RapidAPI via Supabase Test'''
| Test a basic RapidAPI endpoint via Supabase for filtering, integrating with the pipeline to store/publish results. Validates external API handling.
| Supabase, Python, RSYNC/nc, pywikibots
| API-to-Wiki flow, tested by published data on ''OodaWiki''
| Pending
|-
| '''Automation/Standardized Deployment Script'''
| Develop a CLI script to automate directory and tool setup for new projects (e.g., musica, NOTAM) across Imperium, using test lessons. Ensures consistent, customizable deployments.
| Bash/Python, Docker, NFS, Supabase
| Script for project setup with one command, tested by deploying a mock project
| Pending
|}

== Execution Plan ==
Each mission will be executed in a dedicated thread using OODA loops:
* '''Observe''': Assess current system state (e.g., installed packages, configurations).
* '''Orient''': Plan configurations and identify dependencies.
* '''Decide''': Select specific tools and parameters.
* '''Act''': Implement and test the setup.
Upon thread completion, results are reported to the main strategic thread, where an independent test (e.g., file access, data transfer, script execution) confirms success. Successful missions are closed, and the next thread is initiated. The main thread tracks progress, ensuring coherence with the Imperium’s Lingua conventions and strategic goals.

== Notes ==
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
* Mission 1 (NFS Setup) was completed with fixed port configurations for NFS services and verified through multi-node file creation, concurrent writes, and cleanup tests, establishing unified access in Pomerium.

Collegium:Imperium System

2025-10-09T16:06:49Z

AdminIsidore: /* Mission Plan */

{{DISPLAYTITLE:Collegium:Imperium System}}
'''Imperium System Mission Plan'''

== Overview ==
The Imperium System Mission Plan outlines the phased construction and testing of the Imperium, a distributed data processing pipeline. Each mission is executed in a separate thread using OODA (Observe, Orient, Decide, Act) loops, with completion validated via independent tests. The plan adheres to the Lingua standard, using Latin nomenclature (e.g., ''aqua_datum'', ''grana_datum'', ''pomerium'', ''flamen_martialis'') to ensure script interoperability and support quarterly redundancy audits for AI training.

== Mission Plan ==

The following table details the 14 missions, each with tools, dependencies, and objectives to build a unified, secure, and efficient system.

{| class="wikitable sortable"
! Mission
! Description
! Tools/Dependencies
! Objectives
! Status
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| Configure NFS mounts to unify ''Roma'', ''Horreum'', and ''Torta'' (smaller HDD, ~698 GB) as a single logical system within ''Pomerium'', enabling seamless file sharing for scripts and ''grana_datum''. Ensures no race conditions and supports the "single machine" goal.
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
| Completed (October 09, 2025)
|-
| '''NFS-Plus GPU Dispatching'''
| Extend NFS setup to enable ''Roma'' or ''Torta'' scripts to dispatch GPU-intensive tasks (e.g., AI processing) to ''Horreum''’s NVIDIA RTX 5060 Ti, preserving energy efficiency. Builds on NFS for unified data access.
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| Set up Docker containers (''Pomerium'', ''Campus Martius'', ''Flamen Martialis'') on ''Latium'' and minimal directory structure on ''Torta'' (e.g., ''/mnt/lacus'', ''/mnt/aquaeductus'') for pipeline operations. Simplifies ''Torta'' by keeping it Docker-free.
| Docker, ''.bashrc'' modifications, directory scripts
| Functional containers and directories, tested by mock commands in each context
|-
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
| Configure ''Torta''’s external HDDs (larger ~1.8 TB for ''lacus'', smaller ~698 GB for ''aquaeductus'') with NFS, integrating ''Latium''’s ''Pomerium'' Docker into the internal NFS network. Ensures secure data flow from external to internal zones.
| NFS, WireGuard, ''ufw''
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
|-
| '''Flamen Martialis and Salii Separation'''
| Implement ''Flamen Martialis'' in ''Latium''’s ''Campus Martius'' Docker for external data collection/sanitation, with ''Salii'' on ''Roma'' for internal processing, reducing ''Latium''’s role and vulnerabilities. Ensures ''Salii'' is air-gapped, using ''Horreum''’s GPU.
| Python, NFS, SSH
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
|-
| '''Simple Data Diodes'''
| Establish a one-way data flow from ''Latium'' to ''Torta'' (''Campus Martius'' to ''Pomerium'') to prevent reverse communication, mitigating security risks. Focuses on lightweight, secure transfer protocols.
| RSYNC, ''ufw'', WireGuard
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
|-
| '''RSYNC Optimization'''
| Optimize RSYNC for fast, secure one-way data transfers over WireGuard, replacing SCP to avoid bottlenecks in pipelines like NOTAM. Tunes MTU and compression for performance.
| RSYNC, WireGuard, cron
| Transfer mock JSON files in <1s, tested by comparing transfer times
|-
| '''Tar + Netcat (nc) Implementation'''
| Implement tar + nc for burst/large dataset transfers, comparing with RSYNC to determine the best tool per task (e.g., NOTAM vs. musica). Establishes a decision process for tool selection.
| Tar, Netcat, WireGuard
| Functional burst transfer with a decision matrix, tested with mock data
|-
| '''Firejail/Bubblewrap Sandboxing'''
| Deploy Firejail (or Bubblewrap) on ''Latium'' to sandbox ''Flamen Martialis'' scripts, ensuring secure processing of external ''aqua_datum''. Avoids heavy Firecracker setup.
| Firejail, Python
| Sandboxed mock script with restricted access, tested via confinement checks
|-
| '''Supabase Integration'''
| Integrate Supabase as a filtering buffer for ''aqua_datum'', using RLS and edge functions to validate data before transfer to ''Torta'' or ''Roma''. Enhances security and supports prototypes.
| Supabase client libraries, REST API, WireGuard
| Validated data push/pull, tested with a mock schema
|-
| '''JSONPlaceholder Data Pipeline Test'''
| Test the full pipeline using JSONPlaceholder’s mock API, simulating data flow from ''Latium'' to ''Torta'' to ''Roma''/''OodaWiki''. Validates end-to-end setup.
| Python, RSYNC/nc, NFS, pywikibots
| Complete data cycle, tested by verifying output on ''OodaWiki''
|-
| '''NOTAM Data Pipeline Test'''
| Test the pipeline with NOTAM API data, focusing on scheduled pulls and performance. Ensures reliable handling of time-sensitive data.
| Python, Supabase (optional), RSYNC/nc, NFS
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
|-
| '''RapidAPI via Supabase Test'''
| Test a basic RapidAPI endpoint via Supabase for filtering, integrating with the pipeline to store/publish results. Validates external API handling.
| Supabase, Python, RSYNC/nc, pywikibots
| API-to-Wiki flow, tested by published data on ''OodaWiki''
|-
| '''Automation/Standardized Deployment Script'''
| Develop a CLI script to automate directory and tool setup for new projects (e.g., musica, NOTAM) across Imperium, using test lessons. Ensures consistent, customizable deployments.
| Bash/Python, Docker, NFS, Supabase
| Script for project setup with one command, tested by deploying a mock project
|}

== Execution Plan ==
Each mission will be executed in a dedicated thread using OODA loops:
* '''Observe''': Assess current system state (e.g., installed packages, configurations).
* '''Orient''': Plan configurations and identify dependencies.
* '''Decide''': Select specific tools and parameters.
* '''Act''': Implement and test the setup.
Upon thread completion, results are reported to the main strategic thread, where an independent test (e.g., file access, data transfer, script execution) confirms success. Successful missions are closed, and the next thread is initiated. The main thread tracks progress, ensuring coherence with the Imperium’s Lingua conventions and strategic goals.

== Notes ==
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
* Mission 1 (NFS Setup) was completed with fixed port configurations for NFS services and verified through multi-node file creation, concurrent writes, and cleanup tests, establishing unified access in Pomerium.

Collegium:Imperium System

2025-10-09T16:06:20Z

AdminIsidore:

{{DISPLAYTITLE:Collegium:Imperium System}}
'''Imperium System Mission Plan'''

== Overview ==
The Imperium System Mission Plan outlines the phased construction and testing of the Imperium, a distributed data processing pipeline. Each mission is executed in a separate thread using OODA (Observe, Orient, Decide, Act) loops, with completion validated via independent tests. The plan adheres to the Lingua standard, using Latin nomenclature (e.g., ''aqua_datum'', ''grana_datum'', ''pomerium'', ''flamen_martialis'') to ensure script interoperability and support quarterly redundancy audits for AI training.

== Mission Plan ==

The following table details the 14 missions, each with tools, dependencies, and objectives to build a unified, secure, and efficient system.

{| class="wikitable sortable"
! Mission
! Description
! Tools/Dependencies
! Objectives
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| Configure NFS mounts to unify ''Roma'', ''Horreum'', and ''Torta'' (smaller HDD, ~698 GB) as a single logical system within ''Pomerium'', enabling seamless file sharing for scripts and ''grana_datum''. Ensures no race conditions and supports the "single machine" goal.
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
| Completed (October 09, 2025)
|-
| '''NFS-Plus GPU Dispatching'''
| Extend NFS setup to enable ''Roma'' or ''Torta'' scripts to dispatch GPU-intensive tasks (e.g., AI processing) to ''Horreum''’s NVIDIA RTX 5060 Ti, preserving energy efficiency. Builds on NFS for unified data access.
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| Set up Docker containers (''Pomerium'', ''Campus Martius'', ''Flamen Martialis'') on ''Latium'' and minimal directory structure on ''Torta'' (e.g., ''/mnt/lacus'', ''/mnt/aquaeductus'') for pipeline operations. Simplifies ''Torta'' by keeping it Docker-free.
| Docker, ''.bashrc'' modifications, directory scripts
| Functional containers and directories, tested by mock commands in each context
|-
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
| Configure ''Torta''’s external HDDs (larger ~1.8 TB for ''lacus'', smaller ~698 GB for ''aquaeductus'') with NFS, integrating ''Latium''’s ''Pomerium'' Docker into the internal NFS network. Ensures secure data flow from external to internal zones.
| NFS, WireGuard, ''ufw''
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
|-
| '''Flamen Martialis and Salii Separation'''
| Implement ''Flamen Martialis'' in ''Latium''’s ''Campus Martius'' Docker for external data collection/sanitation, with ''Salii'' on ''Roma'' for internal processing, reducing ''Latium''’s role and vulnerabilities. Ensures ''Salii'' is air-gapped, using ''Horreum''’s GPU.
| Python, NFS, SSH
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
|-
| '''Simple Data Diodes'''
| Establish a one-way data flow from ''Latium'' to ''Torta'' (''Campus Martius'' to ''Pomerium'') to prevent reverse communication, mitigating security risks. Focuses on lightweight, secure transfer protocols.
| RSYNC, ''ufw'', WireGuard
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
|-
| '''RSYNC Optimization'''
| Optimize RSYNC for fast, secure one-way data transfers over WireGuard, replacing SCP to avoid bottlenecks in pipelines like NOTAM. Tunes MTU and compression for performance.
| RSYNC, WireGuard, cron
| Transfer mock JSON files in <1s, tested by comparing transfer times
|-
| '''Tar + Netcat (nc) Implementation'''
| Implement tar + nc for burst/large dataset transfers, comparing with RSYNC to determine the best tool per task (e.g., NOTAM vs. musica). Establishes a decision process for tool selection.
| Tar, Netcat, WireGuard
| Functional burst transfer with a decision matrix, tested with mock data
|-
| '''Firejail/Bubblewrap Sandboxing'''
| Deploy Firejail (or Bubblewrap) on ''Latium'' to sandbox ''Flamen Martialis'' scripts, ensuring secure processing of external ''aqua_datum''. Avoids heavy Firecracker setup.
| Firejail, Python
| Sandboxed mock script with restricted access, tested via confinement checks
|-
| '''Supabase Integration'''
| Integrate Supabase as a filtering buffer for ''aqua_datum'', using RLS and edge functions to validate data before transfer to ''Torta'' or ''Roma''. Enhances security and supports prototypes.
| Supabase client libraries, REST API, WireGuard
| Validated data push/pull, tested with a mock schema
|-
| '''JSONPlaceholder Data Pipeline Test'''
| Test the full pipeline using JSONPlaceholder’s mock API, simulating data flow from ''Latium'' to ''Torta'' to ''Roma''/''OodaWiki''. Validates end-to-end setup.
| Python, RSYNC/nc, NFS, pywikibots
| Complete data cycle, tested by verifying output on ''OodaWiki''
|-
| '''NOTAM Data Pipeline Test'''
| Test the pipeline with NOTAM API data, focusing on scheduled pulls and performance. Ensures reliable handling of time-sensitive data.
| Python, Supabase (optional), RSYNC/nc, NFS
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
|-
| '''RapidAPI via Supabase Test'''
| Test a basic RapidAPI endpoint via Supabase for filtering, integrating with the pipeline to store/publish results. Validates external API handling.
| Supabase, Python, RSYNC/nc, pywikibots
| API-to-Wiki flow, tested by published data on ''OodaWiki''
|-
| '''Automation/Standardized Deployment Script'''
| Develop a CLI script to automate directory and tool setup for new projects (e.g., musica, NOTAM) across Imperium, using test lessons. Ensures consistent, customizable deployments.
| Bash/Python, Docker, NFS, Supabase
| Script for project setup with one command, tested by deploying a mock project
|}

== Execution Plan ==
Each mission will be executed in a dedicated thread using OODA loops:
* '''Observe''': Assess current system state (e.g., installed packages, configurations).
* '''Orient''': Plan configurations and identify dependencies.
* '''Decide''': Select specific tools and parameters.
* '''Act''': Implement and test the setup.
Upon thread completion, results are reported to the main strategic thread, where an independent test (e.g., file access, data transfer, script execution) confirms success. Successful missions are closed, and the next thread is initiated. The main thread tracks progress, ensuring coherence with the Imperium’s Lingua conventions and strategic goals.

== Notes ==
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.
* Mission 1 (NFS Setup) was completed with fixed port configurations for NFS services and verified through multi-node file creation, concurrent writes, and cleanup tests, establishing unified access in Pomerium.

Collegium:Imperium System

2025-09-25T22:24:46Z

AdminIsidore:

{{DISPLAYTITLE:Collegium:Imperium System}}
'''Imperium System Mission Plan'''

== Overview ==
The Imperium System Mission Plan outlines the phased construction and testing of the Imperium, a distributed data processing pipeline. Each mission is executed in a separate thread using OODA (Observe, Orient, Decide, Act) loops, with completion validated via independent tests. The plan adheres to the Lingua standard, using Latin nomenclature (e.g., ''aqua_datum'', ''grana_datum'', ''pomerium'', ''flamen_martialis'') to ensure script interoperability and support quarterly redundancy audits for AI training.

== Mission Plan ==

The following table details the 14 missions, each with tools, dependencies, and objectives to build a unified, secure, and efficient system.

{| class="wikitable sortable"
! Mission
! Description
! Tools/Dependencies
! Objectives
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| Configure NFS mounts to unify ''Roma'', ''Horreum'', and ''Torta'' (smaller HDD, ~698 GB) as a single logical system within ''Pomerium'', enabling seamless file sharing for scripts and ''grana_datum''. Ensures no race conditions and supports the "single machine" goal.
| NFS (''nfs-kernel-server'', ''nfs-common''); configure ''/etc/exports'' on ''Torta'', mount on ''Roma''/''Horreum''
| Read/write access across nodes with static IPs, tested via file creation/listing on ''pomerium_via'' paths
|-
| '''NFS-Plus GPU Dispatching'''
| Extend NFS setup to enable ''Roma'' or ''Torta'' scripts to dispatch GPU-intensive tasks (e.g., AI processing) to ''Horreum''’s NVIDIA RTX 5060 Ti, preserving energy efficiency. Builds on NFS for unified data access.
| NFS mounts, CUDA toolkit on ''Horreum'', SSH-based job dispatching (e.g., ''ssh'' or SLURM)
| Run a sample GPU task (e.g., Python/CUDA script) from ''Roma'' using ''Horreum''’s GPU
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| Set up Docker containers (''Pomerium'', ''Campus Martius'', ''Flamen Martialis'') on ''Latium'' and minimal directory structure on ''Torta'' (e.g., ''/mnt/lacus'', ''/mnt/aquaeductus'') for pipeline operations. Simplifies ''Torta'' by keeping it Docker-free.
| Docker, ''.bashrc'' modifications, directory scripts
| Functional containers and directories, tested by mock commands in each context
|-
| '''NFS-Plus Setup on Torta Hard Drives and Pomerium on Latium'''
| Configure ''Torta''’s external HDDs (larger ~1.8 TB for ''lacus'', smaller ~698 GB for ''aquaeductus'') with NFS, integrating ''Latium''’s ''Pomerium'' Docker into the internal NFS network. Ensures secure data flow from external to internal zones.
| NFS, WireGuard, ''ufw''
| Read-only NFS access from ''Latium'' to ''Torta''’s smaller HDD, tested via mount and file read
|-
| '''Flamen Martialis and Salii Separation'''
| Implement ''Flamen Martialis'' in ''Latium''’s ''Campus Martius'' Docker for external data collection/sanitation, with ''Salii'' on ''Roma'' for internal processing, reducing ''Latium''’s role and vulnerabilities. Ensures ''Salii'' is air-gapped, using ''Horreum''’s GPU.
| Python, NFS, SSH
| ''Flamen Martialis'' collecting ''aqua_datum'' and ''Salii'' processing to ''grana_datum'', tested with a mock dataset
|-
| '''Simple Data Diodes'''
| Establish a one-way data flow from ''Latium'' to ''Torta'' (''Campus Martius'' to ''Pomerium'') to prevent reverse communication, mitigating security risks. Focuses on lightweight, secure transfer protocols.
| RSYNC, ''ufw'', WireGuard
| One-way ''aqua_datum'' push to ''/mnt/lacus'', tested by verifying no reverse access
|-
| '''RSYNC Optimization'''
| Optimize RSYNC for fast, secure one-way data transfers over WireGuard, replacing SCP to avoid bottlenecks in pipelines like NOTAM. Tunes MTU and compression for performance.
| RSYNC, WireGuard, cron
| Transfer mock JSON files in <1s, tested by comparing transfer times
|-
| '''Tar + Netcat (nc) Implementation'''
| Implement tar + nc for burst/large dataset transfers, comparing with RSYNC to determine the best tool per task (e.g., NOTAM vs. musica). Establishes a decision process for tool selection.
| Tar, Netcat, WireGuard
| Functional burst transfer with a decision matrix, tested with mock data
|-
| '''Firejail/Bubblewrap Sandboxing'''
| Deploy Firejail (or Bubblewrap) on ''Latium'' to sandbox ''Flamen Martialis'' scripts, ensuring secure processing of external ''aqua_datum''. Avoids heavy Firecracker setup.
| Firejail, Python
| Sandboxed mock script with restricted access, tested via confinement checks
|-
| '''Supabase Integration'''
| Integrate Supabase as a filtering buffer for ''aqua_datum'', using RLS and edge functions to validate data before transfer to ''Torta'' or ''Roma''. Enhances security and supports prototypes.
| Supabase client libraries, REST API, WireGuard
| Validated data push/pull, tested with a mock schema
|-
| '''JSONPlaceholder Data Pipeline Test'''
| Test the full pipeline using JSONPlaceholder’s mock API, simulating data flow from ''Latium'' to ''Torta'' to ''Roma''/''OodaWiki''. Validates end-to-end setup.
| Python, RSYNC/nc, NFS, pywikibots
| Complete data cycle, tested by verifying output on ''OodaWiki''
|-
| '''NOTAM Data Pipeline Test'''
| Test the pipeline with NOTAM API data, focusing on scheduled pulls and performance. Ensures reliable handling of time-sensitive data.
| Python, Supabase (optional), RSYNC/nc, NFS
| NOTAM ingestion to ''Roma'' SQL or ''OodaWiki'', tested by data accuracy
|-
| '''RapidAPI via Supabase Test'''
| Test a basic RapidAPI endpoint via Supabase for filtering, integrating with the pipeline to store/publish results. Validates external API handling.
| Supabase, Python, RSYNC/nc, pywikibots
| API-to-Wiki flow, tested by published data on ''OodaWiki''
|-
| '''Automation/Standardized Deployment Script'''
| Develop a CLI script to automate directory and tool setup for new projects (e.g., musica, NOTAM) across Imperium, using test lessons. Ensures consistent, customizable deployments.
| Bash/Python, Docker, NFS, Supabase
| Script for project setup with one command, tested by deploying a mock project
|}

== Execution Plan ==
Each mission will be executed in a dedicated thread using OODA loops:
* '''Observe''': Assess current system state (e.g., installed packages, configurations).
* '''Orient''': Plan configurations and identify dependencies.
* '''Decide''': Select specific tools and parameters.
* '''Act''': Implement and test the setup.
Upon thread completion, results are reported to the main strategic thread, where an independent test (e.g., file access, data transfer, script execution) confirms success. Successful missions are closed, and the next thread is initiated. The main thread tracks progress, ensuring coherence with the Imperium’s Lingua conventions and strategic goals.

== Notes ==
* Missions adhere to the Lingua standard, using Latin terms (e.g., ''pomerium_via'' for NFS paths, ''frumentarii_transfer'' for RSYNC jobs) to support script interoperability and quarterly audits for AI training.
* The plan prioritizes foundational infrastructure (NFS, GPU dispatching) before security mechanisms (data diodes, sandboxing) and pipeline tests, culminating in automation for scalability.

Collegium:Imperium System

2025-09-25T22:14:58Z

AdminIsidore: Created page with "{{DISPLAYTITLE:Imperium System Mission Plan}} {{italic title}} == Overview == This document outlines the mission plan for building and testing the Imperium system, a distributed data processing pipeline. Each mission is designed to be executed in a separate thread, with phased OODA (Observe, Orient, Decide, Act) loops, and validated via independent tests upon completion. == Mission List == {| class="wikitable" |+ ! Mission Name ! Description ! Key Tools & Objectives |-..."

{{DISPLAYTITLE:Imperium System Mission Plan}}
{{italic title}}
== Overview ==
This document outlines the mission plan for building and testing the Imperium system, a distributed data processing pipeline. Each mission is designed to be executed in a separate thread, with phased OODA (Observe, Orient, Decide, Act) loops, and validated via independent tests upon completion.

== Mission List ==
{| class="wikitable"
|+
! Mission Name
! Description
! Key Tools & Objectives
|-
! colspan="3" | Phase 1: Pomerium & Internal Network Foundation
|-
| '''NFS Setup on Roma, Horreum, and Torta'''
| Configure NFS mounts to unify Roma, Horreum, and Torta's "grana" drive (~698 GB) as a single logical system within the Pomerium. This enables seamless file sharing and supports the "single machine" goal.
|
* '''Tools:''' <code>nfs-kernel-server</code>, <code>nfs-common</code>
* '''Objective:''' Full read/write access to the "grana" share on Torta from both Roma and Horreum, verified via file creation and listing.
|-
| '''NFS-Plus GPU Dispatching'''
| Extend the NFS setup to enable scripts on Roma or Torta to dispatch GPU-intensive tasks to Horreum’s NVIDIA RTX 5060 Ti, using the shared filesystem for data access.
|
* '''Tools:''' NFS, CUDA Toolkit, SSH
* '''Objective:''' Successfully run a sample GPU task (e.g., a small AI inference) initiated from Roma that reads/writes data on the NFS share and executes on Horreum's GPU.
|-
! colspan="3" | Phase 2: Aquaeductus & External Pipeline Foundation
|-
| '''Preparing Dockers and Directories on Latium and Torta'''
| Set up the Docker containers (Pomerium, Campus Martius, Flamen Martialis) on Latium and the required directory structure on Torta's "aqua" drive (`/mnt/aqua/aqua_datum_raw`) for pipeline operations.
|
* '''Tools:''' Docker, <code>.bashrc</code>, Shell scripts
* '''Objective:''' Functional containers and directories, tested by mock commands in each context.
|-
| '''Simple Data Diodes & RSYNC Optimization'''
| Establish a fast, secure, one-way data flow (the Aquaeductus) from Latium to Torta using RSYNC over the WireGuard tunnel. This replaces SCP to avoid bottlenecks.
|
* '''Tools:''' RSYNC, WireGuard, <code>cron</code>
* '''Objective:''' A one-way push of `aqua_datum` to Torta's "aqua" drive, tested by verifying transfer speed and the inability to initiate a connection from Torta back to the originating service on Latium.
|-
| '''Firejail/Bubblewrap Sandboxing'''
| Deploy Firejail on Latium to sandbox the `Flamen Martialis` script, ensuring secure processing of external `aqua_datum` by restricting its filesystem and network access.
|
* '''Tools:''' Firejail, Python
* '''Objective:''' A sandboxed mock script with verifiably restricted access to the host system.
|-
! colspan="3" | Phase 3: End-to-End Pipeline Integration & Testing
|-
| '''Flamen Martialis and Salii Separation'''
| Implement the full Flamen/Salii workflow: Flamen on Latium collects and sanitizes `aqua_datum`, which is then transferred to Torta. Salii on Roma detects the new data and orchestrates internal processing.
|
* '''Tools:''' Python, RSYNC, NFS, SSH
* '''Objective:''' Flamen Martialis successfully collects `aqua_datum`, and Salii on Roma successfully processes it to `grana_datum` on the NFS share.
|-
| '''JSONPlaceholder Data Pipeline Test'''
| Test the full, simple pipeline using JSONPlaceholder’s mock API, simulating the data flow from Latium -> Torta -> Roma -> OodaWiki. This validates the entire end-to-end architecture.
|
* '''Tools:''' Python, RSYNC, NFS, pywikibots
* '''Objective:''' A complete data cycle, verified by seeing the mock data correctly published on an OodaWiki page.
|-
| '''NOTAM Data Pipeline Test'''
| Test the pipeline with a more complex, authenticated source using the FAA's NOTAM API. This focuses on scheduled pulls and performance with real-world data.
|
* '''Tools:''' Python, RSYNC, NFS
* '''Objective:''' Successful and reliable ingestion of NOTAM data, stored as `grana_datum` on the NFS share.
|-
! colspan="3" | Phase 4: Optimization & Future Development
|-
| '''Tar + Netcat (nc) Implementation'''
| Implement and benchmark `tar` + `nc` for large, one-time "burst" transfers and compare its performance to RSYNC to establish a decision matrix for future pipeline tool selection.
|
* '''Tools:''' Tar, Netcat, WireGuard
* '''Objective:''' A functional burst transfer and a documented decision matrix for when to use RSYNC vs. `tar` + `nc`.
|-
| '''Supabase Integration'''
| Integrate Supabase as an optional, advanced filtering buffer for `aqua_datum`, using its edge functions and Row-Level Security (RLS) to validate data before it enters the Aquaeductus.
|
* '''Tools:''' Supabase client libraries, REST APIs
* '''Objective:''' A validated data push/pull through Supabase, tested with a mock schema and RLS policy.
|-
| '''Automation/Standardized Deployment Script'''
| Develop a `creo_castellum.sh` CLI script to automate the setup of new data pipelines across Imperium, based on the lessons learned from the manual builds.
|
* '''Tools:''' Bash/Python, Docker, NFS
* '''Objective:''' A script that can provision a new data pipeline with a single command, tested by deploying a new mock project.
|}

Collegium:Terra

2025-09-23T14:56:32Z

AdminIsidore:

{{DISPLAYTITLE:Imperium System Architecture}}
{{italic title}}
'''Imperium''' is a distributed, multi-node data processing pipeline designed to automate the collection, processing, and publication of data. The system is composed of several specialized hardware nodes, each with a distinct role, orchestrated to work in concert. This document outlines the foundational architecture as of September 23, 2025.

== Core Infrastructure Nodes ==
The Imperium pipeline is built upon five primary local and cloud-based servers, each with a unique specialization.

=== [[Horreum]] ===
Serves as the primary high-performance compute node, specializing in GPU-intensive tasks. It operates as a headless server, receiving jobs from the orchestrator node, Roma.
* '''Role''': Headless GPU Compute Server
* [cite_start]'''Hardware''': HP Z620 Workstation [cite: 1109]
* [cite_start]'''Operating System''': Ubuntu 24.04.3 LTS [cite: 1109]
* [cite_start]'''CPU''': 6-Core / 12-Thread Intel Xeon E5-2630 v2 @ 2.60GHz [cite: 1113]
* [cite_start]'''GPU''': NVIDIA GeForce RTX 5060 Ti with 16 GB VRAM [cite: 1165, 1167]
* [cite_start]'''Memory''': 32 GB [cite: 1110]
* [cite_start]'''Storage''': 1 TB Micron SSD, configured with a 100 GB LVM partition for the OS and ~850 GB of unallocated space for data volumes. [cite: 1131, 1170]

=== [[Roma]] ===
The central orchestrator of the pipeline. Roma is responsible for managing the workflow, scheduling tasks, and dispatching compute-intensive jobs to Horreum.
* '''Role''': Orchestration & CPU Processing
* [cite_start]'''Hardware''': Custom build with AMD A10-7700K APU [cite: 11]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 7]
* [cite_start]'''CPU''': 4-Core AMD A10-7700K @ 3.40GHz [cite: 7, 11]
* [cite_start]'''GPU''': Integrated AMD Radeon R7 Graphics [cite: 8]
* [cite_start]'''Memory''': 8 GB (6.7Gi usable) [cite: 23]
* [cite_start]'''Storage''': 2 TB Hitachi Ultrastar HDD [cite: 31]

=== [[Torta]] ===
A low-power, always-on node that serves as the bastion host and central file hub for the pipeline, managing both raw and processed data.
* '''Role''': Bastion Host & Centralized File Storage
* [cite_start]'''Hardware''': Raspberry Pi 4 Model B [cite: 767]
* [cite_start]'''Operating System''': Debian GNU/Linux 12 (bookworm) [cite: 766]
* [cite_start]'''CPU''': 4-Core ARM Cortex-A72 @ 1.80GHz [cite: 767]
* [cite_start]'''Memory''': 8 GB [cite: 767]
* '''Storage''': 32 GB SD Card for OS; [cite_start]Two external HDDs (1.8 TB and 698 GB) for data storage [cite: 782, 783]

=== [[Latium]] ===
The public-facing cloud node responsible for interacting with external APIs and services. It handles the initial data collection and the final data publication.
* '''Role''': API Scraping & Data Uploading
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1865]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1865]
* [cite_start]'''CPU''': 1-Core DO-Regular CPU [cite: 1866]
* [cite_start]'''Memory''': 2 GB [cite: 1866]
* [cite_start]'''Storage''': 50 GB SSD [cite: 1889]

=== [[OodaWiki]] ===
A cloud-based server hosting the MediaWiki instance that serves as the final destination and presentation layer for the processed data.
* '''Role''': Final Data Presentation Layer
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1001]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1001]
* [cite_start]'''CPU''': 2-Core DO-Regular CPU [cite: 1001]
* [cite_start]'''Memory''': 4 GB [cite: 1002]
* [cite_start]'''Storage''': 80 GB SSD [cite: 1024]
* [cite_start]'''Services''': MediaWiki running on PHP 8.1 [cite: 1081][cite_start], Redis [cite: 1068][cite_start], MySQL [cite: 1072][cite_start], Nginx [cite: 1077]

== Network Architecture ==
The Imperium network is divided into a private local network and a secure cloud-to-local tunnel, establishing the "Pomerium" boundary.

=== Local Network (Pomerium) ===
The core local servers operate on a subnet with static IP addresses assigned by the router.

File sharing between these nodes will be handled by a Network File System (NFS) hosted on '''Torta'''.

=== Secure VPN Tunnel (Aquaeductus) ===
A point-to-point WireGuard VPN provides a secure, encrypted tunnel between the public cloud and the private local network.
* '''Purpose''': Allows `aqua_datum` (raw data) to be transferred securely from '''Latium''' to '''Torta'''.
* '''Endpoint''': The tunnel's public endpoint is the home network's public IP, with UDP port forwarded to '''Torta'''.

== Data Pipeline Workflow ==
The pipeline operates in a continuous, automated loop orchestrated primarily by '''Roma'''.

# '''Data Collection (Castra)''': A scheduled script or containerized agent on '''Latium''' queries an external API. The raw data (`aqua_datum`) is collected.
# '''Secure Transport (Aquaeductus)''': The `Salii` system on '''Latium''' transfers the `aqua_datum` through the secure WireGuard tunnel to the first external hard drive on '''Torta'''.
# '''Processing Dispatch''': A script on '''Roma''' continuously monitors the raw data drive on '''Torta'''. When new `aqua_datum` is detected, it initiates the processing phase.
# '''Compute & Processing''': '''Roma''' handles standard data parsing. For tasks requiring significant parallel processing, '''Roma''' dispatches the job to '''Horreum'''. Both nodes work with data stored on '''Torta''' via NFS. Processed data (`grana_datum`) is written to the second external hard drive on '''Torta'''.
# '''Data Publication''': The `Cubile` system, containing the pywikibots, runs on '''Latium''' inside the secure Pomerium zone. It accesses the `grana_datum` from '''Torta''' and uses it to update the '''OodaWiki''' server.

Collegium:Terra

2025-09-19T18:28:31Z

AdminIsidore: /* Core Infrastructure Nodes */

{{DISPLAYTITLE:Imperium System Architecture}}
{{italic title}}
'''Imperium''' is a distributed, multi-node data processing pipeline designed to automate the collection, processing, and publication of data. The system is composed of several specialized hardware nodes, each with a distinct role, orchestrated to work in concert. This document outlines the foundational architecture as of September 19, 2025.

== Core Infrastructure Nodes ==
The Imperium pipeline is built upon four primary local and cloud-based servers, each with a unique specialization.

=== [[Horreum]] ===
Serves as the primary high-performance compute node, specializing in GPU-intensive tasks. It operates as a headless server, receiving jobs from the orchestrator node, Roma.
* '''Role''': Headless GPU Compute Server
* [cite_start]'''Hardware''': HP Z620 Workstation [cite: 794]
* [cite_start]'''Operating System''': Ubuntu 24.04.3 LTS [cite: 794]
* [cite_start]'''CPU''': 6-Core / 12-Thread Intel Xeon E5-2630 v2 @ 2.60GHz [cite: 799, 808]
* [cite_start]'''GPU''': NVIDIA GeForce RTX 5060 Ti with 16 GB VRAM [cite: 850, 852]
* [cite_start]'''Memory''': 32 GB [cite: 812]
* [cite_start]'''Storage''': 1 TB Micron SSD, configured with a 100 GB LVM partition for the OS and ~850 GB of unallocated space for data volumes. [cite: 816, 819]

=== [[Roma]] ===
The central orchestrator of the pipeline. Roma is responsible for managing the workflow, scheduling tasks, and dispatching compute-intensive jobs to Horreum.
* '''Role''': Orchestration & CPU Processing
* [cite_start]'''Hardware''': Custom build with AMD A10-7700K APU [cite: 1698, 1702]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1698]
* [cite_start]'''CPU''': 4-Core AMD A10-7700K @ 3.40GHz [cite: 1698]
* [cite_start]'''GPU''': Integrated AMD Radeon R7 Graphics [cite: 1699]
* [cite_start]'''Memory''': 8 GB [cite: 1714]
* [cite_start]'''Storage''': 2 TB Hitachi Ultrastar HDD [cite: 1715, 1721]

=== [[Torta]] ===
A low-power, always-on node that serves as the central file hub for the pipeline, managing both raw and processed data.
* '''Role''': Centralized File Storage
* [cite_start]'''Hardware''': Raspberry Pi 4 Model B [cite: 652]
* [cite_start]'''Operating System''': Debian GNU/Linux 12 (bookworm) [cite: 652]
* [cite_start]'''CPU''': 4-Core ARM Cortex-A72 @ 1.80GHz [cite: 652]
* [cite_start]'''Memory''': 8 GB [cite: 652]
* '''Storage''': 32 GB SD Card for OS; [cite_start]Two external HDDs (1.8 TB and 698 GB) for data storage [cite: 665, 666, 667]

=== [[Latium]] ===
The public-facing cloud node responsible for interacting with external APIs and services. It handles the initial data collection and the final data publication.
* '''Role''': API Scraping & Data Uploading
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 549]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 549]
* [cite_start]'''CPU''': 1-Core DO-Regular CPU [cite: 549]
* [cite_start]'''Memory''': 2 GB [cite: 550]
* [cite_start]'''Storage''': 50 GB SSD [cite: 570]

=== [[OodaWiki]] ===
A cloud-based server hosting the MediaWiki instance that serves as the final destination and presentation layer for the processed data.
* '''Role''': Final Data Presentation Layer
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1351]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1351]
* [cite_start]'''CPU''': 2-Core DO-Regular CPU [cite: 1351]
* [cite_start]'''Memory''': 4 GB [cite: 1352]
* [cite_start]'''Storage''': 80 GB SSD [cite: 1372]
* [cite_start]'''Services''': MediaWiki running on PHP 8.1 [cite: 1431][cite_start], Redis [cite: 1417][cite_start], MySQL [cite: 1421][cite_start], Nginx [cite: 1427]

== Data Pipeline Workflow ==
The pipeline operates in a continuous, automated loop orchestrated primarily by '''Roma'''.

# '''Data Collection''': A scheduled script on '''Latium''' queries an external API. The raw data is pulled and transferred via SCP/SSHFS to the first external hard drive connected to '''Torta'''.
# '''Processing Dispatch''': A script on '''Roma''' continuously monitors the raw data drive on '''Torta'''. When new data is detected, it initiates the processing phase.
# '''Compute & Processing''': '''Roma''' handles standard data parsing. For tasks requiring significant parallel processing, '''Roma''' dispatches the job to '''Horreum''', which leverages its RTX 5060 Ti GPU. Both nodes work with data stored on '''Torta'''. Processed data is written to the second external hard drive on '''Torta'''.
# '''Data Publication''': A script on '''Latium''' monitors the processed data drive on '''Torta'''. When new processed data is available, it is pulled to '''Latium''' and then formatted and uploaded to the '''OodaWiki''' server using Pywikibot.

Collegium:Terra

2025-09-19T18:28:01Z

AdminIsidore: /* Horreum */

{{DISPLAYTITLE:Imperium System Architecture}}
{{italic title}}
'''Imperium''' is a distributed, multi-node data processing pipeline designed to automate the collection, processing, and publication of data. The system is composed of several specialized hardware nodes, each with a distinct role, orchestrated to work in concert. This document outlines the foundational architecture as of September 19, 2025.

== Core Infrastructure Nodes ==
The Imperium pipeline is built upon four primary local and cloud-based servers, each with a unique specialization.

=== [[Horreum]] ===
Serves as the primary high-performance compute node, specializing in GPU-intensive tasks. It operates as a headless server, receiving jobs from the orchestrator node, Roma.
* '''Role''': Headless GPU Compute Server
* [cite_start]'''Hardware''': HP Z620 Workstation [cite: 794]
* [cite_start]'''Operating System''': Ubuntu 24.04.3 LTS [cite: 794]
* [cite_start]'''CPU''': 6-Core / 12-Thread Intel Xeon E5-2630 v2 @ 2.60GHz [cite: 799, 808]
* [cite_start]'''GPU''': NVIDIA GeForce RTX 5060 Ti with 16 GB VRAM [cite: 850, 852]
* [cite_start]'''Memory''': 32 GB [cite: 812]
* [cite_start]'''Storage''': 1 TB Micron SSD, configured with a 100 GB LVM partition for the OS and ~850 GB of unallocated space for data volumes. [cite: 816, 819]

=== [[Roma]] ===
The central orchestrator of the pipeline. Roma is responsible for managing the workflow, scheduling tasks, and dispatching compute-intensive jobs to Horreum.
* '''Role''': Orchestration & CPU Processing
* [cite_start]'''Hardware''': Custom build with AMD A10-7700K APU [cite: 1698, 1702]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1698]
* [cite_start]'''CPU''': 4-Core AMD A10-7700K @ 3.40GHz [cite: 1698]
* [cite_start]'''GPU''': Integrated AMD Radeon R7 Graphics [cite: 1699]
* [cite_start]'''Memory''': 8 GB [cite: 1714]
* [cite_start]'''Storage''': 2 TB Hitachi Ultrastar HDD [cite: 1715, 1721]
* [cite_start]'''Network''': Static IP [[meta:TODO|192.168.68.201]] via wired Ethernet (`enp1s0`) [cite: 1747]

=== [[Torta]] ===
A low-power, always-on node that serves as the central file hub for the pipeline, managing both raw and processed data.
* '''Role''': Centralized File Storage
* [cite_start]'''Hardware''': Raspberry Pi 4 Model B [cite: 652]
* [cite_start]'''Operating System''': Debian GNU/Linux 12 (bookworm) [cite: 652]
* [cite_start]'''CPU''': 4-Core ARM Cortex-A72 @ 1.80GHz [cite: 652]
* [cite_start]'''Memory''': 8 GB [cite: 652]
* '''Storage''': 32 GB SD Card for OS; [cite_start]Two external HDDs (1.8 TB and 698 GB) for data storage [cite: 665, 666, 667]
* [cite_start]'''Network''': Static IP [[meta:TODO|192.168.68.202]] via wired Ethernet (`eth0`) [cite: 670, 671]

=== [[Latium]] ===
The public-facing cloud node responsible for interacting with external APIs and services. It handles the initial data collection and the final data publication.
* '''Role''': API Scraping & Data Uploading
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 549]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 549]
* [cite_start]'''CPU''': 1-Core DO-Regular CPU [cite: 549]
* [cite_start]'''Memory''': 2 GB [cite: 550]
* [cite_start]'''Storage''': 50 GB SSD [cite: 570]
* [cite_start]'''Network''': Public IP [[meta:TODO|159.65.246.113]] (`eth0`) [cite: 575]

=== [[OodaWiki]] ===
A cloud-based server hosting the MediaWiki instance that serves as the final destination and presentation layer for the processed data.
* '''Role''': Final Data Presentation Layer
* [cite_start]'''Hardware''': DigitalOcean Droplet [cite: 1351]
* [cite_start]'''Operating System''': Ubuntu 22.04.5 LTS [cite: 1351]
* [cite_start]'''CPU''': 2-Core DO-Regular CPU [cite: 1351]
* [cite_start]'''Memory''': 4 GB [cite: 1352]
* [cite_start]'''Storage''': 80 GB SSD [cite: 1372]
* [cite_start]'''Network''': Public IP [[meta:TODO|104.248.8.20]] (`eth0`) [cite: 1376]
* [cite_start]'''Services''': MediaWiki running on PHP 8.1 [cite: 1431][cite_start], Redis [cite: 1417][cite_start], MySQL [cite: 1421][cite_start], Nginx [cite: 1427]

== Data Pipeline Workflow ==
The pipeline operates in a continuous, automated loop orchestrated primarily by '''Roma'''.

# '''Data Collection''': A scheduled script on '''Latium''' queries an external API. The raw data is pulled and transferred via SCP/SSHFS to the first external hard drive connected to '''Torta'''.
# '''Processing Dispatch''': A script on '''Roma''' continuously monitors the raw data drive on '''Torta'''. When new data is detected, it initiates the processing phase.
# '''Compute & Processing''': '''Roma''' handles standard data parsing. For tasks requiring significant parallel processing, '''Roma''' dispatches the job to '''Horreum''', which leverages its RTX 5060 Ti GPU. Both nodes work with data stored on '''Torta'''. Processed data is written to the second external hard drive on '''Torta'''.
# '''Data Publication''': A script on '''Latium''' monitors the processed data drive on '''Torta'''. When new processed data is available, it is pulled to '''Latium''' and then formatted and uploaded to the '''OodaWiki''' server using Pywikibot.