Fleetic Keyboard

• 

Inspiration

The real problem is not grammar. It is the hesitation before pressing Send.

Many professionals work in English even when it is not their first language. They know what they want to say, but a short Slack message or email can still trigger a familiar detour: write, feel unsure, copy, open an AI app, paste, ask for a rewrite, copy again, and return to the original conversation. That context switch costs time, and the result can sound more formal, more generic, or simply less like the person who wrote it.

I wanted the help to appear where the writing already happens, without turning the keyboard into a chatbot and without treating the user's voice as an error to erase.

What it does

Fleetic is a native Android keyboard for short workplace communication. Its core experience is deliberately small:

1. The user enables Fleetic, reviews the privacy boundary, and creates an initial Communication DNA from a natural writing sample and one refinement priority.
2. GPT-5.6 converts that sample into six understandable dimensions: brevity, formality, warmth, directness, vocabulary, and expressiveness.
3. The user types a message inside the Android app they already use.
4. Fleetic sends text only after an explicit tap on Refine.
5. GPT-5.6 returns clearer, natural English shaped by the active DNA while preserving facts, roles, tense, numbers, commitments, and intent.
6. The keyboard replaces only text it can still prove it owns. If that proof is lost, it fails safely instead of guessing. The user can keep the original text, use a Copy fallback, or undo a successful replacement.

The product promise is simple: Write naturally. Refine confidently. Stay yourself.

Why it is different

Fleetic is not a generic AI keyboard or a grammar checker with a new button. Four decisions define it:

• Personalization is explicit and inspectable. Communication DNA is a small structured profile, not a hidden claim that the system “knows” the user.
• Refine does not mean replace the person. The output may improve clarity and naturalness, but it must preserve the message's meaning and communication identity.
• Sending is always intentional. Ordinary typing stays local. A message is transmitted only when the user taps Refine.
• Text ownership is conservative. A Trusted Buffer tracks whether the keyboard can safely replace the exact message it produced. Uncertain host-app behavior becomes a safe failure, not silent text loss.

The magic moment is not “AI rewrote my text.” It is when the user reads the refined message, still recognizes themselves in it, and sends without hesitation.

How I built it

Fleetic combines a native Android input method with a small, privacy-conscious backend.

Android

The keyboard starts from AOSP LatinIME rather than a simulated text box, so ordinary typing, input-method lifecycle behavior, and host-application integration are real. New Fleetic code uses Kotlin alongside the inherited Java and native C++ engine. Jetpack Compose powers the companion setup and Communication DNA experience, while the latency-sensitive keyboard action strip remains a conventional Android View. A single credential-protected Preferences DataStore holds the anonymous installation identity, privacy acknowledgement, and structured DNA. OkHttp and strict kotlinx.serialization models form the typed API boundary.

Backend

The backend is written in Go with Chi, PostgreSQL through pgx, embedded SQL migrations, and a non-root Distroless container. It exposes versioned DNA, Refine, and post-replacement commit endpoints. The OpenAI adapter is the only package that imports the OpenAI SDK. It uses the Responses API with gpt-5.6-luna, strict structured output, explicit reasoning configuration, store: false, and no silent model fallback.

PostgreSQL stores operational metadata for idempotency, quota, rate limits, and bounded cleanup—not writing samples, messages, refined text, prompts, or raw model responses. The Android installation UUID is hashed before database use, raw content is prohibited from logs, and the OpenAI API key remains on the server.

Safety and verification

The backend validates request and response schemas, applies per-installation and privacy-preserving network abuse limits, deduplicates Refine requests without replaying message content, and commits quota only after the client reports a successful safe replacement. Tests cover contracts, handlers, prompt invariants, provider mapping, PostgreSQL behavior, cleanup, the Android API client, local identity, setup gating, and Communication DNA state.

The Android baseline has been exercised on an emulator and a physical Samsung Galaxy A54 running Android 16. That physical pass also caught and fixed 16 KB native-library alignment before it could become a judge-install problem.

How I used Codex and GPT-5.6

Codex with GPT-5.6 was a continuous engineering collaborator, not a one-shot code generator.

