This article is the developer-facing reference for GDX_HUMAN7 (GoDataX Human), reconstructed directly from the project's own GDX_HUMAN7_DEVELOPMENT_KIT.md, the single entry point a developer joining the project is expected to read. It documents what the project is, how its pieces fit together, how every automation is run, and what each relational schema looks like.

Source: a direct read of every .md document, SKILL.md file, and *.sql DDL/DML script in the repository, plus the architecture slides of GDX_CTP_H7/GDX_DOCUMENTS/GDX_HUMAN/GoDataXHuman7-Br2.odp.

Repository

https://github.com/wilsonfda/godatax.human7.git

Main branch: master. There is no CI pipeline and no build step. This is a documentation + SQL + Node.js/Python automation repository, not a compiled application. Every numbered top-level folder is close to self-contained (its own .claude/skills/, its own .md docs, its own .sql), which is why the folders are numbered in dependency order rather than grouped by language or layer.

1.0 Project Overview

GDX_HUMAN7 is a data-engineering and research project that starts from one real psychometric study, "Predictors of Adaptability to Military Higher Education," applied to 423 cadets at the Military Academy, and expands it in several directions:

1. A rigorous relational model of the raw psychometric data (item-level responses, dimension scores, instruments, constructs) in a Firebird 2.5 database.
2. Interpretive/qualitative bridges between that scientific base and four distinct philosophical/esoteric traditions: the theosophical Septenary Constitution, the 7 Kundalini chakras, Thomas Aquinas's Five Ways, and Virtology (a 33-virtue neuro-philosophical system), always kept explicit as conceptual readings, not statistical findings.
3. Physiological data (cardiac coherence / HRV device) linked to the same person identity as the psychometric study.
4. An analytical layer (a star-schema data warehouse) unifying all these perspectives for cross-cutting queries.
5. A knowledge graph (Neo4j) mirroring the entire relational schema, feeding two graph-machine-learning models (link prediction, community detection) and an LLM assistant.
6. A repeatable pipeline for onboarding new studies/instruments from scratch. The original 423-cadet study was loaded once, by hand; any future study goes through a generic skill assembly line (interview, SQL generation, load, questionnaire export, answer load).

Nearly all automation in the project is implemented as Claude Code skills (.claude/skills/ inside each folder), each with its own SKILL.md. The general pattern is "generate, then execute": a Python or Node.js script reads the data source and generates SQL; a second script executes that SQL against Firebird (--dry-run always available before a real write).

1.1 The source data, in one sentence

An IBM SPSS .sav file with no embedded metadata (no variable labels, no value labels). Every column's meaning (AC1, Ha7, ENGAGvigor, …) had to be reverse-engineered from external support documents and is documented in SPSS_to_Firebird_Mapping.md. 423 respondents, 159 columns: 137 raw items across 9 instruments, 1 context variable (ano, curricular year) and 20 pre-computed dimension scores.

Three additional blocks (ef1–ef18, an1–an11, red1–red5) are medium/low-confidence hypotheses (Maslach Burnout Inventory, an unidentified "organizational anomie" block, and "Red Tape"). No supporting document confirms their authorship or exact item wording. This gap is documented, not guessed at.

1.2 One person, one identity, everywhere

A design decision cuts across folders 2, 6, 7 and 9: there is exactly one person identity in the whole project, GDX_PSY_PERSON.ID_PERSON. DW_DIM_PERSON is a faithful copy of it; GDX_CC_PERSON.ID_PERSON is a direct FK into it (not a parallel catalog); the Neo4j graph inherits the same id as gdx_key. Today only one person (SPSS-784) has both psychometric and cardiac-coherence data, which limits what the dashboards/ML can show about the intersection of the two sources, but the architecture is already built for more.

2.0 Getting Started

2.1 Technology stack

2.2 Credentials & environment variables

Every skill reads connection settings from environment variables, never hardcoded, an explicit, repo-wide rule called out in nearly every SKILL.md and .env.example.

# Firebird (godatax.human), used by every skill that reads/writes GDX_PSY_*/GDX_TA_*/GDX_CC_*/DW_*
GDX_HUMAN_FB_HOST=127.0.0.1
GDX_HUMAN_FB_PORT=3050
GDX_HUMAN_FB_DATABASE=/firebird/godatax.gdb
GDX_HUMAN_FB_USER=godatax1
GDX_HUMAN_FB_PASSWORD=

