--- title: "Kenyan Sign Language Justice Counter Interpreter" date: "2026-07-27" canonical: "https://raytally.com/en/ideas/2026-07-27-idea-85aafd94/" generator: "RayTally · dev-prompt-v4" signal: query: "I wish someone could build an app that tracks hand gestures and facial movements used in Kenya Sign Language to translate it into speech. I hate seeing how deaf people are especially excluded from our justice system because we do not have translators. Abu Iman (@Mr_Guantai) July 25, 2026" observed_at: "2026-07-27T00:34:01.976Z" sources: - url: "https://www.parliament.go.ke/node/26035" boundary: "Published at 2026-06-26T00:00:00.000Z." - url: "https://x.com/Mr_Guantai/status/2081070905275429312" boundary: "Published at 2026-07-25T17:35:42.000Z. Observed at 2026-07-27T00:34:01.976Z." - url: "https://ai.google.dev/edge/api/mediapipe/python/mp/tasks/vision/HolisticLandmarkerResult" boundary: "Published at 2026-06-05T00:00:00.000Z." - url: "https://signvrse.com/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-27-idea-85aafd94/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Kenyan Sign Language Justice Counter Interpreter At Kenyan justice-service counters, KSL users can confirm a sign-language back-translation before their message is spoken aloud, leaving a verifiable bilingual record. ## Product concept When a Deaf Kenyan needs to explain a situation at a police station, court counter, or legal-aid office, they sign in Kenyan Sign Language (KSL) in front of a counter tablet. The camera captures signing, body position, and facial expressions—the grammatical signals the system needs. A transcript first appears on screen, then a sign-language animation plays back the intended message for the signer to confirm. Only after the user selects “meaning is correct” does the system play the message aloud in Swahili or English for the counter staff, while displaying the text. If recognition confidence is low for a segment, the interface highlights it and asks the user to repeat it or type instead. For complex legal wording, staff can call a remote human interpreter with one tap rather than letting the machine guess. After the conversation, both sides can export a bilingual summary with timestamps, the original content, confirmation records, and translations. Deaf users can choose to save it only on their own device or share it with a lawyer, legal-aid organization, or a later case-handling counter for verification. Staff can see only what is needed for the current exchange, not the person’s full history of requests. The first version focuses on high-frequency counter conversations: appointments, incident reports, document submission, and rights notifications. It initially supports short KSL exchanges into English and Swahili. It does not replace certified interpreters, provide legal advice, or treat an unconfirmed machine translation as a formal statement. ## Why now (backed by facts) On June 26, Kenya’s National Assembly passed amendments to the Kenyan Sign Language Bill, which would strengthen responsibilities for sign-language services in courts and public institutions. On July 25, a request for an app addressing the justice system’s lack of interpreters received 361 likes, 134 reposts, and 10,400 cumulative views, bringing the gap in short counter exchanges and user confirmation into focus. ## Direction (model inference, not independently verified) Target user: The core users are KSL signers visiting a police station, court counter, or legal-aid office alone. They especially need to confirm what staff understood when reporting an incident, submitting additional documents, or first receiving a rights notification. A changed subject, time, or negation in a single sentence can affect what happens next. Counter staff and remote interpreters are collaborative users who need to see the original segment, confirmation status, and reason for human handoff. Minimal entry point: Build the counter experience as an offline-first tablet web app using the browser camera. MediaPipe Holistic Landmarker can extract landmarks for both hands, body pose, and face, providing an input layer for signing features. KSL users and legal interpreters should jointly record the training data, limited to short phrases for appointments, incident reports, document submission, and rights notifications. Use a closed vocabulary and sentence-pattern classifier rather than open-ended legal statements. For back-translation, drive a standardized avatar with reviewed motion clips instead of freely generating signs from arbitrary English. Low-confidence segments should directly prompt a retry, typing, or a human call. Store confirmation records separately from video, with records kept on the user’s device by default. The strongest case against: Continuous KSL recognition must account for signing, body position, and facial grammar, and a small short-phrase dataset can easily miss regional and individual variation. If a legal negation, subject, or time reference is recognized incorrectly, users may confirm a translation they did not truly understand. The camera also captures faces and case details; a lost device, retained backend data, or misconfigured permissions could expose sensitive information. Counter lighting, framing, and network conditions add further failure points. If human handoff cannot connect quickly, the process may be slower than pen and paper. A bilingual summary must not be presented as formal testimony, or institutions assume risk for record authenticity and procedural fairness. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Recruit the first testers through Deaf organizations and community legal-aid centers, not broad consumer marketing. A solo builder can demonstrate a complete reporting flow on one tablet and ask KSL users to flag misunderstandings sentence by sentence. Publish the revised controlled phrase list for interpreter and legal-aid review. Show pilot results only as completion rates, reasons for human handoff, and deletion procedures, so public institutions can assess whether deployment is worthwhile. ## Competitors & gaps (model inference) - Signvrse Terp 360: Terp 360, offered by Nairobi-based Signvrse, provides real-time translation from speech or text into sign language through a 3D signing avatar. Its website also describes two-way conversion between sign and spoken language. That already covers the core capabilities of general translation and sign-language playback. Its public materials do not emphasize a justice-counter workflow or user confirmation before a statement is delivered. Nor do they connect low-confidence segments, human handoff, and bilingual summaries into an evidentiary trail. The opportunity is not another general-purpose translator, but a constrained legal-context product. Each playback should be tied to the user’s confirmation, and unconfirmed content must not enter the summary. Reporting, rights notifications, and document submission also require distinct templates. - Human sign-language interpreters with pen and paper or phone typing: Certified human interpreters remain the safer option for complex legal communication. They can ask about context, handle regional signing differences, and assess when legal terms need explanation. Pen and paper or phone typing are immediately available and require no trained model. Together, they are the currently acceptable alternatives at service counters. The limitation is that an interpreter may not be available for an unplanned visit, while writing pushes KSL users toward a written language they may not use fluently. Human-assisted exchanges also do not usually generate a bilingual, segment-by-segment confirmation summary. The product should preserve the authority of human interpreters and handle only short exchanges such as appointments and document submission. It should immediately hand off to a person for free-form statements or rights waivers. That improves response speed rather than replacing professional judgment. ## How it makes money (model inference) Charge courts, police stations, and legal-aid providers a monthly fee per service-counter terminal. The fee covers device management, the controlled vocabulary, and summary exports. Remote human interpreters are billed separately by connected time. ## Source context Theme: Real-time Kenyan Sign Language speech translation Trigger Web Trend observation: X @Mr_Guantai — I wish someone could build an app that tracks hand gestures and facial movements used in Kenya Sign Language to translate it into speech. I hate seeing how deaf people are especially excluded from our justice system because we do not have translators. Abu Iman (@Mr_Guantai) July 25, 2026 Source metric: 点赞 361 / 转发 134 / 浏览 10400 (发布后累计) This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.” ## Sources - National Assembly backs Kenyan Sign Language Bill, expanding rights and access for Deaf community (https://www.parliament.go.ke/node/26035) - I wish someone could build an app that tracks hand gestures and facial movements used in Kenya Sign Language to translate it into speech (https://x.com/Mr_Guantai/status/2081070905275429312) - HolisticLandmarkerResult | Google AI for Developers (https://ai.google.dev/edge/api/mediapipe/python/mp/tasks/vision/HolisticLandmarkerResult) - Signvrse | AI-Powered Sign Language Translation (https://signvrse.com/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.