Add QuMat neutrosophic foundation docs

docs/academic/implementation-to-citation-map.md

@@ -0,0 +1,75 @@
+---
+title: Implementation to Citation Map
+sidebar_label: Implementation to Citation Map
+---
+
+# Implementation to Citation Map
+
+Status: phase-1 citation gate  
+Related issue: [apache/mahout#1372](https://github.com/apache/mahout/issues/1372)
+
+## Rule
+
+Every planned implementation should be in one of three states:
+
+1. `source-backed`
+2. `local design extension`
+3. `unsupported`
+
+Anything still marked `unsupported` should not be presented as if it were ready for implementation.
+
+## Mapping
+
+### NeutroBit carrier over `|0>`, `|1>`, `|I>`
+
+- Status: `source-backed`
+- Primary source:
+  - `Neutrosophic Logic Based Quantum Computing`
+
+### Neutrosophic `W` gate
+
+- Status: `source-backed`
+- Primary source:
+  - `Neutrosophic Logic Based Quantum Computing`
+
+### Neutrosophic `X/Y/Z` family
+
+- Status: `source-backed`
+- Primary source:
+  - `Neutrosophic Logic Based Quantum Computing`
+- Note:
+  - software class shape remains an implementation choice
+
+### Neutrosophic Hadamard
+
+- Status: `source-backed`
+- Primary source:
+  - `Neutrosophic Logic Based Quantum Computing`
+
+### `NeutroGate` software abstraction
+
+- Status: `local design extension`
+- Grounding:
+  - justified by QuMat's gate-oriented API
+- Note:
+  - this is a software abstraction, not a paper-defined class contract
+
+### Projection and comparison harness
+
+- Status: `local design extension`
+- Grounding:
+  - needed to compare a `3`-state reference model against current QuMat qubit semantics
+
+### Direct execution on `qiskit` / `cirq` / `amazon_braket` as neutrobit backends
+
+- Status: `unsupported`
+- Reason:
+  - current repo and current published sources do not justify claiming native `3`-state execution on existing QuMat backends
+
+### Kernel-method bridge into Mahout
+
+- Status: `local design extension`
+- Grounding:
+  - `MAHOUT-2200` confirms kernel-method direction exists
+- Missing:
+  - exact technical bridge remains unproven and should be treated as tentative, not oversold

docs/academic/neutrosophic-operator-layer-bibliography.md

@@ -0,0 +1,104 @@
+---
+title: Neutrosophic Operator Layer Bibliography
+sidebar_label: Neutrosophic Bibliography
+---
+
+# Neutrosophic Operator Layer Bibliography
+
+Status: phase-1 foundation bibliography  
+Related issue: [apache/mahout#1372](https://github.com/apache/mahout/issues/1372)
+
+## Source Selection Rules
+
+Use this precedence:
+
+1. primary papers and journal pages
+2. official project documentation
+3. maintainer-owned issue trackers and talks
+
+This document is intentionally public-safe. It does not rely on unpublished local manuscripts.
+
+## Primary Neutrosophic Sources
+
+### Direct operator and carrier foundation
+
+- Florentin Smarandache et al.  
+  **Neutrosophic Logic Based Quantum Computing**  
+  <https://fs.unm.edu/neut/NeutrosophicLogicBasedQuantum.pdf>
+
+Use in this case:
+
+- neutrobit carrier concept
+- neutrosophic `W`
+- neutrosophic Pauli-style operators
+- neutrosophic Hadamard direction
+
+### Structural neutrosophic foundation
+
+- Florentin Smarandache  
+  **(t, i, f)-Neutrosophic Structures & I-Neutrosophic Structures (Revisited)**  
+  <https://fs.unm.edu/nss8/index.php/111/article/view/484>
+
+Use in this case:
+
+- indeterminacy-bearing structures
+- separation between carrier structure and binary-state assumptions
+
+### Quantum-facing indeterminacy foundation
+
+- Florentin Smarandache  
+  **Neutrosophic Quantum Theory: Partial Entanglement, Partial Effect of the Observer, and Teleportation**  
+  <https://fs.unm.edu/nss8/index.php/111/article/view/6355>
+
+Use in this case:
+
+- quantum-facing indeterminacy language
+- observer and partial-state framing
+
+### Geometry and fractal bridge
+
+- Erick Gonzalez-Caballero, Maikel Y. Leyva-Vazquez, Noel Batista-Hernandez, Florentin Smarandache  
+  **NeutroGeometry and Fractal Geometry**  
+  <https://fs.unm.edu/nss8/index.php/111/article/view/4836>
+
+Use in this case:
+
+- geometric irregularity as a carrier discussion
+- fractal relevance for multi-scale indeterminacy
+
+### Measurement foundation
+
+- Florentin Smarandache  
+  **Neutrosophic Measure and Neutrosophic Integral**  
+  <https://fs.unm.edu/nss8/index.php/111/article/view/3893>
+
+Use in this case:
+
+- explicit measurement rules
+- distinction between indeterminacy and ad hoc scoring
+
+## Official Mahout and QuMat Context
+
+- Apache Mahout  
+  **QuMat**  
+  <https://mahout.apache.org/qumat/>
+
+- Apache Mahout  
+  **Getting Started with QuMat**  
+  <https://mahout.apache.org/docs/qumat/getting-started/>
+
+- Apache JIRA  
+  **MAHOUT-2200 Quantum Kernel Methods research spike**  
+  <https://issues.apache.org/jira/browse/MAHOUT-2200>
+
+- FOSSY 2024  
+  **QuMat: Apache Mahout's Quantum Computing Interface**  
+  <https://2024.fossy.us/schedule/presentation/265/>
+
+## Exclusion Rule
+
+Do not mark an implementation claim as academically grounded if the source provides only:
+
+- general philosophy without operator relevance
+- project marketing without technical surface
+- private or unpublished design intent

docs/index.md

@@ -27,6 +27,11 @@ anywhere.'
 - [Parameterized Quantum Circuits: Developer's Guide](./advanced/pqc) - In-depth guide to PQCs
 - [Qumat Gap Analysis for PQC](./advanced/gap-analysis) - Analysis of PQC capabilities
 
+### Research and RFC Notes
+- [Experimental Neutrosophic Operator Layer for QuMat](./rfcs/experimental-neutrosophic-operator-layer) - Phase-1 RFC for a conservative experimental operator-extension discussion
+- [Neutrosophic Operator Layer Bibliography](./academic/neutrosophic-operator-layer-bibliography) - Published sources used to ground the RFC
+- [Implementation to Citation Map](./academic/implementation-to-citation-map) - Citation gate for distinguishing source-backed items from local design extensions
+
 ### Qumat Components
 - [Qumat (Circuits)](./qumat) - Quantum circuit abstraction layer
 - [QDP (Quantum Data Plane)](./qdp) - GPU-accelerated data encoding

docs/rfcs/experimental-neutrosophic-operator-layer.md

@@ -0,0 +1,152 @@
+---
+title: Experimental Neutrosophic Operator Layer for QuMat
+sidebar_label: Experimental Neutrosophic Operator Layer
+---
+
+# RFC: Experimental Neutrosophic Operator Layer for QuMat
+
+Status: phase-1 foundation draft  
+Related issue: [apache/mahout#1372](https://github.com/apache/mahout/issues/1372)
+
+## Context and Motivation
+
+QuMat already provides a meaningful operator surface for standard quantum-circuit work:
+
+- unified circuit construction
+- standard gate application
+- backend dispatch across `qiskit`, `cirq`, and `amazon_braket`
+- public-facing positioning as Mahout's quantum-computing layer
+
+At the same time, some research directions require a state carrier that is not reducible to a standard qubit. A conservative first step is to treat that need as a reference-model problem, not a backend-rewrite problem.
+
+The immediate goal is therefore modest:
+
+- define a narrow experimental direction
+- keep it separate from production backend semantics
+- anchor it in published sources before any broader implementation claims are made
+
+## Problem Statement
+
+Current QuMat supports standard qubit-oriented gates and backend execution, but it does not provide:
+
+- a non-binary state carrier for indeterminacy-bearing operators
+- an experimental namespace for non-standard operator families
+- a structured comparison surface between standard qubit execution and a richer reference-state model
+
+Without that, the following cannot be explored in a disciplined way:
+
+- neutrobit semantics
+- neutrosophic `W/X/Y/Z/H` gates over a `3x3` carrier
+- comparison studies that preserve the distinction between:
+  - qubit-compatible subspace behavior
+  - genuinely `3`-state neutrosophic behavior
+
+## Proposed Direction
+
+The first increment should remain conservative and local-first.
+
+Suggested shape:
+
+- a `NeutroBit` reference carrier over `|0>`, `|1>`, and `|I>`
+- a `NeutroGate` abstraction for named `3x3` operators
+- a first operator family:
+  - `W`
+  - `X`
+  - `Y`
+  - `Z`
+  - `H`
+- local normalization and measurement utilities
+- a projection and comparison harness against standard QuMat qubit circuits where comparison is mathematically valid
+
+The first goal is observability and reference semantics, not backend replacement.
+
+## Why QuMat Is a Good Candidate
+
+QuMat is a reasonable host for this discussion because it already has:
+
+- a unified operator-facing API
+- documented standard gate semantics
+- explicit backend modularity
+- a live kernel-method direction under `MAHOUT-2200`
+
+The fit is real at the level of:
+
+- experimental operator abstraction
+- comparison harnesses
+- future data-encoding and kernel-method bridges
+- non-breaking extension points
+
+The fit is not yet direct at the level of:
+
+- native `3`-state execution on existing QuMat backends
+- immediate upstream implementation
+- claims that Mahout already supports neutrosophic carriers
+
+## Academic and Technical Foundation
+
+The direct source pack for this direction is documented in:
+
+- [Neutrosophic operator-layer bibliography](../academic/neutrosophic-operator-layer-bibliography.md)
+- [Implementation-to-citation map](../academic/implementation-to-citation-map.md)
+
+Those documents define what is:
+
+- source-backed
+- local design extension
+- unsupported
+
+## Proposed Phased Implementation
+
+### Phase 1 - Reference kernel
+
+Define a local reference-state kernel with:
+
+- carrier semantics
+- operator semantics
+- normalization rules
+- deterministic tests
+
+### Phase 2 - Gate family
+
+Add the first experimental operator family:
+
+- `W`
+- `X`
+- `Y`
+- `Z`
+- `H`
+
+### Phase 3 - Comparison harness
+
+Add a constrained comparison surface between:
+
+- standard QuMat qubit execution
+- projected behavior from the experimental reference carrier
+
+### Phase 4 - Kernel and data-encoding fit analysis
+
+Only after the reference layer is stable, evaluate whether the direction can connect conservatively to Mahout's kernel-method and data-encoding work.
+
+## Explicit Constraints
+
+This RFC does not propose:
+
+- rewriting QuMat backend modules in the first pass
+- changing current production backend semantics
+- claiming native neutrobit execution on `qiskit`, `cirq`, or `amazon_braket`
+- replacing Mahout's current architecture with a new theory-first model
+
+## Open Questions
+
+1. Should a future public proposal stay strictly at the operator-abstraction level?
+2. Should the first comparison harness stay basis-state only?
+3. If kernel-method work becomes the strongest fit, should the operator layer remain purely experimental while only the encoding bridge is discussed publicly?
+
+## Maintainer-Safe Ask
+
+Would QuMat accept a narrowly scoped experimental operator-extension discussion that is:
+
+- explicitly separate from production backend semantics
+- local-reference-first
+- comparison-oriented before implementation-oriented
+- grounded in published academic sources