KEDDEH SYSTEMS / CONNECTED ARCHITECTURE

One connected estate.
Independent systems.

BRAINK governs execution and evidence. KEX locates state, identity and relationships. IL-LLM structures language and knowledge. Their interfaces connect the work; each retains its own responsibility.

Choose a system below. See what it does, how it relates to the estate, and the relevant tool or evidence you can explore next.

Architecture by Aboudy Keddeh — Systems Architect

Choose a system

FOUNDRY FABRIC R1

Explore the connected estate

18 independent foundries, plus their connecting architecture. Select a system to see its purpose, responsibility and evidence boundary.

Find a component by name or purpose

27 of 27 components shown

EXPERIENCE SYSTEMResponsibility guide

Frontage Foundry

Market-facing experience

Defines what a visitor sees, understands and can do across a Keddeh market surface.

Purpose to you: Understand an offer and decide whether it serves your need.
Purpose to humanity: Reduce information barriers and unsupported persuasion.

Responsibilities

Information architecture
Interaction model
Value articulation
Accessibility intent

Connected systems

· ·

Concrete outputs

Frontage specification · Interactive prototype · Experience acceptance criteria

Explore this system

Company presentation, visitor relationships and market-facing journeys.

Explore Frontage Foundry ↗Inspect the research evidence ↗

Share this component

Component address

More tools in the estate

EXPLORE · LEARN · OPERATE

Follow the architecture into software.

Open an operating surface, inspect the research or learn how a runtime handles its work.

01 / BRAINK

Execution & evidence

Explore the governed execution architecture, then open the retained BRAINK × IL-LLM software.

Read BRAINK Open resident software

02 / KEX

State & addressing

Inspect addressed realities and operate the compute, memory and virtual-file-space workbench.

Explore addressed realities Use the VFS workbench

03 / IL-LLM

Meaning & knowledge

Read the semantic architecture and traverse the interactive learning and research surfaces.

Read IL-LLM Open interactive learning

Observer research laboratories ↗Runtime field guide ↗Run the scalar tracking study ↗

Prepare a local delivery brief · optional

YOUR WORKFLOW

Build a suggested delivery plan.

Change a choice to update your plan. This optional planning tool turns your selections into a draft brief. Its suggestions are page-implementation logic; they do not redefine Keddeh architecture or authorise a change.

01 What outcome do you need?

Explain my work clearlyHelp visitors understand what you offer, why it matters and what they can do next.Build or improve a websiteCreate or improve a working website with clear controls, useful error recovery and a traceable release.Understand and connect my systemsFind the responsible system, understand its interfaces and see the evidence needed before connecting it.

02 What state is the work in?

New undertakingThe offer or audience is still being shaped.Existing websiteA live surface needs to be understood or improved.Ready to buildThe direction is approved and needs executable delivery.

03 What is blocking progress?

Clarify the offerVisitors cannot quickly understand the value or difference.Improve conversionInterest is present, but the next action is weak or unclear.Make delivery realThe concept exists, but source, runtime or release are disconnected.

DERIVED FROM YOUR CHOICESLOCAL / NOT SUBMITTED

First step

Define the user task

Write down the intended visitor, their task and the constraints before proposing a solution.

Outcome: Explain my work clearly
Evidence to bring: Current offer, target visitor and available proof.
First owner: Research Mastery + HCI Foundry
Your result: An understandable frontage with a usable next action and traceable claims.
For you: Help a visitor decide whether your work addresses their need before they invest time.
For humanity: Make technical knowledge accessible and reduce decisions based on unsupported promises. Intended benefit; impact requires evaluation.

Portable delivery brief

KEDDEH SYSTEMS / DELIVERY BRIEF
Outcome: Explain my work clearly
Stage: New undertaking
Priority: Clarify the offer
First responsible system: Research Mastery + HCI Foundry
First action: Write down the intended visitor, their task and the constraints before proposing a solution.
Evidence to bring: Current offer, target visitor and available proof.
System path: Research Mastery + HCI Foundry → Frontage Foundry + Foundry Fabric → Website Foundry + Usable Software Foundry → A reviewer separate from the implementation actor → Publishing Mastery + Sites deployment infrastructure
For the user: Help a visitor decide whether your work addresses their need before they invest time.
For humanity (intended): Make technical knowledge accessible and reduce decisions based on unsupported promises.
Impact evaluation: Ask representative visitors to explain the offer and find the next action; record misunderstandings and access barriers.
Attribution: Architecture: Aboudy Keddeh — Systems Architect, Keddeh Systems. Suggested planner rules: Codex implementation assistant; not an owner-approved architecture policy.
Source: W3C — WCAG 2.2 — https://www.w3.org/TR/WCAG22/
Source: ISO — ISO 9241-210:2019 — https://www.iso.org/standard/77520.html
Source: ISO — ISO 9241-11:2018 — https://www.iso.org/standard/63500.html
Source: ISO / IEC — ISO/IEC 25010:2023 — https://www.iso.org/standard/78176.html
Source: OWASP Foundation — OWASP ASVS 5.0.0 — https://owasp.org/projects/asvs