It first audited the product references and the inherited LatinIME lifecycle before proposing an implementation boundary. It helped turn the Build Week scope into an English PRD, acceptance tests, a delivery plan, and eighteen architecture decision records. During implementation it worked in small, reviewable backend and Android slices: typed contracts, Go handlers, the OpenAI adapter, prompt and regression tests, PostgreSQL quota semantics, cleanup, the Android visual foundation, the strict API client, local identity, privacy setup, and Communication DNA onboarding.

Codex also helped expose problems that required judgment rather than autocomplete. A synthetic mixed-language evaluation initially changed an ongoing passive Apple review into a generic active statement and changed a singular user into plural users. I rejected that output; the correction became a semantic-fidelity rule and regression fixture. On Android, verification found a native library aligned for 4 KB pages. The build configuration was corrected and rechecked on a real Android 16 device.

The human decisions remained explicit: the product scope, the meaning of Refine, the ten-use allowance, the trusted-text rules, the privacy boundary, the target host apps, and whether a proposed output actually preserved meaning. The repository's build journal records those decisions, corrections, commands, tests, and remaining limitations instead of presenting every generated change as automatically correct.

GPT-5.6 also runs inside the product. It creates the structured Communication DNA and performs meaning-preserving refinement through strict server-side contracts. Controlled synthetic evaluations are kept separate from credential-free CI so model quality checks are intentional and reproducible.

Challenges I ran into

Treating a keyboard as a trust boundary

Android input fields are controlled by other applications. Selection can move, host text can change, and a multi-step replacement can partially fail. The hardest part was defining when Fleetic truly owns a replaceable buffer and when it must stop. The resulting state machine favors preserving the original draft over performing an unsafe retry.

Improving language without changing meaning

Polished output is not necessarily faithful output. Small changes in agent, patient, tense, number, event state, or commitment can make a sentence smoother but wrong. Prompt rules, structured output, synthetic fixtures, and developer review were all needed to make semantic preservation a first-class requirement.

Adding a modern product layer to a mature input engine

Fleetic combines new Kotlin, Compose, coroutines, DataStore, and network code with an inherited Java/C++ keyboard engine. The boundary had to stay narrow so the new AI flow did not destabilize ordinary typing or add network latency to keystrokes.

Privacy-conscious anonymous limits

The demo must remain free for judges without becoming an unauthenticated public model proxy. Fleetic uses an anonymous local installation ID, server-side hashing, idempotent request metadata, bounded retention, and separate abuse controls while deliberately refusing to store message content.

Accomplishments I am proud of

• Built on a real Android input method instead of demonstrating the idea only in a custom editor.
• Turned Communication DNA into a small, visible, versioned contract with six dimensions.
• Implemented versioned Go endpoints for DNA, Refine, and quota commit with strict validation and stable errors.
• Kept provider prompts, credentials, and raw model responses behind a single server-side OpenAI boundary.
• Made privacy, safe replacement, idempotency, and data retention part of the architecture rather than submission-day disclaimers.
• Used physical Android 16 testing to catch a native compatibility problem that emulator-only work would have missed.
• Maintained a build journal that distinguishes Codex contributions, developer decisions, verified evidence, and unfinished work.

What I learned

The most useful personalization is not the most complicated profile. It is the smallest profile a user can understand and a system can apply consistently.

I also learned that AI-assisted development becomes much more valuable when every important choice has an acceptance test, a decision record, or a concrete device check. Codex accelerated the work most when it could inspect the actual system, propose a bounded change, and then help prove whether that change was safe.

Most importantly, writing assistance is a trust product. Speed and fluent output matter, but preserving the user's meaning and draft matters more.

What's next for Fleetic

After the Build Week Android MVP, the next steps are to broaden host-app compatibility, improve the keyboard experience without weakening the trust boundary, and evaluate Communication DNA across more languages and communication styles. The longer-term product direction includes iOS and desktop entry points plus opt-in learning and coaching, but only after the core Refine experience is consistently safe, useful, and recognizably personal.

Built With

• android
• aosp
• api
• chi
• codex
• compose
• datastore
• distroless
• docker
• go
• gpt-5.6
• java
• jetpack
• kotlin
• kotlinx.serialization
• latinime
• okhttp
• openai
• pgx
• postgresql
• preferences
• responses
• views