Skip to main content

VORTEX FRAMEWORK

Systems that move. Think in fields.

Vortex Framework — a polynomial-time compute framework composing semantic compression, secure containers, portable binaries, graphics, data, and distributed systems.

27D
LOGICAL
01D – 27D representations
FIBERS
16 – 1024
in increments of 16
PATH
BOUNDED
polynomial-time execution
LOCALITY
FIBER
logical rejoin

VME / VORTEX MATHEMATICS ENGINE

A thousand paths through one idea.

Architecture with a pulse. Every stage is an explicit, inspectable boundary rather than an implicit side effect.

Vortex operates through an explicit polynomial-time execution model across its supported 1D–27D logical representations. It treats information as a living stream: split into semantic segments, shaped for locality, carried across fibers, then rejoined with meaning intact.

03D spatial
10D binary
27D logical
ACTIVE STRANDS —
EXECUTION MODEL
polynomial-time
PATH
bounded work, explicit paths
LOCALITY
fiber-local, logical rejoin
  • 01

    OPEN-LOOP TORUS

    Data streams through an open-loop torus processing structure that folds work across fibers without closed circular dependencies.

  • 02

    1D – 27D LOGICAL

    Logical representations scale from a simple line to 27-dimensional forms; higher dimensions fold into bounded lanes.

  • 03

    FIBERS / 16–1024

    Dynamically scheduled logical data lanes, scalable from 16 to 1,024 active fibers in increments of 16.

  • 04

    POLICY TARGETS

    Per-fiber policy throughput targets may be 2, 4, 8, 16, or 32 KiB per millisecond.

Note The interactive field above is a conceptual projection for illustration. Fiber counts and per-fiber throughput figures are architecture and policy targets — not measured or guaranteed hardware throughput by any specific deployment.

AVM / ABSTRACT VORTEX MACHINE

The Vortex core, made portable.

One compute identity. Three operating systems.

AVM is the portable Vortex binary / runtime surface for Windows, Linux, and macOS — containing the full VME core, mathematics libraries, algorithms, a versioned runtime contract, capability discovery, and backend adapters.

CORE

VME compute scheduler and task graph

LIBRARIES

Versioned mathematics and algorithm bundles

RUNTIME

Capability discovery and backend adapters

PORTABILITY

Windows, Linux, and macOS delivery targets

  • Windows
  • Linux
  • macOS

Note Real portability depends on the supported host, selected backend, runtime version, and the negotiated capability contract. Not every feature is available on every host.

VPL + VKL / LANGUAGE LAYERS

Close to the machine. Clear above it.

VPL / LOWER

Vortex Programming Language

The lower-level, explicit, bounded, VME-facing language. Handles typed data, memory boundaries, math operators, fiber-oriented work, and deterministic execution contracts.

VKL / HIGHER

Vortex Kernel Language

The higher-level orchestration layer for VPL. Describes parallel intent, dispatch shape, kernel orchestration, and bounded results. VKL compiles / targets VPL semantics conceptually.

normalize_field.vkl ILLUSTRATIVE
// VKL: illustrative high-level kernel declaration
kernel normalize_field(
  input: f32[n],
  output: f32[n],
  fibers: 256
) {
  for_each lane in input parallel {
    output[lane] = normalize(input[lane]);
  }

  emit output with {
    integrity: "verified",
    locality: "fiber-local"
  };
}

Note This is illustrative landing-page syntax. It is not a normative language specification, and the exact syntax / compiler is not claimed to be shipping.

VSL / VORTEX SHADER LANGUAGE

One visual grammar. Many render surfaces.

VSL is the graphics and compute-facing language layer of Vortex. Target-neutral intent written once can be adapted to Canvas, Canvas 2D, WebGL, WebGPU, Vulkan, and DirectX.

VSL / TARGET-NEUTRAL INTENT

→

ADAPTER / SELECTED BACKEND

  • CANVAS

    2D raster

  • CANVAS 2D

    2D context

  • WEBGL

    3D web

  • WEBGPU

    WGPU web

  • VULKAN

    native GPU

  • DIRECTX

    native GPU

NOTEActual device features, formats, limits, and performance are determined by the selected backend adapter, not by VSL alone.

P2Pm + VSAN / DISTRIBUTED MOVEMENT

A mesh that knows its shape.