1. Define the user task
Owner: Research Mastery + HCI Foundry
Action: Write down the intended visitor, their task and the constraints before proposing a solution.
Input: Audience, desired task, constraints and approval scope.
Output: A short user requirement and measurable acceptance criteria.
Acceptance: Name the user, task, context and expected result. Test whether a visitor can explain the purpose in their own words.
Recovery: If the need is unclear, gather observations and revise the requirement before building.
Standards: ISO 9241-210:2019, ISO 9241-11:2018
Evidence: PENDING
Independent review: PENDING

2. Design the system handoffs
Owner: Frontage Foundry + Foundry Fabric
Action: Design the shortest complete journey, including loading, error, denied and recovery states.
Input: Agreed user requirement, system responsibilities and claim sources.
Output: A journey and interaction specification.
Acceptance: Each action names its input, responsible system, observable output and recovery path. Claims identify their source and current evidence state.
Recovery: Resolve ambiguous ownership or unsupported claims; do not proceed on an assumed dependency.
Standards: ISO 9241-210:2019, ISO/IEC 25010:2023
Evidence: PENDING
Independent review: PENDING

3. Build the usable experience
Owner: Website Foundry + Usable Software Foundry
Action: Implement semantic controls, responsive layouts, explicit labels and recoverable errors.
Input: Versioned design, interface contracts and approved sources.
Output: Versioned source and a reproducible build.
Acceptance: The intended task completes with keyboard input; at 320 CSS pixels the content reflows; errors explain how to recover; inputs cannot execute authored markup.
Recovery: Retain the last usable version and correct failed checks before release.
Standards: WCAG 2.2, ISO/IEC 25010:2023, OWASP ASVS 5.0.0
Evidence: PENDING
Independent review: PENDING

4. Evaluate with evidence
Owner: A reviewer separate from the implementation actor
Action: Compare observed outcomes with the acceptance criteria and attach reproducible evidence.
Input: Exact source revision, checks, test context and representative users where available.
Output: A review with passed checks, failures and untested criteria recorded separately.
Acceptance: Record task completion, errors, recovery, effort and user understanding. Every accepted claim references evidence and a reviewer; missing evidence remains pending.
Recovery: Route failures back to the responsible system and retest the changed journey.
Standards: ISO 9241-11:2018, WCAG 2.2, ISO/IEC 25010:2023, OWASP ASVS 5.0.0
Evidence: PENDING
Independent review: PENDING

5. Publish and observe the result
Owner: Publishing Mastery + Sites deployment infrastructure
Action: Save the tested source version, preserve its audience, deploy and read the native deployment status.
Input: Approved revision, build artifact, audience and recovery version.
Output: Source revision, saved version, deployment result and delivery observations.
Acceptance: Native deployment succeeds for the exact version. Record public delivery separately where observed. Confirm recovery scope; a planner export is not a deployment receipt.
Recovery: If publication fails, keep the prior release and diagnose the failure. Restore a saved version through the same authorized Site when needed.
Standards: ISO/IEC 25010:2023, OWASP ASVS 5.0.0
Evidence: PENDING
Independent review: PENDING

Review the five steps and add evidence

No personal details are requested or stored.

PLAN, CHECK, RECOVER

Your five-step workflow

Each step has an acceptance gate. An evidence reference records what you provide; it does not approve the work or prove execution.

Explain my work clearly · New undertaking · Clarify the offer