# Neo4j (AuraDB), used only by the knowledge-graph export and the two ML skills
NEO4J_URI=neo4j+s://xxxxxxxx.databases.neo4j.io
NEO4J_USERNAME=
NEO4J_PASSWORD=
NEO4J_DATABASE=

.env files are gitignored everywhere; only .env.example (no secrets) is committed.

2.3 Running a skill: the general pattern

cd <folder>/.claude/skills/<SKILL_NAME>/scripts
npm install                        # once
# copy ../.env.example to ../.env and fill in the password, or export the vars directly
node <script>.js --dry-run [--study <slug>]   # see what would happen, writes nothing
node <script>.js [--study <slug>]             # apply it, confirm with a human first

• --dry-run is supported by essentially every write-capable skill.
• --study <slug> scopes a run to one study and is required by every skill built or updated since 2026-09-17/18 (dashboards, DW loader, knowledge-graph export, link suggestions).
• Read-only analysis skills (the two 10.gdx.machine.learning ML skills) never touch Firebird, only Neo4j.

2.4 Sharing the skills with a team

These are Claude Code skills, not a claude.ai (web/desktop chat) feature. claude.ai's own "Skills" run in an isolated cloud sandbox with no outbound network access to a private host and no access to a local .env, so a skill that needs to reach 127.0.0.1 or a Neo4j AuraDB instance with real credentials cannot run there. Every skill in this repository is designed to run locally, inside Claude Code, on a machine that has network access to the database and its own .env. Two different audiences need two different kinds of access.

Teammates who will run the skills themselves

