Keddeh Systems / Future ready

Build the next step.
Know what it rests on.

From portable workspaces to local expertise and connected equipment: a portfolio designed around useful work, clear responsibilities and results you can inspect.

Choose a capability and its acceptance test ↓

Current readiness and qualification gates, without invented launch dates.

One portfolio · distinct responsibilities

Conceptual architecture. The diagram does not connect to AI, files or equipment.

01 / One connected direction

Begin with people.
Connect the pieces deliberately.

The aim is a working environment that carries its context from screen to service to equipment. Each product keeps its identity; each connection needs an explicit interface and a result to verify.

WorkspacesPeople select a task, its files and the result they need.

Meaning & stateIL-LLM, vectors and KEX identify the context that must survive.

Services & transportAdmitted execution and bounded transport carry only the authorised work.

Equipment & impactRated interfaces return observed response; complete measurements establish the impact.

Available software surfaces are a starting point. They do not imply every connection is active or that physical hardware, recovery and energy outcomes have already been qualified.

02 / A roadmap with real gates

Choose the capability.
See the next useful step.

Each chapter starts with the benefit, then separates what is evidenced today from the integration and qualification work ahead. Selecting a chapter changes this guide only.

01 / Workspaces

Start with a place to do the work.

Portable HTML and virtual-filesystem workspaces keep the working surface, source identity and retained objects related.

What we can point to today

The website and four Studio installations have actual browser-local and cloud-retention evidence. Domain Studio, Operating System Studio, BRAINK Workstation Studio and HTML APP STUDIO remain distinct derivatives with their original source lineages preserved.

The next integration

Qualify the protected full-carrier candidates in real browsers, including simultaneous carriers, stale saves, quota failures, crash recovery and explicit legacy-data import.

What earns the next claim

Bind the exact ENV1 compiler and virtual-storage rebootstrap entrypoints, retain both stage receipts and verify reopen/readback. Double wrap means this two-stage sequence, not iframe nesting.

Inspect the readiness boundary

The newer native Studio protection candidate is uninstalled and unpublished: 62 authored tests and 15 independent checks passed within bounded static, isolated transaction and derived UI-handler scope. Browser qualification, ENV1 compiler binding and native ToT provider/receipt binding remain pending. This candidate is separate from the existing installed thin clients. Soft budgets and cooperative locks are not hard process isolation or protection from hostile same-origin code.

02 / Services

Put execution and retained work in the right place.

A connected workspace needs a known execution host and a dependable place to keep its source and results.

What we can point to today

ServerSpace and StoreSpace have separate source packages and deployment boundaries. ServerSpace coordinates admitted execution; StoreSpace builds and verifies retained source-backed objects. Their product guides do not claim a bound native host.

The next integration

Select versioned service packages, persistent state mounts and host adapters. Bind the actual workstation-to-service operation and inspect its returned result.

What earns the next claim

Demonstrate admitted work, durable readback and recovery on the selected host. A reachable service or transport does not establish that a particular workload executed.

Inspect the readiness boundary

VirtualWeb4 is a distinct owner-named offering with an integration specification. Its next gate is product-specific package identity, supported host matrix and an actual carrier-to-handler binding. A single website origin is not evidence of independent multi-host failure domains.

03 / Local expertise

Build knowledge for the task at hand.

Local-first IL-LLM meaning and BRAINK augmented learning are intended to bring equipment- and site-specific context to the person doing the work.

What we can point to today

BRAINK AI, BENNY AI and AI PY are distinct inspected source lines. Their public product surfaces inspect identity and source; they do not start native Python inference or bind a memory backend.

The next integration

Qualify a real compatible host, application-specific memory and permitted tools. Keep the guide, file and equipment agents separate, with explicit scoped handoffs.

What earns the next claim

Verify the supported task, the result and drift boundaries. Learning must not silently expand identity, tools or authority; a role change needs an authorised transition.

Inspect the readiness boundary

BENNY AI’s command-shell and slot-memory source, AI PY’s desktop-aware indexing and ask-routing source, and BRAINK AI’s continuity/addressing/orchestration source are not interchangeable brands for the same running model. No trained local expert is claimed here.

04 / State & continuity

Carry the context needed to continue.

Represent meaning, identity and retained state together so recovery can be checked against the work that came before.