01
Define the user task
Responsible: Research Mastery + HCI Foundry
Evidence pending
Write down the intended visitor, their task and the constraints before proposing a solution.
Bring
Audience, desired task, constraints and approval scope.
Receive
A short user requirement and measurable acceptance criteria.
Acceptance, standards and recovery
Accept when: Name the user, task, context and expected result. Test whether a visitor can explain the purpose in their own words.
If it fails: If the need is unclear, gather observations and revise the requirement before building.
Standards: ISO 9241-210:2019 ISO 9241-11:2018
Evidence reference (optional; document, test report or revision)
02
Design the system handoffs
Responsible: Frontage Foundry + Foundry Fabric
Evidence pending
Design the shortest complete journey, including loading, error, denied and recovery states.
Bring
Agreed user requirement, system responsibilities and claim sources.
Receive
A journey and interaction specification.
Acceptance, standards and recovery
Accept when: Each action names its input, responsible system, observable output and recovery path. Claims identify their source and current evidence state.
If it fails: Resolve ambiguous ownership or unsupported claims; do not proceed on an assumed dependency.
Standards: ISO 9241-210:2019 ISO/IEC 25010:2023
Evidence reference (optional; document, test report or revision)
03
Build the usable experience
Responsible: Website Foundry + Usable Software Foundry
Evidence pending
Implement semantic controls, responsive layouts, explicit labels and recoverable errors.
Bring
Versioned design, interface contracts and approved sources.
Receive
Versioned source and a reproducible build.
Acceptance, standards and recovery
Accept when: The intended task completes with keyboard input; at 320 CSS pixels the content reflows; errors explain how to recover; inputs cannot execute authored markup.
If it fails: Retain the last usable version and correct failed checks before release.
Standards: WCAG 2.2 ISO/IEC 25010:2023 OWASP ASVS 5.0.0
Evidence reference (optional; document, test report or revision)
04
Evaluate with evidence
Responsible: A reviewer separate from the implementation actor
Evidence pending
Compare observed outcomes with the acceptance criteria and attach reproducible evidence.
Bring
Exact source revision, checks, test context and representative users where available.
Receive
A review with passed checks, failures and untested criteria recorded separately.
Acceptance, standards and recovery
Accept when: Record task completion, errors, recovery, effort and user understanding. Every accepted claim references evidence and a reviewer; missing evidence remains pending.
If it fails: Route failures back to the responsible system and retest the changed journey.
Standards: ISO 9241-11:2018 WCAG 2.2 ISO/IEC 25010:2023 OWASP ASVS 5.0.0
Evidence reference (optional; document, test report or revision)
05
Publish and observe the result
Responsible: Publishing Mastery + Sites deployment infrastructure
Evidence pending
Save the tested source version, preserve its audience, deploy and read the native deployment status.
Bring
Approved revision, build artifact, audience and recovery version.
Receive
Source revision, saved version, deployment result and delivery observations.
Acceptance, standards and recovery
Accept when: Native deployment succeeds for the exact version. Record public delivery separately where observed. Confirm recovery scope; a planner export is not a deployment receipt.
If it fails: If publication fails, keep the prior release and diagnose the failure. Restore a saved version through the same authorized Site when needed.
Standards: ISO/IEC 25010:2023 OWASP ASVS 5.0.0
Evidence reference (optional; document, test report or revision)

Evidence references stay in this page until you copy or download them. Refreshing clears them. Independent review remains pending; this page cannot issue a verification or deployment receipt.

Change my choices

Evidence, standards and website delivery

SOURCES & VERIFICATION

What the checks are based on

Standards inform specific acceptance criteria. Evidence shows what has actually been checked. Both are necessary.

W3C / Web accessibility

WCAG 2.2

Recommendation · 12 December 2024

Keyboard access (2.1.1), visible focus (2.4.7), reflow (1.4.10), contrast (1.4.3), labels (3.3.2), target size (2.5.8) and status messages (4.1.3).

Selected criteria guide the checks. A full accessibility conformance assessment remains required.

ISO / Design around people and their context

ISO 9241-210:2019

Human-centred design · edition 2

Identify users, tasks and constraints; translate needs into requirements; iterate the design using observed task outcomes.

Public abstract used for scope. The workflow is a Keddeh interpretation, not a clause-by-clause ISO audit.

ISO / Evaluate outcomes of use

ISO 9241-11:2018

Usability · edition 2

Record whether people complete the intended task, the effort required and their experience in a stated context.

Participant testing has not been conducted for this release. No usability score is claimed.

ISO / IEC / Software and technology product quality

ISO/IEC 25010:2023

Product quality model · edition 2

Define acceptance evidence for correct behavior, reliability, performance, security, maintainability and interaction quality.

Public abstract used for scope. These acceptance gates are project requirements, not certification.

OWASP Foundation / Security controls in web applications

OWASP ASVS 5.0.0

Application security verification · May 2025

For connected execution, test authorization at the server, validate inputs, protect sensitive data and reject unauthorized state changes.

This browser planner makes no external changes. Security verification of proposed integrations is pending.

Checks on this website implementation

The implementation actor’s delivery record identifies the software checks and the remaining review work. These findings concern this page, rather than the validity of the Keddeh architecture.

Read the page delivery record (JSON)

Real-user usability evaluation, assistive-technology testing, live external adapter checks and independent assessment are pending. No ISO certification, complete WCAG conformance or ASVS certification is claimed.

PAGE IMPLEMENTATION / ACCOUNTABILITY

Architecture authorship and page delivery.

Architecture and authorship

Aboudy Keddeh — Systems Architect, Keddeh Systems. The 18 foundry identities and the distinct BRAINK, KEX and IL-LLM responsibilities belong to the established architecture.

Codex, the AI implementation assistant, wrote the page presentation, catalogue summaries and suggested planner rules. That implementation authorship is separate from Aboudy Keddeh’s architectural authorship.

Correction of the previous page

The previous implementation incorrectly labelled a public page “Private prototype”, placed a generic planner before the architecture, and attributed assistant-written planning interpretations to Keddeh Systems. Those were page-delivery errors.

This revision corrects that framing, provides direct software paths and preserves each foundry’s identity. Automated page and interaction checks are implementation observations. Browser visual review and independent assessment remain outstanding for this page.

Inspect the implementation record ↗

One connected estate.Independent systems.