Research-stage technical gateway for the Sal-Meter / CAIS kernel program.
Current status:
kernel-first · pre-opening · research-stage · non-clinical · non-diagnostic · non-therapeutic · non-surveillance · pre-device · pre-certification · no CAIS compliance granted here
This repository is a public technical helper and implementation index.
It is not:
- a canonical authority layer
- a live public competition
- a certification surface
- a conformance recognition surface
- a clinical, diagnostic, or therapeutic claim surface
- a surveillance or human-ranking surface
- a product launch page
- a commercial-device validation page
- a substitute for DOI / OSF records
Canonical authority remains fixed in DOI-registered records and the official canonical routing structure.
The Salpida Foundation website is the public reading and routing hub.
OSF routes public helper files and DOI-stack indexes where applicable.
GitHub is the technical orientation and builder-facing gateway.
Status first. Kernel first. Claims later.
This repository exists to help serious readers, builders, PIs, laboratories, and technical collaborators enter the correct layer of the Sal-Meter / CAIS kernel program without confusing helper materials with canonical authority.
If you are new, start here before browsing files.
-
Current Status
https://salpida.foundation/status/ -
For PIs and Laboratories
https://salpida.foundation/for-pis/ -
OSF Research Hub — Proxy Benchmark Track
https://osf.io/k6crh/Public research hub and routing layer for the SICS Human-State Proxy Benchmark Track.
OSF routes public helper files, DOI stack indexes, synthetic examples, schema helpers, public boundary checklists, and GitHub helper indexes. -
PI Quick Decision Pack
https://salpida.foundation/publications/pi-quick-decision-pack/ -
Sal-Meter Topic
https://salpida.foundation/topics/sal-meter/ -
CAIS Topic
https://salpida.foundation/topics/cais/ -
Human-State-Aware AI Interaction / Proxy Benchmark Track
https://salpida.foundation/topics/human-state-aware-ai-interaction/ -
Publications Hub
https://salpida.foundation/publications/
This repository is a research-stage technical gateway for the Sal-Meter / CAIS kernel program.
It helps readers understand:
- current execution order
- External Layer-0 route
- I₃⁻ / Aptamer G-Iodine inquiry route
- ESL / EStL recruitment routes
- lab-readiness boundary
- proxy benchmark boundary
- public claims boundary
- future broader-opening boundary
- canonical versus helper-surface distinction
This repository helps builders orient.
It does not define canonical authority.
The program sequence must be read in this order:
External Layer-0
→ SICS Internal Phase 0 (G-only)
→ Phase 1 (I-only)
→ Phase 2a (Twin Mini-Cell)
→ Phase 2b (G+I human pilot)
→ LOCK 1 / LOCK 2
→ Future SDK / broader opening
External Layer-0 is not SICS Internal Phase 0.
External Layer-0 is not Phase 1.
External Layer-0 is an outsourced chemistry-first feasibility support track.
SICS Internal Phase 0 is an internal G-only kernel phase.
Phase 1 is an I-only kernel phase.
Phase 2a is the Twin Mini-Cell stage.
Phase 2b is the G+I human pilot stage.
Broader opening is future-facing and belongs only after LOCK 1 / LOCK 2 review.
The following routes are currently open or being prepared.
For electrochemistry, biosensor, redox, gold-electrode, thiol / disulfide, and controlled perturbation teams.
Core question:
Can iodine redox / thiol-interface behavior produce stable, repeatable, auditable signal behavior under bounded feasibility conditions?
Expected capability:
- iodine redox interface familiarity
- thiol / GSH-GSSG response reasoning
- perturbation-response review
- drift control
- repeatability checks
- mandatory control discipline
- raw data handover
- metadata completeness
- audit trail discipline
This is chemistry-first external feasibility support.
It does not create:
- Sal-Meter validation
- CAIS compliance
- certification
- device designation
- clinical interpretation
- diagnostic interpretation
- therapeutic interpretation
- human-state classification
For aptamer, molecular interface, biosensor, binding-characterization, or sensor-interface groups.
Core question:
Can an I₃⁻-targeted aptamer or aptamer-like molecular interface support a non-therapeutic signal-gating path?
Expected capability:
- I₃⁻ target-oriented development support
- binding characterization
- selectivity review
- cross-reactivity review
- immobilization suitability thinking
- sensor-interface compatibility
- sequence / data / IP handover discipline
- publication boundary discipline
This workstream is a non-therapeutic signal-interface component track.
It is not:
- a drug track
- a treatment track
- a diagnostic track
- a clinical-use track
- a final CAIS compliance determination
- a certified Sal-Meter component designation
ESL = Experimental Stability Lead
The ESL is responsible for physical consistency.
Needed strengths:
- electrochemical measurement discipline
- bench stability
- electrode behavior
- cartridge / chamber logic
- drift control
- repeatability
- SOP stability
- calibration discipline
- troubleshooting structure
- external Layer-0 result review
First 30-day output:
- current measurement-risk map
- Layer-0 feasibility review checklist
- minimum internal lab readiness list
- drift / repeatability / control checklist
- External Layer-0 technical review support
- equipment and consumable readiness logic
The ESL owns the question:
Is the physical measurement system stable enough to trust the next step?
EStL = Evidence & Statistical Traceability Lead
The EStL is responsible for evidence consistency.
Needed strengths:
- metadata schema
- QC checklist
- leakage prevention
- audit trail
- raw data package logic
- reproducibility pack
- holdout design
- reporting discipline
- version-aware documentation
- public-claims review discipline
First 30-day output:
- metadata schema v0.1
- evidence package checklist
- raw data handover checklist
- leakage-prevention rules
- PI / lab submission review structure
- public-claims review checklist
- reproducibility package outline
The EStL owns the question:
Is the evidence structure traceable enough to survive review?
Internal lab buildout is not the first public claim.
It is an execution readiness layer.
The lab-readiness route should focus on:
- equipment list discipline
- procurement priority
- sample-handling boundary
- data capture workflow
- metadata capture workflow
- calibration worksheet
- raw data storage policy
- audit trail setup
- internal review cadence
- role split between ESL and EStL
This route must remain research-stage and non-clinical.
It must not imply:
- clinical readiness
- device readiness
- commercial readiness
- CAIS compliance
- certified Sal-Meter status
- validated Sal-Meter status
Proxy benchmark preparation is a support track only.
It is not:
- the Sal-Meter core signal track
- a CAIS-compliant device implementation
- a validated substitute for Sal-Meter
- a clinical, diagnostic, or therapeutic tool
- a surveillance system
- a human-ranking system
Purpose:
- synchronized multimodal benchmark platform
- ECG / HRV / EDA / PPG / optional EEG / eye / gaze support
- metadata discipline
- labeling structure
- leakage control
- baseline models
- dashboard and edge-inference preparation
- future A/B comparison surface when Sal-Meter core signals become available
Public data rule:
No raw human data should be published here.
Public examples should use sample, synthetic, mock, toy, placeholder, or schema-only materials.
Proxy benchmark route:
https://github.com/salpida-foundation/proxy-benchmark-track
OSF public research hub:
The following are not currently active public routes:
- no live public competition
- no public SDK release
- no certified Sal-Meter
- no validated commercial Sal-Meter device
- no clinical or diagnostic use
- no therapeutic positioning
- no surveillance route
- no human-ranking route
- no CAIS compliance claim by participation
- no proxy stack as Sal-Meter
- no broad external build race
- no public raw human data repository
- no production closed-loop intervention system
First, stabilize the kernel.
Then, open the field.
Some future-facing documents or contact-surface notes may be added later under docs/.
These materials should be treated only as future candidate pathways.
They must not state or imply that:
- a Sal-Meter-compatible node already exists
- broad public opening is currently live
- the public SDK has been released
- proxy benchmark outputs are Sal-Meter outputs
- participation grants CAIS compliance
- a GitHub helper file creates certification
- External Layer-0 is the same as SICS Internal Phase 0
Preferred wording:
future candidate pathway
future contact surface
future integration boundary
not currently live
not validated here
not CAIS compliance
not Sal-Meter designation
post-lock candidate route
Do not use:
Sal-Meter-compatible node exists
validated node
certified node
CAIS-compliant integration
live broad opening
public SDK released
official Sal-Meter node
Future candidate helper documents may include:
docs/
future-contact-surface-integration.md
future-sal-meter-compatible-node-boundary.md
cais-node-to-human-state-packet-mapping.md
sal-meter-derived-state-summary-boundary.md
These are not active routes yet.
They should be created only when the program reaches the appropriate post-lock or future-integration stage.
Until then, these names should be treated as reserved candidate paths, not active implementation claims.
Contact us only if you can own one bounded layer.
Good fit if you can reduce uncertainty around:
- iodine redox behavior
- thiol / disulfide perturbation response
- gold-electrode electrochemistry
- baseline stability
- repeatability
- drift control
- raw data and metadata handover
Good fit if you can reduce uncertainty around:
- I₃⁻ target feasibility
- aptamer or binding interface design support
- selectivity and cross-reactivity
- immobilization suitability
- molecular recognition structure
- signal-interface compatibility
- sequence / data / IP discipline
Good fit if you can own:
- physical measurement stability
- electrochemical system consistency
- SOP discipline
- drift and repeatability controls
- internal lab readiness
- external feasibility result review
Good fit if you can own:
- evidence structure
- metadata completeness
- QC and audit trail
- leakage prevention
- reproducibility package logic
- submission and review discipline
- public-claims boundary review
Good fit if you can own:
- synchronized biosignal capture
- LSL / BrainFlow / Timeflux-style architecture
- metadata schema
- labeling discipline
- leakage-safe baseline modeling
- lightweight dashboard
- sample / synthetic dataset preparation
- raw-data-non-public governance
Send a short, bounded-fit message.
Email:
Subject line examples:
External Layer-0 feasibility inquiry — [Lab / Institution Name]
I₃⁻ / Aptamer G-Iodine development inquiry — [Lab / Institution Name]
ESL candidate inquiry — [Name]
EStL candidate inquiry — [Name]
Proxy benchmark support inquiry — [Name / Team]
Your first email should include:
- who you are
- which route you fit
- one capability you can actually own
- one uncertainty you can reduce
- whether a bounded 3–6 month feasibility or readiness path is realistic
- whether raw data / metadata / audit trail requirements are acceptable
Do not send a broad partnership pitch first.
Send one bounded capability.
Subject: [Route] inquiry — [Name / Lab / Team]
Dear Salpida Foundation / SICS team,
I am contacting you regarding the following route:
[Choose one]
- External Layer-0 feasibility inquiry
- I₃⁻ / Aptamer G-Iodine development inquiry
- ESL candidate inquiry
- EStL candidate inquiry
- Proxy benchmark support inquiry
My relevant capability is:
[Write 3–5 lines: lab type, method, instrument, technical skill, or evidence capability]
The specific uncertainty I may help reduce is:
[Write one bounded uncertainty]
A realistic first scope could be:
[Write a narrow 3–6 month feasibility, review, or readiness scope]
I understand that the current program is research-stage, pre-opening, non-clinical, non-diagnostic, and non-therapeutic. I also understand that GitHub is a helper surface and that canonical authority remains fixed in DOI / OSF records.
Best regards,
[Name]
[Role]
[Institution / Team]
[Email]
[Relevant link, if any]
Current helper structure:
docs/
current-operating-model.md
authority-boundary.md
public-claims-guide.md
for-layer0-labs.md
aptamer-giodine-workstream.md
esl-estl-recruitment.md
for-pis-and-lab-leads.md
for-engineers.md
for-researchers-and-scholars.md
PI_Quick_Decision_Pack.md
document-map.md
faq.md
roadmap.md
where-help-is-most-needed.md
how-to-engage.md
who-we-want-to-meet.md
what-a-good-contribution-looks-like.md
Future candidate helper structure:
docs/
future-contact-surface-integration.md
future-sal-meter-compatible-node-boundary.md
cais-node-to-human-state-packet-mapping.md
sal-meter-derived-state-summary-boundary.md
Some documents may be revised as the current public surface is aligned.
When in doubt, read Status first.
OSF hub:
Role:
- public research hub
- DOI stack index
- public routing layer
- synthetic example organizer
- schema helper organizer
- public boundary checklist organizer
- GitHub helper index organizer
OSF is not:
- canonical authority by itself
- Sal-Meter validation
- CAIS compliance
- clinical authority
- diagnostic authority
- therapeutic authority
- certification authority
- human-ranking authority
This repository:
https://github.com/salpida-foundation/sal-meter-kernel-program
Role:
- technical orientation surface
- builder-facing gateway
- current route map
- PI / lab / candidate orientation layer
- helper document index
- future implementation support layer
GitHub is not:
- canonical authority
- certification
- conformance recognition
- benchmark validation
- Sal-Meter validation
- CAIS compliance
- device readiness
- clinical readiness
Proxy repository:
https://github.com/salpida-foundation/proxy-benchmark-track
Role:
- synchronized multimodal benchmark helper
- synthetic/sample-data structure
- schema helper route
- public boundary route
- dashboard / closed-loop demo-lite boundary route
- future Sal-Meter A/B comparison support route
Proxy benchmark is not:
- Sal-Meter
- CAIS compliance
- clinical evidence
- diagnostic output
- therapeutic system
- surveillance route
- human-ranking surface
Canonical authority remains fixed only in DOI / OSF records and the Salpida Foundation canonical routing structure.
Canonical records define:
- what the system is
- what it is not
- what counts as boundary compliance
- what public claims are allowed
- what public claims are not allowed
- when terminology may be used
- what designation requires review
- what cannot be claimed by helpers, forks, or participants
GitHub exists to:
- orient technical readers
- show current routes
- reduce confusion
- help candidates understand fit
- route PIs, labs, and contributors to the right next document
- support implementation once the boundary is understood
- keep public helper materials auditable
GitHub does not override canonical authority.
No public helper surface should publish:
- raw human biosignals
- identifiable participant data
- private session logs
- clinical records
- health records
- consent forms containing personal information
- internal lab packages
- unpublished human-subject datasets
- private CAIS conformance materials
- Sal-Meter raw core input unless separately governed
- production feedback logs
- private user data
Public helper materials should remain:
- documentation
- structure-only notes
- public boundary notes
- route files
- helper schemas
- synthetic examples
- sample examples
- mock examples
- toy examples
- placeholder examples
- issue templates
- public technical orientation files
Use:
research-stage
pre-opening
kernel-first
non-clinical
non-diagnostic
non-therapeutic
non-surveillance
pre-device
pre-certification
CAIS-aligned research path
External Layer-0 feasibility support
I₃⁻ / Aptamer G-Iodine development inquiry
proxy benchmark support track
future broader opening
post-lock SDK
Do not use:
validated Sal-Meter
certified Sal-Meter
CAIS-compliant device
clinical use
diagnostic use
therapeutic platform
live public competition
commercial device
proxy stack as Sal-Meter
Sal-Meter-compatible node exists
public SDK released
official conformance result
Contributions may include:
- documentation improvement
- boundary clarification
- typo correction
- route clarification
- issue template improvement
- public helper wording improvement
- schema-helper discussion
- synthetic/sample data structure discussion
- leakage-control helper notes
- reproducibility helper notes
Contributions must not include:
- raw human data
- real participant data
- clinical data
- health records
- private session logs
- diagnostic claims
- therapeutic claims
- surveillance logic
- human-ranking logic
- Sal-Meter validation claims
- CAIS compliance claims
- certification claims
- sequence generation
- wet-lab recipe
- protocol optimization parameters
Proceed with:
- current README
- public route clarification
- External Layer-0 inquiry routing
- I₃⁻ / Aptamer G-Iodine inquiry routing
- ESL / EStL recruitment routing
- lab-readiness boundary
- proxy benchmark support boundary
- OSF / GitHub / website route alignment
- public helper documentation
Proceed only with explicit boundary controls:
- dashboard demos
- closed-loop demo-lite materials
- human-session examples
- participant-facing templates
- benchmark result summaries
- model performance summaries
- public GitHub examples
- future contact-surface documents
Required controls:
- no raw human data
- no private labels
- no diagnostic claims
- no therapeutic claims
- no surveillance claims
- no Sal-Meter validation claims
- no CAIS compliance claims
- no live broad-opening claim
Hold:
- public raw human datasets
- real participant session logs
- public clinical interpretation
- production closed-loop intervention
- claims of validated benchmark performance
- broad public competition language
- Sal-Meter certification language
- CAIS-compliant device language
- Sal-Meter-compatible node language
- public SDK release language
Do not publish:
- raw human data
- identifiable participant data
- clinical claims
- diagnostic claims
- therapeutic claims
- human-ranking claims
- employment or insurance eligibility claims
- surveillance workflows
- coercive monitoring workflows
- public claims of validated Sal-Meter
- public claims of CAIS-compliant device status
- public claims of certification or official conformance
- biological sequence generation
- wet-lab recipes or optimization parameters
Recommended GitHub About text:
Research-stage technical gateway for the Sal-Meter / CAIS kernel program: External Layer-0, I₃⁻ aptamer inquiry, ESL/EStL recruitment, lab readiness, and proxy benchmark boundary. Not a live competition. Not CAIS compliance.
Use no more than 20 topics.
signal-processing
open-hardware
open-science
biosensors
electrochemistry
cais
aptamer
ai-governance
consciousness-measurement
aptamer-sensing
redox-sensing
consciousness-science
sal-meter
iodine-redox
state-separability
consciousness-like-signal
Primary contact:
Public hub:
Current status:
https://salpida.foundation/status/
For PIs:
https://salpida.foundation/for-pis/
GitHub organization:
https://github.com/salpida-foundation
This repository is a door.
It is not the throne.
It may guide the builder.
It must not crown the result.
The kernel may be prepared in public view.
Its authority remains locked in DOI records.
Claims must never run ahead of proof.