1. Repository access. The repo is hosted at https://github.com/wilsonfda/godatax.human7.git. If it is private, add each teammate as a collaborator (or invite them to the GitHub org/team that owns it).
2. Local setup, per teammate: install Claude Code, git clone the repository, then for every skill they will actually use, cd into its scripts/ folder and npm install once (§2.1).
3. Skill discovery is not recursive. Claude Code discovers project-level skills by searching .claude/skills/ upward from the current working directory toward the repository root, not downward into every subdirectory. Because each numbered folder has its own .claude/skills/ (§3), opening Claude Code at the repository root does not automatically surface the skills nested inside 0.new.instrument/, 2.relational.model.psychometrics/, 9.knowledge.graph/, and so on. In practice this is already how the repo is meant to be used (§2.3's own cd <folder>/.claude/skills/<SKILL_NAME>/scripts pattern), but it is worth spelling out for anyone new to Claude Code:
   • Default, no extra setup: cd into the specific numbered folder before invoking that folder's skill, matching the pattern already used throughout §2.3 and §5.
   • One Claude Code session across several folders: run /add-dir <folder> (Claude Code v2.1.257+) for each numbered folder whose skills are needed in that session, instead of restarting Claude Code every time the working folder changes.
   • Team-wide, install-once alternative: package the skills as a Claude Code plugin and publish it to a plugin marketplace (a git repository can serve as one). A teammate then runs /plugin marketplace add <repo> once and /plugin install <skill>@<marketplace> per skill, and the skills become available in every project regardless of working directory. Plugin skills and project-level skills can coexist; a marketplace/plugin pairing can be declared in .claude/settings.json:

     {
       "extraKnownMarketplaces": {
         "gdx-human7-skills": {
           "source": { "source": "github", "repo": "wilsonfda/godatax.human7" }
         }
       },
       "enabledPlugins": { "gdx-human7@gdx-human7-skills": true }
     }

     This is the recommended path once more than a couple of people need the full skill set regularly, since it removes the "which folder am I in" question entirely.
4. Credentials, per teammate. Every skill reads Firebird/Neo4j connection settings from .env (§2.2), never hardcoded. Prefer creating a separate Firebird user and a separate Neo4j AuraDB user per teammate (scoped to read-only where write access isn't needed) over sharing one password, so a --dry-run/write-guard mistake is attributable and revoking one person's access is trivial.

People who only need to see results, no install

Several outputs of this pipeline need no Claude Code, no .env, and no database access at all, because they are pre-rendered, self-contained artifacts:

• The dashboards (8.gdx.dashboards/) are standalone .html files with inline SVG and no external dependency. Open directly in a browser, or send the file; they are also published live right on this page, above, so pointing a non-technical stakeholder here is usually the fastest option.
• The written deep-dive docs (Dashboards_DW_Explanation.md, GoDataX_Human_7_Knowledge_Graph.md, Septenary_Link_Prediction_and_Community_Detection.md, the development kit itself, and others) are plain Markdown, readable on GitHub or any Markdown viewer.

Conversational access without Claude Code (advanced)

To let someone ask natural-language questions grounded in the Neo4j graph (§8, the 11.gdx.llm.agent.mcp/prompt.instruction.txt system prompt) without installing Claude Code, claude.ai's sandboxed Skills feature is the wrong tool, but claude.ai's Connectors (remote MCP servers, available on Team/Enterprise plans) are not sandboxed the same way: a Connector is explicitly meant to reach a service you host. The path is:

1. Stand up an MCP server that exposes the Neo4j graph (a small wrapper around neo4j-driver, hosted anywhere reachable over HTTPS; this does not exist in the repo yet and would need to be built).
2. Register its URL as a custom Connector in the claude.ai Team/Enterprise admin settings, and load prompt.instruction.txt as that Connector-enabled chat's system prompt/Project instructions.
3. Teammates with access to that Connector can then query the graph conversationally from ordinary claude.ai chat, with the same rigor rules the prompt enforces: always distinguish empirical data from interpretation, never diagnose, always show the graph path.

This is meaningfully more infrastructure work than the two options above (a server to host and secure) and is not required for the pipeline to function. It only matters if conversational, install-free access to the graph is a real requirement.

3.0 Repository Map

GDX_HUMAN7/
  0.new.instrument/               <- generic pipeline to onboard a NEW study from scratch
  1.output.ibm.spss.statistics/   <- the original .sav file + its full data documentation
  2.relational.model.psychometrics/  <- the GDX_PSY_* schema (core of everything) + the loaded study
  3.septenary.constitution/       <- interpretive bridge: instruments × 7 theosophical bodies/levels
  4.kundalini.chakras/            <- interpretive bridge: 7 chakras × septenary levels
  5.five.ways.tomas.aquino/       <- interpretive bridge: Aquinas's 5 ways × septenary levels
  6.cardiac.coherence/            <- physiological data (ECG/HRV device), same person identity
  7.multidimensional.database/    <- the Data Warehouse (star schema) unifying folders 2–6
  8.gdx.dashboards/               <- 8 self-contained HTML dashboards reading the DW
  9.knowledge.graph/              <- export of the whole relational schema into Neo4j
  10.gdx.machine.learning/        <- 2 graph ML models (link prediction, community detection)
  11.gdx.llm.agent.mcp/           <- system prompt for an LLM assistant over the knowledge graph
  12.gdx.virtology/               <- knowledge base of 33 virtues + link-suggestion skill

The numbering reflects, broadly, dependency order: every folder consumes data from lower-numbered folders (the DW in folder 7 reads folders 2–6; the dashboards in folder 8 read folder 7; the graph in folder 9 reads folders 2–7; the ML in folder 10 reads folder 9 only).

4.0 The Pipeline, Step by Step (0–12)

Step 0: New Instrument Onboarding

Four chained skills onboard a brand-new study from scratch:

GDX_SKILL_NEW_STUDY            conversational interview -> new_study_intake/<slug>/intake.json
        |
GDX_SKILL_RECORD_NEW_STUDY     generates SQL from intake.json + executes it against Firebird
        |
GDX_SKILL_EXPORT_NEW_STUDY     reads Firebird -> generates a blank .xlsx questionnaire
        |
   (send one copy per participant, wait for it to come back filled in)
        |
GDX_SKILL_LOAD_NEW_STUDY_ANSWERS   reads ONE filled .xlsx -> writes responses into Firebird

Unlike the historical study (loaded once, by hand), this assembly line is generic: it never hardcodes an id, never invents a field the user doesn't know the answer to, and never duplicates an already-onboarded study. Filled .xlsx files (real participant data) must never be committed. Only intake.json and the generated SQL are meant to be committed.

No dedicated schema of its own. These four skills read and write the GDX_PSY_* relational model shown in Step 2 below, mediated by new_study_intake/<slug>/intake.json.

Skills in this step

Step 1: The Source Data

The historical study's .sav file (423 cadets) and its complete documentation. No skill lives here. It is a raw data source, read by GDX_SKILL_LOAD_RLT_MODEL_DB (folder 2).

Step 2: Psychometrics, the GDX_PSY_* schema

The heart of the project: psychometrics_model_firebird25.sql defines the full relational model, from study to instrument to construct to variable/indicator to item to response alternative to application to response to computed result. 28 tables in total. Every surrogate key is a BIGINT populated by a Firebird BEFORE INSERT trigger reading from a matching SEQ_GDX_PSY_* sequence. No id is ever hardcoded by application code except in the frozen, one-time historical load scripts.

Key rules baked into the DDL:

• GDX_PSY_PERSON.EXTERNAL_IDENTIFIER and GDX_PSY_STUDY_PARTICIPANT(ID_STUDY, ANONYMOUS_CODE) are unique: one physical person, one row, reusable across studies.
• GDX_PSY_ITEM_RESPONSE is unique per (ID_APPLICATION, ID_ITEM); every *_RESULT table is unique per (ID_APPLICATION, ID_CONSTRUCT|ID_VARIABLE|ID_INDICATOR).
• PERCENTILE columns are check-constrained to [0, 100]; boolean-like flags (CONSENT, ACTIVE, REVERSED) are check-constrained to (0,1).
• GDX_PSY_APPLICATION/OBSERVATION/EVALUATION all FK to the composite key (ID_STUDY, ID_PERSON) of GDX_PSY_STUDY_PARTICIPANT, not to GDX_PSY_PERSON directly. A person must be enrolled in the study before anything can reference them there.

Skills in this step

Step 3: Septenary Constitution, instruments × 7 bodies

Catalogs the 7 levels of the theosophical Septenary Constitution (Physical → Vital/Etheric → Astral → Lower Mental → Higher Mental → Buddhic → Atmic/Spirit) and relates psychometric variables to them, each row carrying a written justification and a CONFIDENCE_LEVEL (HIGH/MEDIUM/LOW/SPECULATIVE). ID_INSTRUMENT/ID_VARIABLE are nullable by design: the mapping was populated by free-text label before the formal catalog existed, and is reconciled to real ids afterward.

Skill in this step

Step 4: Kundalini Chakras, 7 chakras

No skill (static DDL/DML). A strict 1:1 ascending correspondence to GDX_PSY_SEPTENARY_LEVEL (chakra of order N ↔ septenary level of order N, a common yoga-theosophy syncretism, explicitly framed as symbolic, not empirical). Unlike the septenary mapping table, ID_SEPTENARY_LEVEL here is NOT NULL. Every chakra always resolves to exactly one level, and the correspondence is fixed DDL/DML.

No skill in this step. The correspondence is fixed DDL/DML; no loader skill ever touches this table.

Step 5: The Five Ways of Aquinas

No skill (static DDL/DML). Catalogs Thomas Aquinas's five cosmological/teleological arguments for God's existence (Summa Theologica I, Q.2, Art.3) and relates each way to the septenary level that best matches the faculty of reasoning it exercises, deliberately N:1 (levels 4/4/5/5/6), never trivially mapping all five to level 7. Confidence is mixed by design: way 4 → Higher Mental is rated HIGH, way 5 → Buddhic is SPECULATIVE, the rest MEDIUM.

No skill in this step. Static DDL/DML, populated once and never touched by a loader skill.

Step 6: Cardiac Coherence, physiological data (ECG/HRV)

Schema GDX_CC_* for capturing cardiac coherence with the ECG/HRV device. GDX_CC_PERSON is not a parallel person catalog. Its ID_PERSON is a direct FK into DW_DIM_PERSON/GDX_PSY_PERSON, the same identity used on the psychometric side, enforced at the database level. Device specs are baked into check constraints: ECG_SAMPLE_RATE_HZ IN (125,128,200,250,256,500,512), 15-bit resolution, HEART_RATE_BPM BETWEEN 20 AND 240, RR_INTERVAL_MS BETWEEN 250 AND 3000. STRESS_CLASS and DEVICE_TEMP_C carry explicit column comments warning they are not a diagnosis / not body temperature.

The physical sensor behind this data is a coin-sized ECG/HRV module worn on a chest strap. It streams raw ECG samples and RR intervals over Bluetooth to the acquisition pipeline that ultimately lands in GDX_CC_ECG_SAMPLE and GDX_CC_RR_INTERVAL.

Skill in this step

Step 8: Dashboards

8.gdx.dashboards/ has no dedicated schema of its own. It only reads the Data Warehouse built in Step 7, below:

The 9 charts, live

Each chart below is the actual, self-contained output of the skill: no server, no external library, just inline SVG and a small script, rendered live from ID_STUDY=1.

5.0 Deep Dive: The Data Warehouse (Step 7)

A single star-schema layer (11 dimensions + 3 facts) relating the five separate OLTP perspectives (psychometric, septenary, chakra, Five Ways, cardiac coherence) without replacing any of them, a read-oriented reshaping that lets one query cross perspectives. For example, "for people whose Hardiness-Challenge score is high, and whose corresponding septenary level is Buddhic, what chakra and which of Aquinas's Five Ways share that level?"

GDX_PSY_PERSON is the single, central person table for the entire DW. DW_DIM_PERSON is sourced from it alone. GDX_CC_PERSON remains its own OLTP table, but is enforced at the database level to point into the same person space via FK_GDX_CC_PERSON_DW_PERSON. One consequence: DW_DIM_PERSON must be loaded before any GDX_CC_PERSON insert can succeed, and can no longer be freely truncated without first considering GDX_CC_PERSON's dependency on it.

No dimension key is reinvented where the source already has a clean BIGINT PK (e.g. DW_DIM_PERSON.ID_PERSON = GDX_PSY_PERSON.ID_PERSON). The only generated dimension is DW_DIM_DATE (2020-01-01…2030-12-31); DATE_KEY = -1 is the reserved "no date" member used by every psychometric fact (the .sav carries no calendar date). How a psychometric fact reaches the metaphysical/energetic perspectives: DW_FACT_PSY_VARIABLE_RESULT → DW_DIM_VARIABLE.ID_SEPTENARY_LEVEL → DW_DIM_SEPTENARY_LEVEL → (DW_DIM_CHAKRA / DW_DIM_FIVE_WAY).

Skill in this step

Validated load (real numbers, godatax.human)

Two loading modes

6.0 Deep Dive: The Knowledge Graph (Step 9)

Folders 2 through 8 store everything as relational tables, correct for OLTP writes and for the SQL-shaped questions the dashboards ask. But the ML models in folder 10 need a graph embedding: a numeric vector per node encoding not just its own columns but its position in the whole network of relationships around it.

The mapping rule is generic, not hand-mapped:

• Node = one table, label = the table name exactly as Firebird has it.
• Node property = one column (BLOB SUB_TYPE TEXT columns read as plain strings).
• Node identity (gdx_key) = the table's own PK (composite keys joined with ::). Every write is a Cypher MERGE, idempotent and re-runnable.
• Relationship = one FK constraint whose child and parent are both in scope; type = the constraint's own name, direction child → parent. A NULL FK produces no relationship.
• Discovered live every run via Firebird's RDB$ system catalog: a new table under an in-scope prefix (GDX_PSY_*, GDX_TA_*, GDX_CC_*, DW_DIM_*, DW_FACT_*) appears in the graph automatically, with no code change.

Skill in this step

A worked example, one row of GDX_PSY_VARIABLE_RESULT (person 784's Emotional Exhaustion score):

(:GDX_PSY_VARIABLE_RESULT {gdx_key:"...", RAW_SCORE:4.0})
  -[:FK_GDX_PSY_VR_APPLICATION]-> (:GDX_PSY_APPLICATION {gdx_key:"784", ID_STUDY:1})
  -[:FK_GDX_PSY_VR_VARIABLE]->    (:GDX_PSY_VARIABLE {gdx_key:"22", NAME:"Emotional Exhaustion"})
                                       -[:FK_GDX_PSY_VARIABLE_CONSTRUCT]-> (:GDX_PSY_CONSTRUCT {gdx_key:"9"})

23 tables are filtered to one study's rows (via ID_STUDY/ID_PERSON/ ID_APPLICATION/SESSION_ID/ID_EVALUATION); 32 shared reference/catalog tables are always exported in full, every run. Because the graph accumulates (MERGE, not truncate), running the skill again for a second study adds that study's rows without touching the first study's.

7.0 Deep Dive: Machine Learning Models (Step 10)

Both models run on Neo4j Graph Data Science (GDS), with no separate Python/pandas ETL for the embedding step itself.

Model 1: Link Prediction

Question: which septenary level should a new, still-unmapped variable most likely belong to? Supervised, FastRP node embeddings over the catalog subgraph, then a classifier scoring every (unmapped variable, level) candidate pair. 18–19 positive examples spread across 7 classes is a small training set, so a confidence threshold turns a weak score into "no suggestion" rather than a manufactured guess. The model is a triage aid, never a classifier trusted unsupervised. It never auto-writes; a human still adds an accepted suggestion by hand.

Real first run: 22 GDX_PSY_VARIABLE nodes, 18 mapped, 4 unmapped (all four are the excluded-by-design Organizational Anomie block plus Red Tape, correctly showing no strong single winner). Independent GDS-pipeline AUCPR: 0.75 (test), ~0.78 (validation avg). A real Neo4j Aura Graph Analytics bug (link-prediction predict.* mis-resolving relationship endpoints on a multi-label projection) is worked around by pulling FastRP embeddings via a plain node-property read and training a ~30-line in-script logistic regression instead.

Scoped below with the Data Science Workflow Canvas (GDX_STRATEGIC_DISCOVERY):

Model 2: Community Detection

Question: do variables/instruments naturally group the way the septenary/chakra/Five-Ways framework says they should? Unsupervised: Louvain (primary) plus Label Propagation (cross-check), without any label-derived shortcut edge, so the test is honest. Real run: Louvain found 9 non-trivial communities. Most are clean structural confirmations (the three satisfaction-family instruments cluster together on Astral/Manipura); one is the predicted "spans levels" case (the Engagement Scale's Dedication and Absorption cluster together but span Higher Mental and Buddhic). Label Propagation agreement was high (mostly 100%).

Scoped below with the Data Science Workflow Canvas (GDX_STRATEGIC_DISCOVERY):

• Match — a community is one solid level color, validating that part of the mapping.
• Community spans levels — e.g. Community X mixes Astral and Higher Mental.
• Level splits across communities — e.g. Astral appears in both Community X and Community Y.

Suggested order: Model 2 first (no labeled data needed, low risk, immediate); Model 1 second, revisited as the labeled set grows.

8.0 Deep Dive: The LLM Knowledge-Graph Agent (Step 11)

A single system-prompt file (11.gdx.llm.agent.mcp/prompt.instruction.txt) for an LLM assistant connected to the Neo4j knowledge graph. Core rules the prompt enforces:

1. Answer only from what the connected Neo4j graph actually contains. Never invent a relationship, measurement, instrument, result, or interpretation.
2. If the graph doesn't have enough information, say so explicitly rather than filling the gap.
3. Always distinguish five categories in any answer: scientifically measurable data, calculated indicators, psychological interpretations, philosophical/metaphysical interpretations, and energetic/traditional models.
4. Never present a metaphysical/philosophical/energetic association as a scientifically validated causal relationship.
5. Never provide a medical or psychological diagnosis. The assistant is explicitly educational/analytical, not a substitute for a qualified professional.
6. Protect participant-identifying data; disclose it only to an explicitly authorized user.
7. When useful, show the actual graph path (entities and relationships) behind an answer.
8. Respond in the same language the user used; if asked to translate, translate the entire answer including retrieved values.

Preferred response structure: direct answer → evidence found in the graph → relevant relationships/graph path → scientific-or-interpretive classification → limitations.

No skill in this step. It is a single system-prompt file, not an automated Claude Code skill; it is the prompt used by an external agent/chat integration (Neo4j Aura's console.neo4j.io agent) connected to the Step 9 graph.

9.0 Deep Dive: Virtology & Link Suggestions (Step 12)

A "clinical-philosophical" school founded by Eduardo Casarotto, captured via an automated, explicitly-flagged-as-unverified web fetch. Central reframing: a virtue is redefined away from a moral concept into a neurological one, "a set of neural networks working in a specific configuration," trainable through repetition until it operates without effort.

The 33 virtues are given as a complete, ordered list (Humility declared explicitly foundational: "without it none of the others can be sustained"). Open gaps are honestly documented: no full inventory of the claimed "Evolution Levels," no official virtue→SNO/SNE mapping exists from the source at all. Only a narrower, project-authored variable→virtue map is used in practice.

Skill in this step

Real validated run, ID_STUDY=1, top lowest indicators:

The unresolved row is the "never guesses" rule working as intended: Emotional Exhaustion was never in the original .sav at all (it was computed later from raw item responses), so it has no .sav column for the lookup key to match.

10.0 Cross-Cutting Design Principles

Several documents repeat, in different words, the same rules. Worth naming once:

• Never invent missing data. A gap is always documented as a gap (an UNKNOWN mapping, a "no suggestion (review)" row, an UNMATCHED/MISSING report line), never filled with a guess.
• "Not zero, not missing, structurally absent." The phrase used for a heatmap cell with no mapped instrument at a level. The same reasoning applies to any relationship that simply doesn't exist in the schema yet.
• Empirical finding ≠ interpretive reading. Relating a scientific instrument to a chakra or a virtue is a conceptual organizing tool inside GoDataX, never a scientific or doctrinal claim.
• Secrets are never committed. Every skill that touches Firebird/Neo4j reads credentials from environment variables (.env, gitignored; only .env.example is committed).
• Idempotency and reversibility. Nearly every database-writing skill supports --dry-run, an "already loaded" guard, and never deletes data.
• One person, one identity, enforced first as a convention, then as an actual database FOREIGN KEY (FK_GDX_CC_PERSON_DW_PERSON).
• --study <slug> scoping. Every skill built or touched since 2026-09-17/18 resolves the same intake.json → GDX_PSY_STUDY.ID_STUDY chain, so a second study never silently blends into a chart, a DW load, or a report meant for the first one.

11.0 Proposed Architecture Extension: Environmental, Energetic & Anomalous Phenomena Sensing

This is a designed but not yet implemented extension. No folder, schema, or skill exists for it in the repository today. It is reconstructed from slides 90 through 96 of the project's own slide deck (GDX_CTP_H7/GDX_DOCUMENTS/GDX_HUMAN/GoDataXHuman7-Br2.odp) and organized below as a layered engineering architecture, from raw sensor reading through to interpretive output, together with concrete recommendations for folding it into the existing repository conventions if and when it is built.

The framework proposes recording environmental/anomalous signals that are not perceptible to the naked eye, on the same unified timeline as the psychometric, physiological and cardiac-coherence sensors already implemented, so simultaneities and temporal patterns between a person's internal state and their surrounding environment can be observed (explicitly: "correlation, not proof of causation"). The design separates six layers, front to back: a concept layer (the unified timeline itself), a sensor-reading layer (the 21 instrumental dimensions), an acquisition layer (the physical gateway hardware), a data model layer (the proposed relational schema), a processing layer (turning synchronized streams into detected events), and an interpretation layer (turning detected events into classified, labeled hypotheses).

11.1 Concept layer: one timeline, multiple sensors

Every signal family below is plotted against the same time axis as the psychometric, physiological and cardiac-coherence data already captured elsewhere in the project, so that co-occurring events can be read off a single timeline rather than reconciled after the fact across separate logs.

All eight streams are correlated against the same three target datasets already in production: psychometric, physiological, and cardiac-coherence data. The slide deck is explicit that this is a statement about simultaneities and temporal patterns, not proof of causality.

The source diagram also carries a three-tier legend worth preserving in any implementation: instrumental measurement (a sensor reading), subjective report (something a participant says happened), and philosophical/metaphysical interpretation (a reading of what it might mean). Nothing in this extension is allowed to collapse those three into one undifferentiated "event."

11.2 Sensor-reading layer: 21 instrumental dimensions

Every measurement is explicitly framed as instrumental (a physical, objective reading). Interpretations such as "presence," "entity," or "communication" belong to a separate, clearly-labeled analytical/hypothetical layer, never mixed into the raw measurement. The 21 dimensions group into 5 categories:

11.3 Acquisition layer: two-tier hardware gateway

Two-tier acquisition, matching sensor bandwidth to compute needs: a Raspberry Pi 5 acts as the acquisition gateway for the lower-bandwidth sensors, collecting, pre-processing and time-synchronizing them; a Mini PC handles the instruments that need more compute or bandwidth. The two devices connect over Ethernet, and every sensor stream carries a GPS/NTP/PTP timestamp so readings across both devices align on one precise timeline.

Data & processing flow, sensor to insight:

1. Sensors: environmental data acquisition.
2. Raspberry Pi 5 / Mini PC: collection, synchronization and pre-processing.
3. Database: secure, structured storage.
4. Temporal correlation: multisensor analysis over time.
5. Anomaly detection: AI and detection algorithms.
6. Interpretive layer: visualization, reports and insights.

11.4 Data model layer: proposed relational schema

The slide deck's own ER diagram groups into five functional blocks: registration & configuration (locations, sensor types, sensors, environment conditions), acquisition & events (sessions, events), observations & media (observations, media files, event tags), analysis & interpretation (analysis results, interpretations), and support & references (sensor calibration, users, reference data, the last one holding the normal operating range per sensor dimension used to flag a reading as anomalous). Table and column names are shown exactly as designed on the slide (lowercase snake_case); §11.7 below recommends renaming them to match this repository's existing GDX_ENV_* convention before implementation.

11.5 Processing layer: from sensing to insight

A worked example from the slide deck shows the three stages end to end: synchronized multi-sensor capture around a person in an environment (a stimulus, e.g. the question "Is anyone here?"), time-aligned data streams across every channel (electric field, magnetic field, RF spectrum, audio, infrasound, temperature, photon count, radiation, air quality, all against one GPS/NTP-synchronized time axis), and the resulting event detection and pattern analysis.

In the worked example, a stimulus at 22:31:14 is followed within seconds by a correlated burst across five independent channels: an RF anomaly, a magnetic variation, a detected audio event, a thermal change, and a photon spike. Pattern analysis (temporal correlation, anomaly score, signal classification, noise filtering, cross-sensor validation) feeds an interpretive layer that lists possible presence, possible communication, environmental cause, or unknown event as hypotheses, never as findings. The deck's own framing: "From data to meaning, always with method."

11.6 Interpretation layer: classifying a potential-communication event

Going one level deeper than §11.5, the deck specifies a 4-stage discipline for turning a raw signal into a labeled hypothesis, never skipping a stage:

Methodological note from the deck: the system must keep separate (1) what was measured, (2) what the algorithm recognized, and (3) the meaning assigned to the event. "From data to meaning, always with method."

11.7 Integration layer: folding into GDX_HUMAN's existing conventions

1. Rename to the project's schema convention. The proposed tables should become GDX_ENV_LOCATION, GDX_ENV_SENSOR_TYPE, GDX_ENV_SENSOR, GDX_ENV_SESSION, GDX_ENV_EVENT, GDX_ENV_OBSERVATION, GDX_ENV_ANALYSIS_RESULT, GDX_ENV_INTERPRETATION, and others, with BIGINT surrogate keys via a SEQ_GDX_ENV_* sequence and a BEFORE INSERT trigger, the same Firebird 2.5 pattern every other schema already uses.
2. Link back to the single central person, optionally. A nullable ID_PERSON FK to DW_DIM_PERSON on GDX_ENV_SESSION, nullable because many sessions (e.g. unattended site monitoring) have no single person to attach.
3. Add ID_STUDY for --study scoping, so a future GDX_SKILL_LOAD_ENV_SESSIONS_DB and the knowledge-graph export skill can scope this data exactly the way every other skill built since 2026-09-17 already does.
4. Reuse the project's confidence/classification pattern: the same HIGH/MEDIUM/LOW/SPECULATIVE enum already used by the septenary and Five Ways mapping tables, instead of inventing a new one.

With those four changes, this extension would plug in as Step 13 in the pipeline, feeding the DW (a new DW_FACT_GDX_ENV_EVENT grain) and the knowledge graph (automatically, via the existing introspection-based export) with no redesign of either.

12.0 Appendix: Where to Go Next

Glossary

DW (Data Warehouse): the star-schema analytical layer (folder 7) unifying every OLTP perspective for cross-cutting queries.

ETL: Extract, Transform, Load, the process of moving data from the OLTP schemas into the DW.

CFA / EFA: Confirmatory / Exploratory Factor Analysis, statistical techniques used to validate the CAAS instrument's dimension structure.

HRV / RMSSD / SDNN: Heart Rate Variability and two of its standard time-domain metrics, captured from the device's RR intervals.

gdx_key: the Neo4j node-identity property, always equal to the source table's own primary key.

AUCPR: Area Under the Precision-Recall Curve, the metric used to independently validate Model 1's link-prediction quality on a small, imbalanced label set.

FastRP / Louvain: the two core Neo4j Graph Data Science algorithms used, FastRP for node embeddings (Model 1) and Louvain for community detection (Model 2).

MERGE: the idempotent Cypher write used for every node and relationship, so the knowledge-graph export can be re-run safely without duplicating data.