Keep context close.
Give a deployment site-specific knowledge and relevant operating history. A workshop guide and a bed-system guide need different expertise.
Keddeh Systems / Augmented intelligence
Put understanding
beside the work.
A local guide that knows the context. Separate capabilities that own their actions. People who can follow what happened and decide what comes next.
A human-centred architecture and proposed integration, with source-backed software to inspect today.
01 / Start with understanding
Knowledge is local.
Responsibility is clear.
IL-LLM (ILLLM) carries local-first meaning and relationships: the terms, equipment and history that make a task understandable. BRAINK augmented learning and governance connect observations to proposed improvements within a defined role.
Handoff with a purpose.
Guide, file and equipment agents are separate bounded realities. Each owns its state and permitted interfaces; each evaluates the request it receives.
Improve without drifting.
Adaptation can inform a proposal. Changing identity, tools or authority requires an authorised transition rather than a silent expansion.
02 / A day in the workshop
From the bay
to the people doing the job.
Follow one proposed repair workflow. Select a stage to see how reported equipment state, a repair job, workstation files and an advisor’s view fit together.
Vehicle & bayEstablish the source
Reported stateKeep the boundary explicit
Job identityInspect the result
Illustrative workflow · Stage 1 of 4
Start with the right vehicle.
A vehicle is associated with a repair job and bay. A qualified interface can report the hoist’s state, with its source and observation time. The person checks that the reported context belongs to this job.
Reported hoist state is information. It is not permission to move equipment.
Repair jobEstablish the source
Workstation contextKeep the boundary explicit
Local guidanceInspect the result
Illustrative workflow · Stage 2 of 4
Bring the work beside the mechanic.
The job context relates to the mechanic’s workstation, permitted repair files and retained observations. A local-first guide can explain relevant material and suggest what to inspect, within its available knowledge and interface.
This is an illustrative integration. No trained workshop expert or live workshop-management deployment is claimed.
Guide proposalEstablish the source
Authorised handoffKeep the boundary explicit
Agent-owned resultInspect the result
Illustrative workflow · Stage 3 of 4
Ask the right capability to act.
If a permitted file operation is needed, a scoped request goes to a separate file agent. That agent checks its own identity, state, target and authority. An equipment request belongs to a separately qualified equipment agent and interface.
The guide has no intrinsic file-deletion or equipment-actuation capability. Shared context does not add one.
Observed resultEstablish the source
Permitted job viewKeep the boundary explicit
Advisor & officeInspect the result
Illustrative workflow · Stage 4 of 4
Share the result people need.
An authorised advisor or office view receives the relevant job progress and returned result. Retained files and readback support later inspection. A failed or unknown result stays visible instead of becoming a success message.
Each view has a defined audience. Equipment safety controls remain with the qualified equipment system.
These controls change the explanation only. No live hoist control, AI inference, file mutation or telemetry is performed.
03 / Explore the responsibility
Who can do what?
Choose a role to inspect its intended capability boundary. There is no permission switch: selecting a role here changes the view, never the authority.
Local guide
Useful knowledge, within a defined role.
Within its declared interface
- Read context exposed through its permitted interface.
- Explain repair information and propose a next step.
- Request a scoped handoff when a declared interface supports it.
Outside that role
- Delete files or drive a hoist intrinsically.
- Acquire a file or equipment agent’s identity.
- Add tools or expand authority through learning.
A proposal names the job, target, purpose and requested operation. A separate agent evaluates it under its own authority.
File agent
Files have their own working boundary.
Within its declared interface
- Handle operations exposed by its file interface, within an authorised namespace.
- Check the requested target and required authority.
- Return the actual outcome and retained-state readback.
Outside that role
- Treat a guide’s suggestion as automatic approval.
- Reach arbitrary workspaces outside its scope.
- Command equipment merely because a file describes it.
Deletion, when offered by a particular file agent, remains a separately authorised file operation. This explorer grants no permissions.
Equipment agent
Physical action needs a qualified interface.
Within its declared interface
- Report sourced equipment state through a supported adapter.
- Evaluate a bounded request against equipment-specific authority and interlocks.
- Return observed response from qualified sensing.
Outside that role
- Move a hoist because a guide requests it.
- Infer electrical compatibility from a connector shape.
- Bypass safety controls or invent a successful readback.
Actuation requires a bound, rated interface, the right authority and target-specific qualification. None is connected to this page.
Person & governance
Learning can improve advice. Authority stays explicit.
Within its declared interface
- Define roles, permitted interfaces and handoff policy.
- Review a proposed change and authorise an explicit transition.
- Keep learning grounded in observed results and responsibilities.
Outside that role
- Treat model confidence as permission.
- Silently change an agent’s identity or capabilities.
- Assume adaptation proves safe physical operation.
BRAINK augmented learning and governance are the intended approach to keeping adaptation within a role. Drift mitigation must not silently expand identity, tools or authority.
04 / Follow the software
A practical route
from idea to integration.
Begin with the actual working surface, then qualify the services and local expertise for the intended deployment. The available website and Studio installations do not establish a deployed AI workshop or physical controller.
Prepare a workstation
Choose the repair job and authorised file space. BRAINK Workstation Studio exposes scoped files, receipts and runtime references. The integration must return the chosen file identity and actual operation result to that job; opening a guide does not bind the runtime.
Separate work from retention
ServerSpace coordinates admitted execution; StoreSpace retains and builds source-backed objects. A workstation request needs an admitted host, an authorised target and a returned receipt. Reopen the retained result to check that the mechanic and advisor are seeing the same job state.
Qualify local expertise
BRAINK AI is a separately preserved implementation under identity review. The public guide is inspection-only; no native inference or memory backend is activated there.
How do meaning, identity and recovery relate?
Vector representations describe quantities and relationships. KEX addresses state; seed, KEX DNA and keys have distinct roles in identity, constraints, encryption and continuity. IL-LLM supplies relational meaning. DNA represents constrained state for intended rehydration and failover, not an executable engine. A reconstructed state still needs an authorised runtime and a verified result. Identity/address changes and cryptographic-key rotation are different operations.
What stays local, and what connects outward?
The intended deployment separates web-connected manager workstations from a local machinery plane without a direct internet interface. Scoped handoffs join their work. This is an architecture boundary to implement and qualify, not proof of certified physical air-gapping or universal isolation.
Implementation guides behind this workshop workflow
Optional source and availability checks for the roles described above.
- Workstation Studio · scoped files and operation receipts
- ServerSpace · admitted execution and host boundaries
- StoreSpace · retained source and readback
- BRAINK AI · source identity and current availability
- KEX · identity and state reconstruction
- Vectors · representation conventions
- Edge software · local execution and reconnection
- Connected-workshop brief · equipment and acceptance scope
- Green Futures · resource-use principles
- Energy comparison · observed services and baseline model
- Readiness roadmap · integration and acceptance gates
Make the next step specific
Bring the work.
Define the roles.
Define one repair workflow: vehicle and job identity, the equipment observation, files the mechanic needs, who can authorise a handoff, and the result the advisor should see. That is the starting scope for an integration brief.
Prepare a workshop integration brief →
Opens an editable enquiry for your review. Nothing is sent by selecting this link; no order, licence or equipment permission is granted.