Platform architecture

A connected architecture.
Distinct responsibilities.

Keddeh Systems brings together execution governance, semantic knowledge and state addressing. Understanding the boundaries is the first step to understanding how the platform connects.

Explore by responsibility

Three questions.
Three different roles.

Select a component to see what it defines, where its responsibility ends and how it can contribute to a workflow.

Governed execution & evidence

BRAINK: Connect who may act, what may change, and how the outcome is verified.

Responsibility

BRAINK defines actors, authority, permitted transitions, execution and evidence. A worker’s action and a verifier’s assessment remain separate responsibilities.

Boundary

A permission decision is not execution. An execution result is not independent verification. Each needs its own evidence.

Example: For a workflow change, bind the authorised actor, expected state and adapter before mutation; retain the readback and outcome afterward.

Read the BRAINK overview
Illustrative workflow

Make a change.
Keep its meaning
and its evidence.

A team needs to update a process. IL-LLM helps structure the intention and relevant knowledge. KEX supplies the state and addressing context. BRAINK governs the permitted transition and evidence.

An execution bridge calls an authorised adapter. The host and runtime carry the operation. Readback observes the external result; a separate verifier assesses it.

Define intentResolve stateCheck authorityExecuteRead backAssess
The wider system

An estate of purposeful parts.

Explore each area without treating the entire estate as a single application.

Foundries

Eighteen independent domains, each with its own purpose, outputs, planes and policies.

Explore the foundries

Evidence

The difference between a proposal, an implementation, an observed result and an assessment.

Understand verification

Status

What this frontage offers, what depends on another service and where availability is described.

View availability
Inside the systems

See the purpose.
Follow the mechanism.

Two journeys through Keddeh’s architecture. Open the software, inspect the contracts and understand the state that must survive a failure.

01 / VFS & StoreSpace

Keep the file.
Keep its story.

Move from an original source to a navigable library with explicit identity, provenance and content verification. The original bytes remain the reference.

For the person
Find and understand a record without losing its source.
For the system
Retain bytes, verify GitHub custody, classify and admit into VFS.
What recovery must preserve

Retain the source identity, content digest and last verified import stage. Resume the incomplete stage; reconcile changed bytes before admission.

02 / KEX & ServerSpace

Design for the
moment of failure.

Separate a session’s identity from the worker carrying it. Make reconnection understandable while recovery restores what was actually saved.

For the person
See the reconnection state and retain context during recovery.
For the system
Fence the old worker, acquire a new generation, restore and reconnect.
What recovery must preserve

A stable identity does not preserve browser RAM or a WebRTC connection. Restoration requires a saved checkpoint and a new transport. Reconcile uncertain clicks and submissions before replay.

Architecture journeys illustrate the intended contracts. They are not live telemetry or a claim that all migration and recovery integrations are complete.

One system / distinct responsibilities

Connect the parts.
Preserve the boundaries.

PURPOSE

People & interface

The task, the interaction states and the explanation of what changed.

MEANING

IL-LLM

Terms, relationships and context that give the task a defined meaning.

AUTHORITY

BRAINK

Governed execution with explicit actor, scope and permission.

CONTINUITY

KEX, VFS & carriers

Stable identity, durable records and replaceable execution infrastructure.

Source identity, checkpoint version and transport generation belong to different layers. Record and test each at the boundary where it matters.

Inspect the architecture-to-experience contract

Start with what needs to work better.

Bring a process, an idea or a systems question. We’ll help define the next useful step.

Start a conversation