PROJECT 06 // INTENT-DRIVEN TEXT INPUT
ArcoScribe
An experimental text input system that attempts to reconstruct complete language from abbreviated input, reducing the distance between a thought and its expression.
LIVE WEB PROTOTYPE // LOCAL PROCESSING
Try ArcoScribe
Type a few letters from each word, in their original order and separated by spaces. Hints may be prefixes or span the word: cd can become could. The prototype expands and ranks the sentence entirely in your browser.
NO CLOUD
- ESTIMATED CONFIDENCE
- --
- MEASURED WORD ACCURACY
- --
- CHARACTER COMPRESSION
- --
- LOCAL LATENCY
- --
INTERPRETATION: SELECT A TOKEN TO CORRECT IT
ALTERNATIVES FOR SELECTED TOKEN
This remains a bounded, deterministic language prototype, not a finished language model. Confidence and measured accuracy are deliberately separate. Corrections stay in this browser session and are never uploaded.
Project vision
ArcoScribe interprets intent instead of demanding complete words. Characters become hints, words become probabilities, and meaning becomes the objective.
The web version is both a public demonstration and an algorithm laboratory. It makes the core interaction immediately testable without an account, installation, or cloud service.
Intent over characters
Most keyboard pipelines begin with literal character sequences, even when prediction is layered on top. ArcoScribe instead explores whether sparse character hints can express a sentence-level intention.
A short sequence such as “i w t g h” becomes a constrained sentence search. Context, candidate vocabulary, and an estimated confidence score rank “I want to go home” against other compatible interpretations.
Prediction pipeline
- Ordered character-hint recognition
- Candidate expansion
- Context evaluation
- Personal vocabulary
- Sentence ranking
- Confidence-gated completion
Method of implementation
The current web laboratory is a TypeScript reference implementation. The intended portable core is ArcoBASIC: platform adapters capture input and render choices, while the same language engine is designed to run inside the browser, Android, or Arcology OS. The example below is executable ArcoBASIC validated against the current ArcoBASIC runtime, not invented pseudocode. Its comments are part of the design: the source should teach its intention while it performs it.
Input is divided into space-separated character hints. A hint is an ordered subsequence, not merely a prefix: cd matches could because c and d appear in order, while dc does not. Exact words receive the strongest lexical score, prefixes receive a smaller bonus, and characters spread across a word accumulate a gap penalty. This keeps flexible abbreviations possible without treating every remotely compatible word as equally plausible.
Each compatible word becomes a candidate. Candidate ranking combines seven signals: base word frequency, hint-match quality, amount typed, omitted-character cost, bigram context, trigram context, and a session-learned preference. Context is what turns wh into with after go out and before me, even when what has a higher global frequency.
The sentence search keeps a bounded beam of the best partial sentences instead of committing to each word greedily. Every new hint expands the surviving paths, rescoring them with the previous one and two selected words. Only the strongest paths continue. In the current curated demonstration, this makes i cd ry u a br resolve as a complete sequence rather than six isolated guesses.
- Normalize input but preserve the writer’s original text for comparison and correction
- Generate only words containing every hint character in order
- Score lexical fit plus unigram, bigram, trigram, and learned context
- Expand sentence hypotheses through a bounded beam and retain the best 96 paths
- Estimate confidence from winner/runner-up separation and hint specificity
- Require review when confidence is low; never confuse estimated confidence with measured accuracy
- Store accepted preferences in session scope so learning is private, temporary, and reversible
' This prototype tests whether a short hint appears throughout a word.
#DESCRIPTION "ArcoScribe ordered character hint prototype"
FUNCTION MatchHint(hint, word)
' Ignore capitalization so CD, cd, and Cd express the same hint.
hint = Lower(hint)
word = Lower(word)
' Empty hints and hints longer than the word cannot match.
IF hint == "" OR String.Length(hint) > String.Length(word) THEN
RETURN {"Matches": FALSE, "Score": 0}
END IF
searchFrom = 0
first = -1
last = -1
i = 0
' Find each hint character after the previously matched character.
' This lets cd match could while correctly rejecting dc.
WHILE i < String.Length(hint)
character = String.Slice(hint, i, 1)
position = String.IndexOf(word, character, searchFrom)
IF position < 0 THEN RETURN {"Matches": FALSE, "Score": 0}
IF first < 0 THEN first = position
last = position
searchFrom = position + 1
i = i + 1
WEND
' Nearby characters are stronger evidence than widely scattered ones.
internalGaps = last - first + 1 - String.Length(hint)
score = 22 - first * 5 - internalGaps * 2
' Exact words and ordinary prefixes deserve additional confidence.
IF word == hint THEN score = 52
IF String.StartsWith(word, hint) AND word <> hint THEN score = 30
IF score < 2 THEN score = 2
RETURN {"Matches": TRUE, "Score": score}
END FUNCTION
FUNCTION CandidateScore(hint, word, frequency, bigramWeight, trigramWeight, learnedWeight)
' Incompatible words leave the candidate search immediately.
match = MatchHint(hint, word)
IF match.Matches == FALSE THEN RETURN -100000
' Combine the hint itself with surrounding words and user preferences.
missingCharacters = String.Length(word) - String.Length(hint)
score = frequency + match.Score + String.Length(hint) * 5
score = score - missingCharacters * 1.15
score = score + bigramWeight * 24
score = score + trigramWeight * 62
score = score + learnedWeight * 38
RETURN score
END FUNCTION
' These checks demonstrate letters distributed throughout complete words.
cdMatch = MatchHint("cd", "could")
ryMatch = MatchHint("ry", "really")
PRINT cdMatch.Matches
PRINT ryMatch.Matches
PRINT CandidateScore("wh", "with", 80, 2, 1, 0)Input modes
- Physical keyboard character hints
- Touch keyboard character hints
- Abbreviated stylus handwriting
- Voice intentionally excluded from Version 1
Learning and privacy
ArcoScribe is intended to learn vocabulary, names, acronyms, terminology, capitalization, and favorite phrases transparently and reversibly.
Basic functionality should remain on-device whenever practical. User vocabulary belongs to the user; everyday text entry should not require a cloud service.
Current evaluation boundary
The web prototype succeeds on its curated regression phrases, including the examples shown on this page. Those phrases also contribute to its small language model, so that result measures regression stability, not general writing accuracy.
Informal free-form use remains much less accurate and highly dependent on vocabulary and context. Confidence is an internal ranking signal, not a calibrated probability of correctness. Independent text sets, correction frequency, keystroke reduction, and latency distributions are still required before ArcoScribe can make a general performance claim.
Shared architecture
Input capture, rendering, and platform integration remain platform-specific. Prediction logic is designed to stay portable so that Android and Web can produce equivalent results.
The production goal is prediction latency below 50 milliseconds with continuous feedback and no visible pauses.
Search for intent, not for the literal input
The specific technique, ordered character-hint matching plus a bounded beam search, is one answer to a more general question: does the literal thing a user typed have to be the thing your system searches for. ArcoScribe's answer is no, and that reframing is the transferable part.
- Treat the raw input as evidence of intent rather than as the query itself. cd matching could because c and d appear in order works because the system searches for compatible words, not for an exact character sequence; the same reframe applies to search boxes, command palettes, and autocomplete far outside text entry.
- Keep a bounded set of live hypotheses instead of committing early to the single best-looking one. The beam search here rescoring the strongest surviving sentence paths as each new hint arrives is the same idea behind speculative parsing, incremental search, or any system that has to commit before it has full information.
- Separate a system's internal confidence signal from a real accuracy claim, and say so plainly. Reporting that regression-phrase success measures stability, not general accuracy, is the honest move; treating an internal ranking score as a calibrated probability is how systems end up overpromising what they actually know.
Guiding principle
A keyboard should never be the bottleneck between thought and expression.
The user provides intent. ArcoScribe provides the language.
Key terms, in plain language
You do not need a systems background to follow the work. These are the specialized terms used on this page.
- Ordered subsequence
- Characters that appear in the same order inside a word without needing to be adjacent. For example, cd is an ordered subsequence of could.
- Bigram
- A pair of neighboring words used as context. If one candidate commonly follows the previous word, its score can increase.
- Trigram
- A sequence of three neighboring words. It supplies more specific context than a two-word bigram.
- Beam search
- A search method that keeps several promising partial answers at each step, rather than committing immediately to one guess or exploring every possibility.
- Prediction confidence
- An estimate of how decisively the best interpretation beat its alternatives. It is useful for deciding when to ask for more input, but it is not the same as measured accuracy.