What we can point to today

The architecture relates vector representations, KEX addressing, seed, KEX DNA, keys and IL-LLM meaning. Native ToT source includes an authority/evidence boundary and a rehydration path; the browser-carrier provider binding remains unresolved.

The next integration

Bind a versioned state representation to its actual runtime, receipt linkage and storage. Define how authorised transitions and key lifecycle relate to identity without conflating them.

What earns the next claim

Interrupt the chosen runtime, rehydrate the intended state, compare retained results and test failure responses. A browser reload alone does not qualify native ToT recovery or hardware failover.

Inspect the readiness boundary

DNA represents constrained state for the intended reconstruction and failover model. It is not a self-executing engine. Seed, DNA and cryptographic keys have distinct jobs; address/identity evolution does not prove key rotation. Recovery claims need observations from the selected implementation.

05 / Edge & transport

Connect only the work that needs to travel.

Local execution and explicit transport interfaces offer a way to keep context near its use and measure what actually moves between systems.

What we can point to today

TL2 implementation is traced, with four local source-bound encoding/encryption roundtrips and altered-tag rejection observed. TL retains its own identity. Edge software has mapped source families; neither observation is an internet performance benchmark.

The next integration

Qualify authenticated channels, replay handling, resource limits and the exact Edge release/device profile. Test offline work, reconnection and selected-result synchronization.

What earns the next claim

Compare the same useful workload across complete wire traffic, latency, CPU, memory and energy. Count encoding, handshakes, retries and retransmissions.

Inspect the readiness boundary

TL2 currently carries encrypted bytes as hexadecimal text inside JSON. Any transfer claim must include that overhead and outer traffic. The Keddeh Internet Service Provider architecture does not establish an activated public ISP, subscriber service or unlimited data.

06 / Equipment & energy

Take the next step into the physical world.

Ethernet BRAINK modules are designed to relate inputs, requested behaviour and observed response, with local expertise beside the equipment.

What we can point to today

The modular hardware design covers power, control, Network ToT and Memory ToT, with bounded pulse/path discovery. Software availability and browser installations do not establish a manufactured or qualified physical system.

The next integration

Fix the schematic, BOM, firmware, connector/driver ratings and supported equipment profiles. Measure known-device behaviour, unknown/fault refusal, restart, link loss and retained-state recovery.

What earns the next claim

Pass target-specific bench acceptance and applicable qualification. Compare complete useful work and energy at a declared boundary before stating savings.

Inspect the readiness boundary

CAT6/Ethernet, CAN electrical signalling and KEX-CAN records remain distinct layers. Passive adapters do not establish compatibility. CPU/GPU upgrade paths, SSDRAM, MRAM-backed multi-failover and shared connector designs require their own selected-device and target-specific qualification. No release date, stock, price or certification is asserted.

04 / Follow the evidence

Progress has more
than one meaning.

A source file, a working connection and an independently checked result answer different questions. Use the product guides to see the boundary that applies to the capability you need.

Source identified → implemented

Know what the code is.

Source identification pins the correct product and revision. Implementation means a mechanism exists in code; it does not establish that it ran in your environment.

Connected → deployed → executed

Know where the work happens.

A bound interface connects components. Deployment puts a version in an environment. Execution needs the actual task result and readback, at that boundary.

Independently checked

Know what was checked.

An independent check applies to its stated tests, version and environment. Candidate-level checks do not confer production, browser or physical-system approval.

Where does FROST fit?

FROST remains a distinct owner-named software offering. Its authoritative product source and executable interface still need identification. No function is invented from the name, and it is not substituted with an unrelated cryptographic product.

How will energy improvements be established?

Use the same useful workload and output quality, measure the complete system boundary, and include local compute, transport, storage, idle time and recovery. Report absolute energy and useful work with the comparison conditions. Local-first design is a hypothesis to test, not an automatic energy-saving result.

Product guides and supporting evidence · 28 guides

Use these optional references to inspect the product you selected. Each guide records its purpose, present status and qualification boundary. The roadmap above already explains the next integration and acceptance work.

Workspaces & Studios · 4 guides

Domain Studio

Design domain records before changing a live network.

Owner-controlled browser application • access by arrangement

