Project: OBINexus — NSIGII Human Rights Protocol
Status: Stable Milestone
Date: March 5, 2026
Author: Nnamdi Okpalan
1. Introduction: System and Components
NSIGII (Scripting for command-and-control verification) defines a No-Rollback Abstract Binary Instruction Interface callable through native FFI from any polyglot binding. The architecture operates on a firmware-level control loop where human-in-the-loop verification governs all state transitions.
The core principle: there is no rollback. State transitions are irreversible in the traditional sense. Instead, NSIGII provides Filter (mutation/transformation) and Flash (storage/persistence) as complementary operations that achieve forward-only state evolution through undo/redo sequencing — not rollback.
Key Components
- Controller: The human-in-the-loop agent issuing directives and verifying consensus
- Actuator: The execution unit performing the trait/transformation dictated by the controller
- System Loop: The closed feedback cycle between controller and actuator, mediated by the NSIGII protocol
- Filter: A mutable transformation stage — read, transform, pass forward (analogous to a pipeline filter)
- Flash: A persistent storage stage — capture, save, update (analogous to firmware flash write)
Control Flow Diagram
Human (Controller)
│
▼
┌──────────────┐
│ NSIGII │◄──── Consensus Verification
│ Protocol │ (Want? Need? Should?)
│ Layer │
└──────┬───────┘
│
▼
┌──────────────┐ ┌──────────────┐
│ Filter │────►│ Flash │
│ (Transform) │ │ (Storage) │
│ Mutate/Redo │ │ Save/Update │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
┌──────────────────────────────────┐
│ Actuator (Execution) │
│ Performs the trait on target │
└──────────────────────────────────┘
2. The Firmware Update Model
The NSIGII interface treats all code as firmware — a stable binary blob loaded into a system interface. The update process follows this sequence:
- Code Blob Load: The stable milestone binary is loaded into the firmware system interface
- Trait Transformation: The incoming code is decomposed into traits (behavioral units)
- Actuator Execution: Traits are performed by the actuator under controller supervision
- Analog Joystick Metaphor: The Python/C control file provides an "analog joystick" — a continuous control surface for the system, not a discrete switch. This allows fine-grained human-in-the-loop steering of the firmware update process
- Loop Closure: The system loop feeds actuator output back to the controller for verification
3. Controller and Actuator Roles
| Role | Function | Analogy |
|---|---|---|
| Controller | Issues directives, verifies consensus, steers the system | Human holding the joystick |
| Actuator | Executes traits, performs transformations, reports state | Motor responding to joystick input |
| Filter | Transforms data in transit, applies mutations | Signal processing stage |
| Flash | Persists state, commits updates to storage | Firmware write operation |
| NSIGII Protocol | Mediates all interactions, enforces no-rollback | The bus connecting everything |
The controller/actuator relationship follows the rectangle driver model from the Isomorphic Binding Architecture: asymmetric interfaces forming request/response pairs, where the controller requests and the actuator responds.
4. Package Format and Module Integration
4.1 The .nsigii Package Envelope
A .nsigii file is a package envelope that wraps standard archive formats while enforcing NSIGII protocol semantics:
obinexus_mailable_.zip → obinexus_mailer.zip.nsigii
(raw archive) (NSIGII envelope)
The .nsigii suffix signals that the archive is subject to NSIGII no-rollback semantics during extraction and loading.
4.2 Extraction and Traversal Loading
# Step 1: Import the NSIGII envelope as a standard zip
from zipfile import ZipFile
# Step 2: Extract contents
with ZipFile("obinexus_mailer.zip.nsigii", 'r') as archive:
archive.extractall("./workspace")
# Step 3: Traverse-load by dependency
# "Load by need" — modules are imported only when their
# dependencies (physical imports) are satisfied
import nsigii.transition as transition
import nsigii.filter as filter_module
# Step 4: Apply Filter (transform) then Flash (save)
filtered_state = filter_module.transform(raw_input)
flash_module.save(filtered_state)
flash_module.update(filtered_state)
# Step 5: Hand off to the next stage in the polyglot pipeline
handoff(filtered_state, target="lua")
4.3 Physical Import Resolution ("Load by Need")
Modules inside the .nsigii package are not loaded eagerly. Instead, the NSIGII loader performs physical import transition: it traverses the dependency graph and loads only the modules whose physical dependencies (shared libraries, FFI targets, data files) are present on the host system. This ensures that a polyglot package can be deployed to heterogeneous targets without bundling unused bindings.
5. Polyglot FFI Bridge: Python ↔ Lua
5.1 The Bidirectional Pipeline
Once the Python side completes its Filter→Flash cycle, the processed state is handed to Lua through the FFI bridge. Lua then performs its own execution cycle:
Python (main.py) Lua (main.lua)
┌──────────────┐ ┌──────────────┐
│ import ctypes │ │ local ffi = │
│ │ │ require("ffi")│
│ Filter → │──── Binary ──────►│ │
│ Flash → │ Protocol │ Own Filter → │
│ Handoff │ │ Own Flash → │
└──────────────┘ │ Own Execute │
└──────────────┘
5.2 Native FFI Entry Points
Python side — uses ctypes to call into libpolycall.so:
import ctypes
libpolycall = ctypes.CDLL("libpolycall.so")
libpolycall.nsigii_filter.argtypes = [ctypes.c_void_p, ctypes.c_size_t]
libpolycall.nsigii_filter.restype = ctypes.c_void_p
# Transform through the canonical IR
result = libpolycall.nsigii_filter(data_ptr, data_len)
Lua side — uses LuaJIT FFI to call the same shared library:
local ffi = require("ffi")
ffi.cdef[[
void* nsigii_filter(void* data, size_t len);
int nsigii_flash(void* state, const char* target);
]]
local libpolycall = ffi.load("polycall")
-- Execute through same canonical IR
local result = libpolycall.nsigii_filter(data, data_len)
libpolycall.nsigii_flash(result, "main.lua")
5.3 Polyglot No-Rollback Guarantee
The filtering is the transformation. When data passes from Python → C FFI → Lua, each stage applies a Filter (mutate forward) and Flash (persist state). Because each language binding is a driver (rectangle/asymmetric interface) communicating through the Canonical IR, the transformation is lossless and forward-only. There is no mechanism to "roll back" a filter — only to apply a new filter that undoes the previous one (redo/undo semantics).
6. No-Rollback Philosophy: Undo/Redo via SemVerX
6.1 Why No Rollback?
Traditional rollback destroys state. NSIGII rejects this. Instead:
- Undo = Apply an inverse filter that transforms state backward toward a previous form
- Redo = Reapply the original filter, moving state forward again
- Every state is preserved — nothing is destroyed, only transformed
This is philosophically aligned with the NSIGII human rights protocol: no erasure, no ghosting, no disappearance of state.
6.2 SemVerX Versioning
Package versioning follows SemVerX (extended Semantic Versioning):
major.minor.patch[-filter][-flash]
Examples:
1.0.0 — Initial stable release
1.0.1-filter — Patch with transformation applied (mutation)
1.0.1-flash — Patch with state persisted (storage)
1.1.0-filter — Minor version with new filter capability
2.0.0-flash — Major version with breaking storage change
6.3 The Wheel Model for Update Packaging
Updates are distributed as a wheel — a cyclic package format where:
┌────────── Wheel ──────────┐
│ │
│ ┌─────┐ ┌─────┐ │
│ │Undo │◄───►│Redo │ │
│ └──┬──┘ └──┬──┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ │
│ │ Filter → Flash │ │
│ │ (Transform → │ │
│ │ Persist) │ │
│ └─────────────────┘ │
│ │
│ SemVerX: M.m.p-f-F │
│ │
└────────────────────────────┘
The wheel rotates forward (filter→flash→filter→flash) and can be turned backward (undo) or forward again (redo), but the wheel itself is never removed — the state history is continuous and unbroken.
6.4 Red-Black Tree Version Index
The SemVerX version history is indexed as a Red-Black Tree (RBT), not an AVL tree. The choice is deliberate: NSIGII is insert-heavy (no-rollback means versions only accumulate, never delete), and RBT offers fewer rotations on insertion than AVL while maintaining O(log n) lookup.
Each version node in the tree carries paired filter/flash states:
Version Node Structure:
┌──────────────────────────────────────────┐
│ Version: major.minor.patch │
│ Color: RED | BLACK │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ .filter │ │ .flash │ │
│ │ (transform │ │ (persisted │ │
│ │ state) │ │ state) │ │
│ └─────────────┘ └─────────────┘ │
│ │
│ left* ── right* ── parent* │
└──────────────────────────────────────────┘
At each semantic level, filter and flash form a pair:
| Level | Filter State | Flash State |
|---|---|---|
| major |
major.filter — breaking transformation applied |
major.flash — breaking state persisted |
| minor |
minor.filter — new capability transformed in |
minor.flash — new capability persisted |
| patch |
patch.filter — fix/mutation applied |
patch.flash — fix committed to storage |
The RBT properties map directly to NSIGII guarantees:
- Root is BLACK → The initial release (1.0.0) is always a stable, committed (flash) state
- Red nodes cannot be adjacent → Two consecutive filter operations without an intervening flash are invalid (you must persist before transforming again)
- Equal black-depth on all paths → Every version lineage has the same number of committed (flash) checkpoints, ensuring no branch of the version tree is under-persisted
- Insert-only → No-rollback means nodes are never deleted from the version tree; the tree only grows, recolors, and rotates
6.5 Why Red-Black over AVL for Version Indexing
The original Isomorphic Binding Architecture references Huffman-AVL for AST isomorphism at the Canonical IR layer. That remains correct for the data transformation path (where lookups dominate). But the version index has different access patterns:
| Property | AVL | Red-Black | NSIGII Version Index |
|---|---|---|---|
| Balancing strictness | Strict (±1) | Relaxed (2x height ratio) | Relaxed is sufficient — versions are monotonic |
| Insertion cost | More rotations | Fewer rotations | Insert-heavy (no-rollback = append-only) |
| Deletion cost | Complex | Manageable | N/A — no deletion in no-rollback |
| Lookup speed | Slightly faster | Slightly slower | Acceptable — version lookup is infrequent vs. insertion |
| Real-world use | Database indices | OS schedulers, std::map
|
Cross-platform package management |
RBT wins for the version tree because NSIGII never deletes version nodes, making the insertion-optimized RBT a natural fit.
6.6 The Trident Wheel: Cross-Platform No-Rollback Infrastructure
The wheel is the no-rollback polyglot infrastructure deployed across the Trident platform — the three target operating system families:
┌─────────────────── Trident Wheel ───────────────────┐
│ │
│ ┌──────────────┐ │
│ │ RBT Version │ │
│ │ Index │ │
│ └──────┬───────┘ │
│ │ │
│ ┌───────────┼───────────┐ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Windows │ │ macOS │ │Unix/Linux│ │
│ │ .exe │ │ .app │ │ ELF/.so │ │
│ │ MSI/MSIX │ │ .pkg │ │ .deb/.rpm│ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ └─────────────┼─────────────┘ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ .nsigii Package │ │
│ │ (Platform-agnostic │ │
│ │ envelope) │ │
│ │ │ │
│ │ Filter → Flash cycle │ │
│ │ per platform target │ │
│ └────────────────────────┘ │
│ │
│ Wheel rotation = version increment │
│ No rollback = RBT insert-only │
│ Undo/Redo = inverse filter application │
│ │
└──────────────────────────────────────────────────────┘
The Trident Wheel ensures that:
-
A single
.nsigiipackage serves all three platforms through conditional trait loading -
Platform-specific actuators (
.exe,.app, ELF) are compiled from the same LibPolyCall ABI -
The RBT version index is shared across all platforms — version
1.2.3-filtermeans the same transformation on Windows, macOS, and Linux - No platform gets rolled back independently — the wheel turns for all three simultaneously, maintaining version parity across the Trident
7. Integration with LibPolyCall Isomorphic Binding Architecture
The NSIGII binary interface integrates with LibPolyCall's Canonical IR as follows:
NSIGII Package (.nsigii)
│
▼
┌──────────────────────────────────────────┐
│ NSIGII Protocol Layer │
│ Filter (Transform) ←→ Flash (Persist) │
└──────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Canonical IR (CIR) │
│ CIR_Object → CIR_Field → CIR_Value │
│ Huffman-AVL AST Isomorphism │
└──────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ LibPolyCall FFI Layer │
│ libpolycall.so (shared ABI) │
│ Zero-Trust: Crypto-seeded GUID sessions │
└──────────────┬───────────────────────────┘
│
┌──────────┼──────────┬──────────┐
▼ ▼ ▼ ▼
Python Lua Go COBOL
(ctypes) (ffi) (gosilang) (cbl-polycall)
main.py main.lua main.go main.cbl
Each binding is a driver (rectangle). The NSIGII protocol ensures the square (perfect bidirectional binding) at the CIR level. Language-specific serialization formats (dict, table, VSAM record) are all isomorphically mapped through the CIR without data loss.
8. Summary
| Concept | Definition |
|---|---|
| NSIGII | No-rollback abstract binary instruction interface for human-in-the-loop control |
| Filter | Mutable transformation — the "pipe" that changes data forward |
| Flash | Persistent storage — the "write" that saves state |
| No Rollback | State is never destroyed; undo/redo replaces rollback |
| SemVerX | Versioning with filter/flash annotations at major/minor/patch levels |
| RBT Version Index | Red-Black Tree indexing all version states; insert-only, no deletion |
| Trident Wheel | Cross-platform no-rollback infrastructure for Windows, macOS, Unix/Linux |
| Trident | The three-platform deployment target: Windows, macOS, Unix/Linux |
.nsigii |
Package envelope enforcing protocol semantics on archives |
| Controller | Human-in-the-loop agent (joystick metaphor) |
| Actuator | Execution unit performing traits under controller direction |
| CIR | Canonical Intermediate Representation bridging all language bindings |
The NSIGII No-Rollback Abstract Binary Interface ensures that every state transition in the OBINexus ecosystem is verifiable, persistent, and irreversible — mirroring the human rights principle that identity, labor, and contribution cannot be erased or ghosted.
OBINexus Project — Session state preserved. No rollback. No ghosting.
Top comments (0)