KEDDEH SYSTEMS
ENGINEER · AUTOMATE · SCALE
BRAINK APPLICATION BRIEF
Connected mechanic workshop
Hardware + software + people

One repair job.
A clearer working day.

Bring the mechanic, service advisor and office into the same authorised repair context, with local-first guidance and reported bay state beside the work.

DESIGN APPLICATION · INTEGRATION & HARDWARE QUALIFICATION REQUIRED

The working situation

A vehicle moves from booking to inspection to repair. The technician needs the current task and evidence; the advisor needs an accurate update; the office needs the approved record. BRAINK’s proposed workshop application connects those views through an identified repair job.

Mechanic

Opens the authorised job on a workstation, follows guidance and records inspection results.

Service advisor

Reads shared job progress, approved findings and reported bay availability from an office desktop.

Office / administrator

Manages userspace, filespace and the website-hosting relationship with named operating responsibilities.

One context. Distinct working capabilities.

Proposed application composition, with explicit handoffs between the functions that perform the work.

Repair and bay modulesCompatible diagnostic or sensing modules report observations with port identity and time.
Separate service runtimesEquipment agents, file agents and guidance have distinct captured runtimes, state and capabilities.
People’s workspacesMechanic workstation and advisor/office desktops see the context appropriate to their role.
Network ToT: identified relationships and requested behaviour.
Memory ToT: retained observations and actual readback.
Authorised handoff: task identity → admitted function → observed result → independent readback.

The modular BRAINK design combines a fixed CAT6/Ethernet side with allocated equipment connector squares. Electrical compatibility depends on each module’s driver, sensing capability and qualified device profile.

Curiosity has room here.KEDDEH-BRAINK-WS · v1.0 · 1 / 2
KEDDEH SYSTEMS
ENGINEER · AUTOMATE · SCALE
BRAINK APPLICATION BRIEF
Connected mechanic workshop
From the person to the recorded result

A useful working path

  1. Prepare the repair contextAssign the job, the authorised people, relevant files and declared equipment before any module is used.
  2. Guide the person at the bayThe local-first guidance agent explains the next step using the available job context. It does not intrinsically carry hoist-control or file-deletion operations.
  3. Request a specific functionA file request goes to a separately authorised file runtime. A supported equipment request goes to its own equipment runtime, with its own admission and state.
  4. Report what was observedRetain the device/profile identity, observed bay or hoist state, timestamp and uncertainty beside the repair record. A stale or unresolved observation stays visible as such.
  5. Hand the job forwardThe advisor reviews recorded findings; the mechanic confirms the work performed; the office retains the approved handover.

How the parts combine

The proposed deployment includes website hosting, userspace and filespace around the workshop’s public and staff-facing work. ServerSpace is the execution/coordination service; StoreSpace is the retained-source/build service. A customer filespace and repair-record workflow still require a defined application data model, permissions and retention integration.

Shape a practical first integration

The hardware remains an owner-designed modular architecture. Learning must not silently expand a runtime’s role, state scope, tools or authority. A scope change requires a separate authorised transition and renewed verification. No board rating, arbitrary-device discovery guarantee, ready-to-install package or customer deployment is asserted here. Exact module, firmware, host and application revisions must be agreed and tested.

Start with one real workflow.

Bring one repair workflow, the equipment involved and the people who need to see its progress.

Discuss your application