Next qualification step: Qualify live DNS, registrar, delegation and TLS bindings separately from locally retained drafts.

Domain Studio · implementation and readiness guide

Operating System Studio

Assemble applications inside the AetherOS working environment.

Owner-controlled browser application • access by arrangement

Next qualification step: Qualify native package transactions and real browser recovery; preserve its browser/VFS operating boundary.

Operating System Studio · implementation and readiness guide

BRAINK Workstation Studio

Keep workstation files, receipts and runtime references together.

Owner-controlled browser application • access by arrangement

Next qualification step: Bind authorised runtime operations explicitly and verify file/receipt readback without silently starting the preserved runtime.

BRAINK Workstation Studio · implementation and readiness guide

HTML APP STUDIO

Build portable HTML application packages with inspectable identity.

Owner-controlled browser application • access by arrangement

Next qualification step: Bind native ENV1 compilation and storage rebootstrap, then verify the resulting package and reopened state.

HTML APP STUDIO · implementation and readiness guide

AI source variants · 3 guides

BRAINK AI

KEX continuity, addressing and virtual-machine orchestration.

Inspection-only • native execution not activated

Next qualification step: Qualify a real native host, application-specific memory and bounded task execution before offering inference.

BRAINK AI · implementation and readiness guide

BENNY AI

A command-shell and slot-based memory variant.

Inspection-only • native execution not activated

Next qualification step: Qualify a real native host, application-specific memory and bounded task execution before offering inference.

BENNY AI · implementation and readiness guide

AI PY

Desktop-aware indexing, ask routing and packet-ledger structures.

Inspection-only • native execution not activated

Next qualification step: Qualify a real native host, application-specific memory and bounded task execution before offering inference.

AI PY · implementation and readiness guide

Execution & retention · 2 guides

ServerSpace

Coordinate host-side execution, mesh connections and runtime routing.

Published host runtime • managed deployment by arrangement

Next qualification step: Admit the actual host process and verify a workload result, persistent state and recovery.

ServerSpace · implementation and readiness guide

StoreSpace

Build, retain and verify source-backed objects in a dedicated virtual filesystem.

Separate service package • native host not bound

Next qualification step: Bind the native compiler and persistent mount; verify retained source, binary digests and build readback.

StoreSpace · implementation and readiness guide

Architecture & equipment · 7 guides

Double-wrapped HTML architecture

Build the working environment. Bootstrap its storage from within.

Source-described architecture; two-stage runtime acceptance pending

Next qualification step: Execute the exact ENV1-to-storage sequence and retain both stage receipts plus independent reopen/readback.

Double-wrapped HTML architecture · implementation and readiness guide

VirtualWeb4

A virtual working estate with a visible return path.

Distinct VirtualWeb4 offering • integration specification staged

Next qualification step: Establish a product release identity, supported host matrix and verified carrier-to-handler binding.

VirtualWeb4 · implementation and readiness guide

Keddeh Internet Service Provider

Connect distributed Keddeh work through a defined service boundary.

Distributed service architecture • public ISP activation unverified

Next qualification step: Establish routing, operating authority, security qualification and a service agreement before public ISP operation.

Keddeh Internet Service Provider · implementation and readiness guide

TL / TL2 transport architecture

Trace the channel from local request to returned bytes.

TL2 implementation traced; TL identity retained separately

Next qualification step: Qualify end-to-end security and compare complete wire traffic and useful workload outcomes; retain TL identity separately.

TL / TL2 transport architecture · implementation and readiness guide

Edge software

Keep essential work beside the operator.

Source-described Edge architecture • runtime acceptance pending

Next qualification step: Fix the release manifest and device profile, then test offline work, recovery and update/rollback.

Edge software · implementation and readiness guide

FROST software

A distinct Keddeh software offering.

Distinct owner-named software; product source identification pending

Next qualification step: Identify the authoritative product source and supported executable task before assigning functionality.

FROST software · implementation and readiness guide

Ethernet BRAINK hardware

Connect the module. Discover the path. Assign the job.

Owner-designed modular architecture; hardware qualification pending

Next qualification step: Fix the board, firmware and rated interfaces; test discovery, faults, readback and intended-use acceptance.

Ethernet BRAINK hardware · implementation and readiness guide

Mathematics & representations · 11 guides