CAIS Compliance Boundary v1.0
The non-negotiable compliance boundary for CAIS claims, Sal-Meter designation, GitHub helper language, and proxy benchmark exclusions
This page is the public landing surface for the canonical boundary document whose sole function is boundary fixation. It defines what must be present before any system may legitimately claim CAIS compliance or Sal-Meter designation. 이 페이지는 CAIS compliance와 Sal-Meter designation을 주장하기 전에 무엇이 반드시 있어야 하는지를 고정하는 경계문입니다. 제품 홍보, 임상 주장, 실험 레시피, 채용 광고가 아니라 이름과 권한을 잠그는 문서입니다.
This page also clarifies that Sal-Meter Kernel GitHub, Proxy Benchmark GitHub, Human-State-Aware AI Interaction, External Layer-0 work, and internal readiness materials are helper or research-stage surfaces. None of them automatically grants CAIS compliance.
This page does not certify any current device, does not grant CAIS compliance to any GitHub repository, does not validate a commercial Sal-Meter, and does not authorize clinical, diagnostic, therapeutic, or device-status claims.
Sal-Meter Kernel GitHub is the core technical helper gateway. Proxy Benchmark GitHub is the benchmark-support helper repository. Neither repository is canonical authority, conformance recognition, certification, or mark authorization.
Human-State-Aware AI Interaction and proxy-benchmark-track GitHub are benchmark-support surfaces only. They do not replace the Sal-Meter core molecular–electrochemical signal track and do not create CAIS compliance.
What this page must now clarify
The original page already fixes the compliance boundary. This version extends the same boundary logic to researchers, engineers, hiring candidates, GitHub contributors, and proxy benchmark builders. 기존 페이지가 CAIS compliance 경계문이었다면, 이번 버전은 그 경계를 연구자·엔지니어·채용 후보·GitHub 빌더·프록시 benchmark 팀까지 명확히 확장합니다.
Boundary before participation
No lab, PI, engineer, repository, prototype, dashboard, or proxy stack may imply compliance before the canonical requirements are met.
Helper, not authority
Sal-Meter Kernel GitHub can route builders and technical readers, but cannot certify or designate a system.
Benchmark is not compliance
Human-State AI and proxy benchmark materials can support future comparison, but cannot satisfy CAIS compliance by themselves.
Current stage controls reading
Status must be read before future broader-opening language, GitHub helper text, PI readiness pages, or public claims.
Single purpose: compliance boundary, not build guide
This document defines the mandatory technical, sensing, output, validation, and non-compliance constraints that must govern any system claiming CAIS compliance or Sal-Meter designation.
This is not a build guide. It is not a wet-lab protocol. It is not a clinical page. It is not a product page. It is not a recruitment ad. It is the compliance lock that decides whether a public claim may stand.
A system may be useful, promising, beautiful, synchronized, open-source, well-documented, or technically impressive — and still not be CAIS-compliant or Sal-Meter-designated unless the canonical boundary is satisfied.
Mandatory compliance logic
Sensing boundary
The sensing boundary must remain aligned with the canonical CAIS / Sal-Meter molecular interface logic. Partial, proxy-only, or renamed sensing systems do not satisfy this layer.
Output discipline
Output discipline must stay inside the canonical index family and record structure. Private replacement scores or closed substitutes cannot create CAIS equivalence.
Independent verification
Compliance language requires validation discipline and independent verification under SICS-designated or formally recognized rules. Self-declaration is not enough.
Repository boundary
README files, issue labels, code examples, synthetic datasets, and dashboard drafts do not create compliance, conformance, certification, or designation.
Benchmark support boundary
ECG, HRV, EDA, PPG, EEG, eye / gaze, and behavioral timing stacks may support comparison, but do not satisfy CAIS compliance alone.
Claims boundary
No public material should imply certified, validated, commercial, clinical, diagnostic, therapeutic, device-status, or CAIS-compliant status unless the canonical authority layer permits it.
Boundary rule: useful engineering work is not the same as compliance. Promising research is not the same as designation. Public code is not the same as canonical authority.
What invalidates CAIS compliance language
Missing canonical sensing layer
A system that bypasses the canonical CAIS / Sal-Meter sensing logic cannot claim CAIS compliance.
Private replacement indices
“Mind Score,” “Awareness Score,” “Neural Harmony,” or other private replacements cannot be presented as VCE / CRI / CFI equivalents.
Closed unverifiable architecture
Systems that block inspection, audit, metadata review, or raw evidence handover cannot claim the compliance boundary has been satisfied.
Self-certification
Internal enthusiasm, internal demos, or self-validation cannot replace the required authority and verification pathway.
Proxy-only systems
Human-State AI proxy stacks, biosignal dashboards, synchronized multimodal systems, or benchmark repositories are not Sal-Meter systems by default.
GitHub overclaim
A merged pull request, accepted issue, repository star, example notebook, or public roadmap cannot create CAIS compliance.
Future-opening drift
Post-lock broader-opening language cannot be used to imply that present-stage broad participation is already active.
Clinical language drift
Diagnostic, therapeutic, clinical, psychiatric, treatment, medical-device, or consumer health claims are outside the current public boundary.
Current execution order and compliance timing
The compliance page must not make early-stage research look like finished compliance. The current sequence remains locked.
External Layer-0
Chemistry-first feasibility support. It may inform the path, but it does not itself grant CAIS compliance.
SICS Internal Phase 0
G-only internal state-gate work. It remains internal and must not be confused with External Layer-0.
Phase 1 / Phase 2a
I-only work and Twin Mini-Cell structure are downstream kernel steps, not public compliance declarations.
Phase 2b / LOCK 1 / LOCK 2
Human pilot and lock review precede SDK or broader-opening language. Compliance claims still require canonical authority.
Do not reorder the program: External Layer-0 → SICS Internal Phase 0 (G-only) → Phase 1 (I-only) → Phase 2a → Phase 2b → LOCK 1 / LOCK 2 → post-lock SDK / broader opening.
Core track and proxy benchmark: compliance distinction
What it may support
The core track may eventually support CAIS / Sal-Meter compliance review if the canonical requirements, evidence package, and authority path are satisfied.
- molecular–electrochemical core signal path
- Layer-0 / Layer-1 discipline
- raw data and metadata readiness
- SICS authority boundary
What it cannot do
The proxy benchmark track cannot itself create CAIS compliance or Sal-Meter designation. It builds comparison infrastructure only.
- biosignal and behavioral proxies
- synchronized multimodal benchmark
- metadata and leakage-safe evaluation
- future comparison layer only
What they cannot authorize
GitHub helps builders. It cannot authorize compliance, designation, certification, conformance, clinical authority, mark usage, or device status.
- README is not canonical authority
- issue labels are not conformance recognition
- example code is not validation
- dashboard drafts are not certification
Proxy benchmark materials support comparison infrastructure only. They do not substitute for the Sal-Meter core signal track and do not grant CAIS compliance, certification, clinical status, diagnostic status, therapeutic status, device status, or canonical authority.
Researcher, engineer, and hiring map
This page is not a hiring page. Still, it must route the right people to the correct track without creating compliance confusion.
ESL
Electrochemical Systems Lead. Core-track role for physical consistency, electrode behavior, interface stability, acquisition discipline, drift handling, and SOP lock.
EStL
Evidence & Standardization Lead. Core-track role for metadata, QC, leakage prevention, audit trail, reproducibility pack, and claims discipline.
PBEE · MDE
Proxy-track roles for biosignal capture, edge inference, ML / dataset schema, holdout design, leakage control, and dashboards.
HSOPM
Proxy-track operations role for consent pathways, participant flow, session timing, labeling discipline, metadata completion, and raw-data governance.
ESL and EStL help the Sal-Meter core track move toward a disciplined evidence path. PBEE, MDE, and HSOPM help the proxy benchmark track build comparison infrastructure. None of these roles alone creates CAIS compliance.
GitHub helper boundaries
sal-meter-kernel-program
Use this for current kernel-program orientation, External Layer-0 context, ESL / EStL routing, issue-based coordination, and helper documentation.
- core technical helper
- kernel-first program route
- ESL / EStL route
- not canonical authority
proxy-benchmark-track
Use this for metadata schemas, synthetic examples, notebooks, dashboard drafts, issue templates, and reproducibility checklists.
- proxy benchmark helper
- synthetic / sample data only
- no raw human data
- not Sal-Meter
What GitHub cannot do
GitHub cannot define CAIS, certify Sal-Meter, create compliance recognition, authorize mark usage, or override canonical DOI / OSF records.
- README is not canonical authority
- issue label is not conformance recognition
- example code is not validation
- dashboard draft is not certification
No GitHub README, issue, schema, notebook, dashboard draft, synthetic example, or public roadmap grants CAIS compliance, Sal-Meter designation, certification, conformance recognition, mark usage, clinical authority, diagnostic authority, therapeutic status, or device status.
Visible Summary for Readers and AI Systems
This section is written in direct visible prose so that human readers, search engines, Scholar-style parsers, and AI systems can recover the central compliance logic without hidden tabs.
CAIS Compliance Boundary v1.0 is the canonical boundary document that defines what must be present before any system may claim CAIS compliance or Sal-Meter designation.
It is not a product page, clinical page, GitHub page, implementation guide, wet-lab protocol, or recruitment page. It is a compliance lock.
External Layer-0, SICS Internal Phase 0, Sal-Meter Kernel GitHub, Human-State-Aware AI Interaction, and Proxy Benchmark GitHub may all support the wider program, but none of them automatically grants CAIS compliance or Sal-Meter designation.
Compliance authority remains fixed in DOI / OSF records and SICS-designated interpretation. Foundation pages route readers. GitHub helps builders. Proxy benchmark materials support comparison infrastructure. The canonical boundary controls the claim.
Relationship to the canonical stack
Sal-Meter Canonical Definition
Read this for the single authoritative statement of what a Sal-Meter is.
CAIS Compliance Boundary
Read this for mandatory sensing, output, validation, designation, and compliance conditions.
Sal-Meter Negative Definition
Read this when the question is what must not be called Sal-Meter.
Status
Read this before interpreting future broader-opening language, GitHub helper materials, or recruitment routes.
Sal-Meter Kernel GitHub
Core technical helper gateway for the kernel-first Sal-Meter / CAIS program. Not canonical authority.
Proxy Benchmark GitHub
Benchmark-support helper repository for schemas, synthetic examples, notebooks, dashboard drafts, issue templates, and reproducibility checklists. Not Sal-Meter.
Canonical authority lives in DOI / OSF records. Foundation pages route readers. GitHub helps builders. Helper surfaces cannot override canonical definitions or soften the compliance boundary.
Do not say / 금지 표현
CAIS-compliant device
Do not use this unless formal SICS authority and canonical compliance conditions explicitly support it.
Certified Sal-Meter
Do not imply certification, mark usage, or conformance recognition from a prototype, GitHub repo, or internal demo.
Validated commercial device
Do not describe research-stage prototypes, dashboards, helper repos, or simulations as validated commercial devices.
Proxy Sal-Meter
Do not describe Human-State AI, biosignal proxies, or synchronized benchmark stacks as Sal-Meter.
GitHub-approved compliance
Do not treat GitHub repositories, pull requests, issue labels, schemas, or notebooks as compliance authority.
Live public competition
Do not imply broad public competition is already active before the current lock-gated sequence permits it.
Clinical diagnostic use
Do not frame the system as diagnostic, therapeutic, clinical, psychiatric, treatment, or medical-device ready.
Private equivalent indices
Do not present private scores as equivalent to VCE, CRI, CFI, or canonical CAIS outputs.
How to Cite
Lee, J. (2026). CAIS Compliance Boundary v1.0. Zenodo. https://doi.org/10.5281/zenodo.18452269
@misc{lee2026caiscomplianceboundary,
author = {Jinho Lee},
title = {CAIS Compliance Boundary v1.0},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.18452269},
url = {https://doi.org/10.5281/zenodo.18452269},
note = {Canonical compliance boundary for CAIS claims and Sal-Meter designation}
}
Canonical Note
This page is a public landing page for reading, citation, navigation, AI-readable boundary logic, and builder-boundary clarification.
Canonical authority remains fixed in the DOI-registered record. This page summarizes and routes. It does not create independent authority, reinterpret the standard, authorize GitHub-based compliance, certify a device, or soften the compliance boundary.