P2Pm is Vortex’s peer-to-peer mesh concept supporting sharding, clustering, distributed compute, peer-provided heavy-compute services, and capability- and locality-aware placement. VSAN — Vortex Self Aware Network — supplies real-time observability and policy signals for peer health, topology, resource pressure, workload behavior, routing behavior, identity and admission, anomaly detection, and remediation policy.

  1. 01 / SHARD

    Split with intent

    Partition & ownership

    Partition compute and data into bounded, observable units with explicit ownership and recovery rules.

  2. 02 / CLUSTER

    Coordinate capacity

    Grouping & policy

    Group peers by capability, proximity, policy, or workload affinity while retaining placement visibility.

  3. 03 / COMPUTE

    Move the work

    Dispatch & verify

    Dispatch independently verifiable tasks where capacity and locality support the declared execution plan.

  4. 04 / VSAN

    Watch the mesh

    Observe & remediate

    Use real-time telemetry for peer health, routing behavior, resource pressure, anomalies, and remediation policy.

Security positioning.

P2Pm should be designed to reduce P2P risk through layered identity and admission controls, authenticated transport, authorization, rate limits, anti-replay rules, resource quotas, sybil-resistance mechanisms, anomaly detection, and continuous VSAN monitoring. No architecture can truthfully claim that every P2P attack vector does not apply. Security claims must be supported by a published threat model, implementation review, adversarial testing, and measured operational evidence.

VDBE / VORTEX DATABASE ENGINE

Data stays where it makes sense.

VDBE is a Vortex database-engine layer and integration surface. It coordinates with local data stores, server databases, and cloud-hosted services through explicit adapters — it does not pretend all storage models must be replaced by a single database.

LOCAL

  • SQLite3
  • CSV

STANDARD

  • PostgreSQL
  • MySQL
  • MariaDB

CLOUD

  • Cloudflare D1
  • Cloudflare Vectorize

HOSTED

  • MongoDB

NOTEActual consistency, query behavior, security, and performance remain properties of the selected backend and deployment policy.

VSCC / SEMANTIC COMPRESSION CODEC

Meaning travels lighter.

VSCC does not pretend that everything compresses. It recognizes structure, tests bounded paths, and retains the smallest complete lossless frame — or keeps the original intact.

  1. SOURCE
  2. SEMANTIC SEGMENTS
  3. SELECTED PATH
  4. FRAME ESTIMATE
  5. NET REDUCTION

NOTEHigh-entropy, already-compressed, encrypted, or random data may require raw fallback. Compression must happen before encryption when compression is intended; authentication must happen before decompression / expansion when handling untrusted content.

VORTEX / MANIFEST
{
  "framework": "Vortex",
  "modules": [
    "VME",
    "VSCC",
    "VLES",
    "VSS"
  ],
  "mode": "middle-out",
  "integrity": "byte-exact"
}

STATIC ILLUSTRATION

Adjust the path and source size to see how the illustrative frame estimate is composed. The ratios come from a static JSON file — there is no codec behind this, and nothing is measured.

RUN COMPOSITION

min 1024 · step 1024 · 1 MiB default

computing…

SOURCE / NET REDUCTION

SOURCE
1 MiB 1,048,576 B
SEMANTIC SEGMENTS
421.9 KiB semantic 421.9 KiB + residual 602.1 KiB
SELECTED PATH
middle-out balanced segmentation, semantic rejoin
FRAME ESTIMATE
421.9 KiB 0.412× of source
NET REDUCTION
58.8% illustrative — exact framing, no measured codec

Illustrative only. Production VSCC must measure actual encoded bytes, include complete manifest / frame overhead, and keep the raw fallback when no complete-frame net saving exists.

NOTEIllustrative only. Production VSCC must measure actual encoded bytes, include complete manifest / frame overhead, and keep the raw fallback when no complete-frame net saving exists.

RESEARCH / CONCEPTUAL MODELS

The shape of less.

Conceptual module visualizations. Values are illustrative design models — not measured performance claims.

01 / VSCC

Compression composition

Illustrative design model values: source 100 percent, semantic 38 percent, residual 22 percent.

Illustrative composition of a payload separating recognizable semantic segments from residual material.

02 / VLES

Entropy normalization

Illustrative design model values: raw 100 percent, normalized 27 percent.

Illustrative normalization of a noisy distribution into a smoother, lower-entropy residual.

03 / LLM

Quantization × compression

Illustrative design model values: FP16 100 percent, low-bit 31 percent.

Quantization and lossless-container savings must be reported separately. Quality must be validated on the target task suite. Values shown are illustrative.

04 / VSS

Secure file container

Illustrative staged model order: SOURCE, VSCC, VAEC, VSS, SEALED.

Illustrative packaging order: compression, optional recovery protection, then authenticated encryption. No custom cryptographic primitives or guarantees are claimed.

LANGUAGE & PLATFORM WORK

Vortex Framework languages and platform work

