KHEPR / Softworks Research
a shared picture
of the field.
Aerial observation, local computing and wearable interfaces. One shared picture, with people making the decisions.
KHEPR AIRexterior study
01the idea
A camera sees something. A person sees a different screen. By the time they speak, the situation may have changed. We are interested in this gap.
KHEPR is our research into a shared operational picture: aerial observations, a local compute node and interfaces that agree about what is known, what is uncertain, and what needs a person’s decision.
We are building this from Egypt with the Softworks team. Our ambition is an integrated platform for Egypt and the Middle East, shaped by local operating conditions and the people who will use it. It is an early research programme, not a finished product.
the important part is not that the machine sees.
it is that the person can understand why.
For me, this is also a question about AI. More intelligence should bring more clarity and responsibility. A confident-looking box on a screen is not enough.
02a day with khepr
A fictional venue, one inspection team and a passage that needs a second look. Follow a proposed shift from preparation to the next handover, including the interruptions that a polished demonstration can hide.
Proposed case study · software review exists; physical deployment remains research work.
- 01
Before the site opens
Start with a record everyone can trust.
The team gathers around FIELD before inspecting a fictional exhibition venue. They agree which passages matter, who reviews observations and who is responsible for the next action. NODE is the proposed local home for that record, even when the wider connection is unreliable.
A visible readiness check should show source health, available storage and the last successful update. Missing information stays missing; the interface must never replace it with a reassuring green state.
The handoverA named reviewer, a bounded inspection brief and a shared starting revision.
KHEPR NODE
exterior studyKHEPR NODE / exterior concept. Geometry is available to inspect; physical performance remains unverified. - 02
Define the question
Ask something a person can actually review.
The first question is narrow: does the service passage need a second look before visitors arrive? A site reference and a recent source frame give the reviewer context. The team can use recorded or fixed-camera observations while aerial work remains in simulation and approved trials.
Agree what would count as useful evidence and what cannot be concluded from the view. An obscured passage is unknown, not clear. A proposal is separate from a confirmed incident.
The handoverA review question with a source, a location reference and explicit limits.
- 03
Gather context
Another angle, attached to its source.
AIR represents the proposed aerial observation point. In the scenario, a new view shows a service cart near the passage. The useful handover is the observation itself: the original frame, when it was captured, which source produced it and whether its position is known.
Preserve the source even if perception fails. An attractive model or a successful simulation does not establish flight endurance, real-world detection accuracy or permission to operate.
The handoverA timestamped observation available to inspect and replay.
KHEPR AIR
exterior studyKHEPR AIR / exterior concept. Geometry is available to inspect; physical performance remains unverified. - 04
Make sense of it
Keep the question and the evidence together.
At FIELD, the reviewer compares the new frame with the incident history. Perhaps the cart is temporary, perhaps the view is misleading, or perhaps someone should check the passage. The interface should make those alternatives easy to examine before anyone acts.
The reviewer confirms, dismisses or asks for more evidence. The decision must reference the revision they actually saw; a newer observation arriving halfway through review should not silently change that context.
The handoverA human-reviewed event, its supporting evidence and the next responsible person.
- 05
Take context to the task
A glance should be enough to reconnect.
The person on site receives the same reviewed event through the intended LENS interface. A short note explains what needs a second look, how old the evidence is and where the full record can be found. Most of the visual field remains available to the real scene.
Only attach a spatial label when alignment is valid. If pose or registration is uncertain, show an unlocated note rather than a convincing label on the wrong object. Physical optics and alignment remain research work.
The handoverOne concise task with a freshness state and a path back to the evidence.
KHEPR LENS
exterior studyKHEPR LENS / exterior concept. Geometry is available to inspect; physical performance remains unverified. - 06
Choose the right interface
More room for context, without more distraction.
For a different inspection task, VISOR explores a larger helmet-mounted display. This is an alternative interface, not a requirement to wear both devices. The same incident can be reviewed, acknowledged and dismissed without creating a separate version of the story.
Keep dismissal immediate and the real scene visible. Fit, heat, weight, visibility and any protective function require their own engineering and qualification; the current model is an exterior study.
The handoverThe same reviewed context, presented in a form appropriate to the task.
KHEPR VISOR
exterior studyKHEPR VISOR / exterior concept. Geometry is available to inspect; physical performance remains unverified. - 07
When a connection stops
Make the interruption part of the story.
A source stops updating while the inspector is moving between rooms. The last observation still matters, but it is no longer live. The interface should show its age and keep any new local note visibly pending rather than pretending it reached the shared record.
On reconnect, compare revisions and deduplicate retried changes. If another reviewer changed the event, show the conflict and ask for an intentional resolution. This recovery behavior is an acceptance target, not a field-proven claim.
The handoverA readable last-known state, a visible interruption and an explicit recovery path.
- 08
Return to the evidence
A new observation can change the answer.
The inspector finds that the cart has moved. A fresh observation is attached to the existing event so the reviewer can compare before and after. The old frame remains part of the history instead of disappearing when the status changes.
A person decides whether the question is resolved or needs another check. Closing the event should preserve who reviewed it, which evidence they used and the revision shared with the other interfaces.
The handoverA traceable resolution, or an explicitly open question for the next reviewer.
- 09
Complete the equipment cycle
Returning is part of the design.
DOCK explores what happens around the aerial platform after an observation session: a place to return, a route for transferring evidence and a future charging relationship. The journal should make outstanding transfers visible before the team considers the session complete.
Treat mechanical alignment, charging and docking control as separate engineering questions. The exterior preview is useful for discussing form and access; it does not demonstrate autonomous landing or reliable charging.
The handoverA proposed return station and a clear record of what has, or has not, been received.
KHEPR DOCK
exterior studyKHEPR DOCK / exterior concept. Geometry is available to inspect; physical performance remains unverified. - 10
The next shift
Leave the reasoning, not just the final status.
The next team should be able to understand the inspection without reconstructing it from scattered messages. The record links the original question, observations, interruptions, human reviews and unresolved follow-ups. A replay should tell the same story as the live interfaces.
A future controlled study would compare this journey with the team’s current process: time to a reviewed decision, duplicate handovers, recognition of stale information and whether another person can reconstruct what happened. No field improvement has yet been measured.
The handoverA useful shift record, with evidence and uncertainty still attached.
03the product family
The family is designed around a flow of information. Hardware gives it a place in the world; the shared software gives it continuity.
- air s1the observation point
A compact aerial-platform study for inspecting a site from another angle. The current work is in simulation; the exterior model is not flight-qualified.
simulation + exterior concept- dock d1a place to return
A station concept for landing, charging and handing observations back to the local system. Mechanical alignment, charging and autonomous docking still need engineering and tests.
planned hardware- lens l1information in your line of sight
Everyday AR glasses that could bring a reviewed incident into the operator’s view. The shared software preview exists. Physical optics, spatial alignment and wearable hardware do not yet.
software preview + hardware study- visor v1a field display, explored
A more substantial wearable display concept for demanding settings. Fit, visibility and safe interaction are open questions. It has no protective-equipment certification.
early design study- node n1local intelligence
A portable compute enclosure intended to run the shared state and perception close to the site. Cooling, battery life, connectivity and compute selection remain to be validated.
software core + enclosure study- field f1the operator’s desk
A portable laptop-based workspace for Command: review observations, understand system health and make decisions with the evidence beside them.
working desktop workflow
DOCK / a place to return
KHEPR DOCKexterior study
names describe the intended product family. renders and the 3d model are design studies, not manufactured or certified equipment.
04the visual notebook
One family, different points of view. These studies explore the shape of the system before its physical parts are engineered. The gallery keeps the complete frames; open any study for a closer look.
Current exterior study. Inspectable geometry; physical performance remains unverified.
05hardware starts with constraints
The first hardware question is not “which chip looks impressive?” It is what the workload needs, what the operator carries, and what can be measured reliably. We plan to choose parts after recording representative workloads, not before.
- compute & memory
- Benchmark observation processing, inference and evidence storage together. Measure tail latency and peak memory before choosing a CPU/accelerator mix. Reserve headroom for the review interface; a busy model must not make the operator view unresponsive.
- thermal design
- Build a sustained-load bench test, log temperatures and look for throttling. Cooling depends on enclosure airflow, dust, ambient heat and serviceability. A render cannot tell us whether a sealed box will survive a long day outside.
- power & service
- Measure the full node, including storage and networking. Separate peak demand from average draw, and keep a defined reserve for clean shutdown. Connectors, replaceable modules and repair access should be reviewed before a custom enclosure.
- observations & timing
- Every sensor-facing interface needs source identity, timestamp, calibration version and health. Clock uncertainty belongs in the quality model. Spatial estimates need explicit frames and units, not unexplained coordinates.
- glasses & optics
- Start with a desktop preview, then evaluate a suitable display device. Test alignment drift, motion-to-display delay, readability, weight and fatigue. Sparse, reviewed information is more useful than filling the lens with labels.
- air & dock
- The exterior studies define a visual family. Mechanical, electrical, charging and environmental validation are separate workstreams for qualified partners, under the required permissions. Physical aerial trials are outside the present software demonstration.
what does local compute cost in power?
240 wh × 0.80 ÷ 45 w
planning arithmetic, not a battery specification or measured runtime. assumes 80% usable energy after reserve/losses and a steady load. excludes aircraft, docking and charging other devices. temperature, battery ageing and peak workloads will change the result.
06how it connects
Core is the shared software authority. Command is the review workspace. The goal is simple to describe and quite difficult to get right: every interface should agree on the same event, with its evidence and its age.
The local Core keeps the authoritative incident state: observations, human decisions, timestamps and revisions. NODE is the planned enclosure for field compute. An AI suggestion does not become a confirmed incident by itself.
event_id · revision · evidence_agea logical connection map. physical radio links, coverage and field reliability are not yet qualified.
We want critical context close to the site, so a remote service is not the only place where information can make sense. That is a design goal; offline endurance, network recovery and field reliability still need dedicated validation.
07ai glasses. less screen, more context.
LENS L1 is the lighter interface: a quick look at a reviewed event, its location if known, and the age of the supporting evidence. We want less time switching screens, without putting a second dashboard in front of someone’s eyes.
KHEPR LENSexterior study
- candidate stack
- A commercial optical see-through developer headset first, with its supported pose and display SDK. A tethered phone or NODE would handle heavier work. Custom optics come after the interface is useful.
- what appears
- One event summary, a freshness indicator and a reference back to the evidence. Spatial labels only when pose and registration are valid; otherwise a clearly unlocated note.
- what we must measure
- Text legibility across light levels, label drift during head motion, motion-to-photon delay, recognition of stale evidence, comfort and task completion time. No measured hardware results yet.
A pair of glasses with a camera is not automatically AR. Reliable anchoring needs the camera, head pose and display to share a calibrated space and clock. Our software-state work is useful groundwork; it does not solve those optical problems by itself.
08a helmet interface, carefully explored
VISOR V1 explores the same context in a helmet-mounted form for civilian maintenance and site inspection. It may offer more mounting space, but that also creates questions about balance, heat, visibility and attention.
KHEPR VISORexterior study
modular, by intention
Explore a removable display module and replaceable attachment parts. Keep compute and battery mass away from the face where possible. Access to the real scene must remain clear when the display is off.
fit before features
Evaluate centre of mass, eye relief, prescription eyewear, ventilation and use with gloves. Any change to protective equipment needs a qualified manufacturer and relevant testing; a render cannot establish protection.
The first useful experiment is a seated interface and fit study. Next comes a controlled task study with an appropriate commercial platform. A custom helmet is a later engineering programme, with its own certification budget and partner.
09what belongs in your field of view?
AR should explain uncertainty in the same place it presents information. Enter the first-person lens view, look gently around the scene and try the three evidence states. The labels follow the view; their certainty changes with the evidence.
see it from here.
from inside the frame
A cart is near the passage. The interface offers an observation for review, with its age and source. A person still decides what it means.
an ai-generated scene with authored, animated labels and a bounded first-person view. it demonstrates an intended experience, not real glasses, live detection or measured ar tracking. no camera access.
Reprojection error compares an observed image point with its predicted location. We would record it alongside pose age and confidence, then test label stability across motion and lighting. A low error in one still frame does not establish robust tracking.
- register. Establish camera intrinsics and the camera-to-display transform using the selected development hardware.
- align time. Relate the frame timestamp to the pose timestamp. Keep uncertainty visible when clocks or delivery are unreliable.
- project. Transform a known site reference into the view. Gate the anchor on tracking validity and evidence age.
- degrade clearly. If alignment is lost, withdraw the spatial claim and retain readable context. Recovery must not silently reuse an obsolete pose.
- evaluate. Measure drift, relocalisation time and users’ interpretation of uncertainty in controlled trials.
planned research sequence. No qualified visual-inertial odometry, SLAM or physical world-locked overlay is claimed.
10node / intelligence close to the site
NODE N1 is the proposed local server. Its job is continuity: accept observations, run suitable perception workloads, persist the evidence journal and serve the current incident revision to the interfaces on site.
KHEPR NODEexterior study
- compute candidates
- An 8 GB edge-AI development kit for profiling, compared with an x86 mini-PC configuration with 16–32 GB RAM. Selection depends on sustained measured latency, model memory and thermals—not a peak TOPS figure.
- storage hypothesis
- 512 GB NVMe as a prototype starting point, with explicit retention limits and separate event metadata. At an assumed constant 4 Mb/s, one video stream produces about 1.8 GB/hour; actual encoding and retention must be measured.
- network boundary
- Start with wired local networking. Add wireless only after measuring loss, jitter and reconnection. A network partition must not create two independent authorities for the same incident.
- power & heat
- Profile total wall power including storage, cooling and networking. The 25–90 W envelope in the energy calculator is a planning range, not a measured NODE load or a battery guarantee.
- serviceability
- Replaceable storage, accessible filters and documented recovery. Future field packaging needs dust, thermal, vibration and power-interruption tests before a ruggedness claim.
failure is part of the architecture
A camera disconnect should affect freshness, not erase the event. A restart should recover the journal without inventing new decisions. Storage pressure needs a visible policy rather than silent evidence loss. These are acceptance tests we want for NODE, alongside authentication and role-scoped access.
a logical local processing path. deployment hardening, partition recovery and physical packaging remain to be qualified.
11one incident, from doubt to decision
Our current demonstration uses a fictional venue. A service cart appears near an exit. The interesting part is what happens after the first detection.
- observe. A camera frame arrives with its timestamp and source. Evidence has an age.
- propose. An AI observation becomes something to review. It does not automatically become a confirmed incident.
- decide. A person checks the evidence and confirms or dismisses it.
- share. Command and the Lens preview read the same incident revision.
- notice uncertainty. If the camera stops updating, the observation becomes stale. The interface must say so.
- close and learn. New evidence and a human decision can close the incident. The journal preserves what happened for replay.
a software and simulation workflow. this does not demonstrate real-world detection accuracy or physical flight readiness.
12notes from the difficult part
The maths matters because uncertainty is not a UI problem. These are research questions we are working toward, not claims that the complete algorithms are already running in the field.
what does the system actually know?
An observation changes a belief; it does not remove uncertainty. We need to understand false positives, missed observations and how confidence changes with lighting, distance and unfamiliar scenes. A working camera prototype is only the start. Held-out evaluation and calibrated uncertainty are still required.
a label must belong to the place it describes
A world point, a camera pose and a display projection have to agree. Pose error becomes visible drift. Research here includes coordinate frames, time alignment, calibration and the error between an expected and an observed image point. Reliable spatial mapping and real glasses alignment are not yet qualified.
correct information can still be too old
We track evidence age and incident revisions in the software flow. The harder next work is delayed messages, dropped connections, conflicting updates and recovery. The interface should preserve the difference between “clear”, “unknown” and “not recently observed”.
failure should teach us something
Replayable observations and human decisions let us ask useful questions: Was the evidence fresh? Did two screens show the same revision? Did the user understand the uncertainty? Physical perception, docking and fleet behaviour need their own independent test programmes.
13the software underneath
Our direction is event-based: keep the observation, the proposed interpretation and the human decision as separate records. This makes a decision explainable and a run replayable. It also stops a later model output from silently rewriting what somebody approved.
from observation to shared context
on a small screen, swipe across the diagram ↔
The proposed information path: timestamped observations become reviewable evidence, Core holds incident state, and Command, Lens and replay read that state. Source health can mark evidence stale. This is a logical software diagram, not a qualified physical network.
view diagram source
flowchart TB
A[Timestamped observation] --> B[Perception proposal]
B --> C[Evidence and quality checks]
C --> D[Core incident journal]
D --> E[Command review]
E -->|human decision| D
D --> F[Lens preview]
D --> G[Recorded replay]
H[Source health] -->|fresh / stale / unknown| Dthe evidence envelope
Source ID, capture time, receive time, model/calibration version, quality flags, a frame reference and the incident revision. Store enough context to understand a result later, without keeping unnecessary personal data.
the update contract
Validate actions on the server, commit a decision and its event together, and make retries safe. Reject an outdated revision instead of quietly overwriting a newer decision. Reconnecting clients ask for what they missed.
two screens, one revision
on a small screen, swipe across the diagram ↔
Illustrative review exchange: both clients receive revision 12; an accepted review commits revision 13; a later write based on revision 12 is rejected. It describes the intended consistency rule, not a performance guarantee.
view diagram source
sequenceDiagram
participant V as Command
participant C as Core
participant L as Lens
C->>V: incident / revision 12
C->>L: same revision 12
V->>C: review / expected revision 12
Note over C: authorise, validate, commit
C-->>V: accepted / revision 13
C-->>L: updated / revision 13
V->>C: late update / revision 12
C-->>V: conflict / reload current state// illustrative review contract, not a public API
type Review = {
incidentId: string
expectedRevision: number
decision: 'confirm' | 'dismiss'
requestId: string // retry the same intent safely
}
async function review(input: Review, actor: Reviewer) {
requirePermission(actor, 'review')
return transaction(async tx => {
const prior = await tx.requestResult(input.requestId)
if (prior) return prior
const current = await tx.incident(input.incidentId)
if (current.revision !== input.expectedRevision)
throw new RevisionConflict(current.revision)
return tx.commitDecisionAndEvent(input, actor)
})
}A public sketch of the approach, not source copied from an internal repository. The actual implementation must validate inputs, scope retry keys to the actor and intent, and enforce the revision check atomically.
When a connection fails, the interface should keep the last known evidence with a visible age. It should not make an old observation look live. Recovery must prove that the interfaces converge again, rather than simply reconnecting a socket.
14from the development bench
This is the part of the notebook with receipts. These frames and numbers come from retained development artifacts, recorded before this page was made. They are separate from the AI-generated product studies.
how long a frame took
pipeline time / millisecondsCPU execution · 2 inference threads · 10 warm iterations per fixture. Published report median and p95; small-sample timing only.
Recorded image-pipeline timings, not camera-to-display latency, FPS under load or accuracy. The CPU model is not recorded in this report; cross-machine comparisons would be premature.
the useful finding is the gap
Three of the four scene fixtures produced zero object detections. The remaining ground-view fixture produced one chair proposal. We have not measured held-out precision, recall or average precision, and a confidence score is not a calibrated probability of correctness.
The next evaluation needs independently labelled scene sequences, split by scene and capture session rather than random neighbouring frames. We need false alarms per camera-hour, missed events, precision–recall curves and performance by light, distance and occlusion. Thresholds should be selected on validation data, then frozen before the test set is opened.
recall = TP / (TP + FN)
evaluation definitions, not current scores. An object box and an operational event need separate labels and separate evaluation.
def detect(self, bgr, threshold=0.5):
if not isinstance(bgr, np.ndarray) or bgr.dtype != np.uint8 or bgr.ndim != 3 or bgr.shape[2] != 3 or min(bgr.shape[:2]) < 1:
raise ValueError("Expected a nonempty uint8 BGR image")
if not 0 < threshold < 1:
raise ValueError("Threshold must be between zero and one")
started = time.perf_counter()Input validation from the working detector. Bad image data fails explicitly before inference. This is selectable source text, not a screenshot of an editor or a staged team work session.
To reach a real spatial view, we would need a defined local coordinate frame, timestamped camera poses, camera intrinsics and extrinsics, and a measured transform into the site frame. A future geographic overlay also needs a surveyed reference and an explicit coordinate reference system. None of that can be inferred from a good-looking aerial image.
what the retained reports actually say
- earlier simulation
- Recorded route / return / landing and replay: passed in that earlier environment. The retained run contains 78 event revisions and 65 captured frames.
- new simulation environment
- Camera and API access worked. Native takeoff and hover returned failures; the remaining route was not run. Earlier passes do not qualify this integration.
- coverage snapshot
- 930 / 1195 statements covered: 77.82%. Below the project’s 80% gate. Coverage describes exercised code, not physical safety.
- still missing
- Held-out aerial accuracy, real optics, verified field networking, physical docking and qualified endurance. No deployed customer or certified hardware claim.
15a measurement plan, not a scorecard
These are proposed starting targets for a controlled software trial, not measured results or product specifications. We will revise them after the baseline. Hardware, scene complexity and network conditions must be recorded with every result.
- review visibility
- p95 ≤ 500 ms
observation received at the node → review UI updated, on a defined local test setup
- shared revision
- p95 ≤ 150 ms
accepted review → both desktop views display the committed revision
- freshness signalling
- ≤ 2 s threshold
mark evidence stale once its age crosses the configured demo threshold; never label it “clear”
- local continuity
- 30 min trial
a bounded disconnected session with local evidence and a complete replay after recovery
- repeatable state
- 0 divergent revisions
in the scripted review/conflict/reconnect acceptance suite; not a claim of zero production failures
- perception quality
- baseline first
report precision, recall, false alerts per hour and misses on held-out scenes before setting a numeric gate
how we would test it
- Freeze a small scenario set and a versioned configuration. Keep development scenes separate from held-out evaluation.
- Record capture, receipt, inference, commit and display timestamps. Report median and p95, plus failures and sample count.
- Repeat with delayed frames, source interruption, dropped connections, conflicting reviews and a restart.
- Compare the observed screen state with the event journal and replay. Publish the scope and conditions beside the numbers.
For perception, a good average is not enough. We need results by lighting, distance and scene type. For AR, measure alignment and comfort on the actual device. For the node, measure sustained load and thermal behaviour. Each has its own pass criteria.
16different sites. the same need for clarity.
We are starting with inspection and human-reviewed safety workflows. The value is shared context, fewer disconnected screens and a clearer record of decisions.
01 / a venue before opening
The situation. A facility team needs to review whether a service cart is obstructing an exit. Different people are looking at different screens.
The proposed flow. An observation is attached to an incident, a person checks the original frame, and the same reviewed state appears on the other interfaces. A source interruption visibly changes freshness.
What matters. Time to a reviewed decision, missed obstructions, false alerts and whether old evidence is mistaken for live evidence. This is the current fictional-site demonstration story.
02 / maintenance across a large site
The situation. An inspection team needs to document equipment condition and hand an issue to maintenance without losing the original evidence.
The proposed flow. Keep an asset-linked observation, its review history and a new observation for closure. An authorised aerial observation could eventually add another viewpoint after physical validation and approval.
What matters. Evidence completeness, useful alerts per inspection and whether another person can understand the handover. No automated diagnosis or guaranteed defect detection is claimed.
03 / a disconnected training exercise
The situation. A civil-response team practices coordination while connectivity becomes unreliable.
The proposed flow. The local node retains evidence and decisions, interfaces show their connection/freshness state, and the team replays the exercise afterward. Complete offline operation is a validation goal.
What matters. Whether people recognise uncertainty, whether decisions survive interruption and whether replay explains the sequence. This is a training concept, not a life-critical deployment claim.
04 / security and defence-estate support
The situation. Appropriately authorised teams need a clearer non-combat facility-safety record across shifts.
The proposed flow. Review site observations, document decisions and hand over unresolved issues with current evidence. The same approach could support infrastructure inspection and training.
What matters. Accountable reviews, relevant evidence and fewer inconsistent handovers. No customer deployments, biometric identification, targeting or weapons-control capability are presented.
The current scope does not include autonomous targeting, identifying individuals or weapons control. Permissions, privacy and human accountability have to be part of the product, not a later attachment.
17what we want to become
built in egypt.
useful on the ground.
understandable by people.
We want KHEPR to become a company that understands the complete journey from an observation to a human decision. The software, the physical interface and the record should feel like one considered system.
Our starting point is deliberately specific: site inspection and shared awareness. A useful result in one controlled setting would teach us more than a wide list of features that nobody can depend on.
- nowbuild trust in the record
- Make the software repeatable. Keep timestamps, revisions and evidence traceable. Show a failed check as clearly as a successful one.
- nextearn a place in the field
- Evaluate perception, wearable legibility and local compute with suitable partners. Seek the permissions and independent expertise required for a bounded physical pilot.
- laterconnect more of the site
- If earlier results justify it, grow toward serviceable hardware, useful spatial interfaces and integrations that respect the operator’s existing workflow.
what we would like to become known for
- evidence you can question. A clear path back to the observation and the person who reviewed it.
- interfaces that know when to be quiet. Enough context to help, with uncertainty visible and unnecessary information out of the way.
- engineering that can be maintained. Documented interfaces, repairable physical choices and a clear recovery story.
- local ownership, serious collaboration. Build capability in Egypt with research, manufacturing and operational partners who can challenge the work.
bring us a real inspection problem.
We would like to speak with facility teams, optics and hardware engineers, research groups and patient investors. A useful first conversation is about the task, the evidence needed and what would make a pilot worth continuing.
start with a private research review18the business behind the research
The business hypothesis is a local system for organisations that need to inspect a site and coordinate a human response. We would start with one bounded civilian workflow, prove its value with a partner, then decide which hardware deserves to become a product.
sell a useful, accountable workflow.
earn the right to build the whole family.
first buyer hypothesis
Venue operators, industrial facilities and infrastructure inspection teams. A pilot would begin with their inspection process, permissions and evidence requirements. We have not validated demand or willingness to pay.
commercial shape
A paid discovery and integration phase, an approved pilot kit, then software maintenance and support. Recurring pricing should follow the service burden and measured value; it is not priced or contracted yet.
hardware shortlist / not a purchase order
- edge compute reference
- Jetson Orin Nano Super developer kit: the NVIDIA marketplace lists US $399 and out of stock when checked on 25 October 2026. An 8 GB development platform, with 7–25 W module modes. Availability and landed Egyptian cost require a fresh quote.
- depth bench reference
- OAK-D Lite: Luxonis lists US $269, a 13 MP RGB sensor, stereo depth and USB connectivity. A candidate for controlled depth experiments, not a selected aerial payload or a proven KHEPR component.
- selection gates
- Measure sustained latency and memory, confirm software access and component supply, then test thermal behaviour and total power. Commercial reference hardware reduces early uncertainty; it does not remove integration work.
specification references: NVIDIA developer-kit guide · NVIDIA configuration. Peak vendor compute figures are not measured KHEPR throughput. Manufacturer listings are reference points, not supplier commitments.
what one unit might cost
These are author-proposed USD planning allowances, not supplier quotations or final product prices. The midpoint includes an allowance for parts, assembly, unit checks and a small replacement reserve. Production engineering, import duties, taxes, delivery, certification and programme R&D are excluded and could materially change the economics.
| product / allowance | cost range | base cost | modelled price |
|---|---|---|---|
| air s1approved inspection platform, observation payload, batteries, integration & unit test allowance | $1,800–$3,400 | $2,600 | $4,000 |
| dock d1enclosure, charging interface, electronics, assembly & bench verification | $600–$1,200 | $900 | $1,385 |
| lens l1commercial display reference, tether/accessories & interface integration | $800–$1,400 | $1,100 | $1,692 |
| visor v1commercial display, fit fixtures & removable module study; certification excluded | $1,200–$2,400 | $1,800 | $2,769 |
| node n1compute, NVMe, cooling, enclosure, power/network parts & assembly | $800–$1,400 | $1,100 | $1,692 |
| field f1commercial laptop, transport case, setup & unit test allowance | $1,200–$2,000 | $1,600 | $2,462 |
price = assumed unit cost ÷ (1 − margin). This is gross margin, not markup or net profit. The all-six total is a research scenario, not a recommended customer bundle. Unquoted landed costs, service work and low-volume rework may reduce or erase the margin.
fund the next evidence, in stages
The current software plan estimates 75–117 engineer-days with contingency. That is an internal planning range, not a delivery promise, and it does not complete the six physical products. Hardware and certification need their own estimates.
A budgeting exercise prepared for this journal, not a fundraising commitment, salary benchmark or complete launch budget. Tax, import, certification, legal approvals and commercial runway need separate quotations. This does not finance deployment-ready custom aircraft or protective equipment.
- software gate. Repeatable shared-state and recovery tests, bounded replay, documented remaining failures.
- perception gate. A held-out dataset and agreed error tolerance for one inspection task. Stop if the evidence does not support the use case.
- wearable / node gate. A measured interface study and sustained power/thermal profile on commercial reference hardware.
- pilot gate. An authorised partner, signed scope, costed support and explicit acceptance criteria before physical deployment.
What could make KHEPR valuable is the continuity between evidence, local computation and human decisions. What could make it fail is equally concrete: unreliable perception, distracting wearables, difficult approvals or hardware that costs more to support than customers will pay. We want partners who will help test those assumptions early.
19where we are, honestly
software prototype
Shared incident state, human review, evidence history, replay and connected desktop/Lens previews. Camera-perception experiments and fictional-site simulation. AIR + DOCK exterior modelling.
the physical system
Real-world aerial accuracy, reliable spatial mapping, physical glasses, autonomous docking, multiple aircraft and field endurance. No claim of flight authorisation, product certification or deployed customers.
- 01
make the software dependable
Strengthen the shared workflow, replay and fault tests. Define clear acceptance criteria.
- 02
qualify what it can perceive
Build representative evaluation data, measure errors and test degraded conditions.
- 03
engineer the physical interfaces
Select compute and sensors, study thermal and power limits, and validate AR calibration and ergonomics.
- 04
seek an approved pilot
Complete the relevant legal and permission work, then run a bounded physical trial with suitable partners.
- 05
expand only after evidence
Docking and larger connected deployments come after the earlier reliability and approval gates.
20built in egypt. responsibly.
KHEPR is in an invitation-only concept stage. We are opening private software demonstrations and research conversations, while physical deployment remains dependent on engineering validation and the required approvals.
Egypt restricts drone import, production and use without prior permission. The Ministry of Civil Aviation describes Ministry of Defence approval followed by a flight-permit application. We are not presenting this concept as permission to import, manufacture or fly a drone.
Our legal and approval work is part of the path ahead. This page does not claim that applications have been filed or authorisations granted.
approval references: egypt ministry of civil aviation · uk government guidance for egypt. requirements should be confirmed with the relevant authorities for each proposed activity.
want to help build khepr?
We would like to meet investors, research partners and engineers who understand that serious systems take patient work. The next stage needs support for evaluation, hardware engineering, wearable interfaces and the legal path to approved trials.
I can walk you through the concept, the working software and the questions we have not answered yet. We can discuss the team, milestones, risks and what a useful partnership would look like in a private conversation.
let's talk investmentWritten by Ahmed Mostafa with the Softworks team. KHEPR identity and current product models from the published KHEPR asset library. Models include owner-supplied exteriors and reconstructed design studies. The first-person AR view remains a generated interface illustration.