Assembly
Status: Under Development
Runtime notes: Low-level systems integration
C
Status: Beta
Runtime notes: Native systems and runtime integration
C++
Status: Beta
Runtime notes: Native compute and engine integration
Go
Status: Beta
Runtime notes: Services, networking, and tooling
Rust
Status: Under Development
Runtime notes: Safety-oriented systems integration
Python
Status: Beta
Runtime notes: Research, data, and automation workflows
Assembly
Status: Beta
Runtime notes: Assembly integration surface
PHP
Status: Beta
Runtime notes: Web and application service integration
COBOL
Status: Beta
Runtime notes: Legacy enterprise integration
Java
Status: Beta
Runtime notes: Enterprise services and JVM integration
C#
Status: Beta
Runtime notes: .NET and application integration
Ruby
Status: Under Development
Runtime notes: Web tooling and developer workflows
NodeJS-TypeScript (Bun, Deno)
Status: Beta
Runtime notes: JavaScript and TypeScript runtime integration
Vortex Bootloader
Status: Under Development
Runtime notes: Boot-time systems foundation
VortexOS
Status: Under Development
Runtime notes: Operating-system research and platform surface

FRAMEWORK MODULES / SYSTEM INDEX

The field, indexed.

  1. 01 / AVM

    Portable machine

    Portable Vortex core

    Cross-platform binary delivery surface for VME, math libraries, and algorithms.

  2. 02 / VME

    Fiber compute

    Polynomial-time fibers

    Polynomial-time computation across a configurable open-loop torus.

  3. 03 / VPL + VKL

    Language layers

    Low and high expression

    Low-level Vortex programming plus higher-level kernel expression.

  4. 04 / VSL

    Shader surfaces

    Graphics intent

    Graphics and compute intent across web and native rendering backends.

  5. 05 / VSCC + VLES

    Semantic compression

    Lossless meaning

    Lossless segmentation, exact transforms, and measured residual coding.

  6. 06 / VSS + VAEC

    Trust and recovery

    Protected frames

    Authenticated envelopes plus bounded repair policy for protected frames.

  7. 07 / P2Pm + VSAN

    Observed mesh

    Distributed movement

    Peer coordination, sharding, clustering, distributed compute, and real-time monitoring.

  8. 08 / VDBE

    Data adapters

    Stored where sensible

    Local, server, and cloud data integration under explicit backend policy.

REDEAUX / MANIFESTO

Computation with shape, rhythm, and trust.

REDEAUX is building the Vortex Framework: an open proposal for infrastructure that treats information as a living stream rather than a static artifact. Data enters a polynomial-time execution model, is split into semantic segments, carried across 16–1,024 configurable fibers, and rejoined with meaning intact.

The framework spans eight subsystems — the portable Vortex core (AVM), the mathematics engine (VME), the VPL/VKL language layers, graphics surfaces (VSL), semantic compression (VSCC/VLES), trust and recovery envelopes (VSS/VAEC), distributed coordination (P2Pm/VSAN), and data adapters (VDBE). Every subsystem is held to the same standard: discrete boundaries, explicit paths, verifiable operational policy, and no closed circular dependencies.

Vortex Framework. It is designed to feel alive — so that the systems carrying our data have the same rhythm, discipline, and verifiability we expect from the data itself.

FAQ / REDEAUX

Frequent questions, answered plainly.

The Vortex Framework is REDEAUX’s for next-generation infrastructure. It is an open-loop, polynomial-time compute and compression architecture that treats data as a living stream — segmentation, transport, and rejoin across configurable fibers.

Every operation in the Vortex Framework is bounded by a polynomial-time execution model. That means work scales predictably with input size — no hidden exponential blow-ups — and per-fiber throughput is set as an explicit policy target rather than an untracked bottleneck.

Not yet. The framework is currently an active development project with many working prototypes. Fiber counts, dimensional topologies, and throughput figures are policy targets describing the design — they are not measured guarantees of any specific hardware deployment.

Eight: AVM (portable Vortex core), VME (Vortex Mathematics Engine), VPL and VKL (language layers), VSL (graphics intent), VSCC/VLES (semantic compression), VSS/VAEC (trust and recovery), P2Pm/VSAN (distributed coordination), and VDBE (data adapters).

Vortex compression (VSCC/VLES) is semantic segmentation with exact transforms and measured residual coding. The goal is lossless meaning: splitting information into recoverable semantic segments so the pipeline can compress, transport, and rejoin without losing intent.

Follow @RedeauxG on X, connect on LinkedIn, and read the REDEAUX blog for frameworks and releases.

REDEAUX / 12

Make the system feel alive.

Vortex Framework is for infrastructure with shape, rhythm, discipline, and verifiable operational boundaries. Built by Redeaux for the work that comes next.