Language
Language brings the book, Reader, Workbench and a real multi-model manuscript revision around one practical problem: when AI transforms a message, how do we inspect what survived, correct what changed and control what happens next?
A place to work with meaning
You ask an assistant to review a document. It returns a clear explanation. Another assistant takes that explanation as context and proposes a change. By the third exchange, an exception has disappeared, a tentative conclusion has become a fact, and a request to prepare something has become an apparent instruction to execute it.
Each reply can look reasonable on its own. The failure sits between them.
Language is a project for making that passage inspectable. Keep the expression or source available. Make the interpretation explicit enough to challenge. Preserve uncertainty and the conditions governing a claim. Record corrections as changes with consequences. Carry the revised state forward without treating it as permission to act.
The current project has two working surfaces: Language Reader, which explores what survives a change of representation, and Language Workbench, which explores how participants propose, accept, revise and transfer meaning. A third application puts the design principles to work on a real artifact: multi-model editorial revision of the Language manuscript itself. The illustrated book supplies the argument and distinctions behind this work. The complete communication environment remains a direction for development.
Start with the book, inspect the prepared Chapter 11 companion, or run the local prototypes. The companion is part of the staged website integration; the local prototypes are available in the repository.
The outcome to aim for
A useful communication workspace should let you answer concrete questions:
- Which source and version support this statement?
- What was quoted, interpreted, supplied from elsewhere or generated?
- Which qualification disappeared when the representation changed?
- Is this an accepted instruction, a model proposal or an unresolved assumption?
- What did a correction change, and which earlier conclusions depended on it?
- What did a fresh participant actually receive?
- Who may perform the proposed action, on which target, under which current grant?
These questions serve different purposes. A source link does not certify an interpretation. Human acceptance records a decision about meaning without establishing that every underlying claim is true. An accurate interpretation does not supply an action grant.
The practical deliverable is a view or shared record whose contents and standing can be examined, together with enough history to contest it.
The communication loop
Original expression or identified source
|
Proposed interpretation
|
Inspect, challenge and correct
|
Human acceptance where required
|
Task-facing view or bounded transfer
|
Observe the recipient's response
|
Reconsider the affected interpretation
An external action introduces another boundary: check the actual operation, recipient, data use, limits and current authorization. It does not follow automatically from the loop.
This is the common design idea. The Reader and Workbench currently implement different parts of it; they are separate applications, and a seamless shared workspace between them has not yet been delivered.
Conceptual architecture from the book. The shared record remains an interpretation; consistent views can share the same error. Open the diagram.
Start small: inspect one transformation
The Reader begins with a constructed retry policy:
For non-idempotent payment requests, allow at most three attempts in total. Idempotent requests follow the separate recovery path. Handling of third-party timeouts remains unresolved; consult design record D-17 before changing this policy.
A fluent summary might turn this into “retry failed payments three times.” That loses the request-type restriction, changes total attempts into additional retries, omits the separate recovery path and drops the unresolved timeout condition and consultation requirement.
The prepared companion lets you inspect that failure rather than merely read about it. Choose a task and an authored view, compare a deliberately flawed compression, recover the source, inspect the five authored obligations and record a local correction. You can export an envelope containing the view, checks and annotations.
The source stays available. A reader annotation stays distinct from an authoritative change to the policy. The negative control makes the preservation problem visible without requiring an account or a hosted model call.
This is a prepared demonstration. Its representations and obligations are authored fixtures. Their coverage checks do not independently establish semantic fidelity, and the demonstration has not measured reader benefit. It is a working instrument for inspection, with explicit limits on what its verdict means.
Read the preservation chapter · Open the prepared companion · Inspect Reader code
Continue across participants: negotiate and transfer
The Workbench starts from a human expression and preserves it in a journal. An interpreter proposes structured changes. A reviewer can challenge the interpretation. A person decides whether to accept a satisfactory proposal or supply a correction. Accepted state can then be packaged for a fresh recipient that has not received the original conversation.
The publication-boundary walkthrough makes the separation tangible:
| Event | What should change | What it does not supply |
|---|---|---|
| Ask to prepare the book for publication | Record the expression and a proposed interpretation | Permission to publish or push |
| Accept a satisfactory interpretation | Advance accepted semantic state | An action grant |
| Accept a licensing-dependent hold | Record its scope and unresolved condition | A decision that licensing is resolved |
| Accept a later resolution | Change the named condition and reconsider affected decisions | Separate approval for publication |
| Transfer the revised state | Give a fresh recipient an explicit, bounded record | Proof that the recipient understood it |
| Request an application action | Evaluate the current rules and exact grant | A completed external effect |
Application actions in these walkthroughs are simulated. The Workbench does not publish the book, push a repository or adjudicate licensing. Its deterministic rules cover a bounded contract; arbitrary prose obligations do not become executable safeguards simply because they appear in a record.
The local application supports mock participants and configurable hosted participant roles. Hosted execution is a separate opt-in with configured limits and recorded requests. A model’s proposal, review or readback remains distinct from human acceptance.
Inspect Workbench code and walkthroughs
What the record needs to preserve
The value comes from keeping several objects connected without collapsing them.
| Object | Its job |
|---|---|
| Original expression or source | Preserve what was actually submitted or written, with its identity and version |
| Interpretation | State a fallible reading that can be inspected and revised |
| Evidence and provenance | Connect claims to supporting material and retain its standing |
| Uncertainty | Keep unresolved questions, assumptions and scope limits visible |
| Acceptance and correction | Record who adopted which version and what superseded an earlier reading |
| Rendering | Present material for a task without becoming a replacement source of truth |
| Transfer | Carry selected state and supporting context, with its boundaries visible |
| Grant and execution record | Separate permission, attempted submission and observed result |
A correction should have consequences. If an interpretation depended on an assumption that changed, its dependent uses need reconsideration. Preserving the old record as history is compatible with stopping it from governing the present.
The book gives the solution its scope
The 37 chapters develop four connected problems. Each adds a question the eventual workspace must answer.
| Part | Communication problem | Consequence for the solution |
|---|---|---|
| I — A New Language, Chapters 1–12 | A source can have many task-facing representations | Preserve source access, expose interpretation and check what survives transformation |
| II — Too Much Information, Chapters 13–20 | Generating a view does not decide what deserves attention | Separate eligibility, relevance, selection, resolution and delivery; make coverage limits inspectable |
| III — The Personal Experience, Chapters 21–28 | Adaptation can turn temporary observations into lasting claims about a person | Separate declared, observed and inferred state; scope its use, support correction and retain a path without optional conditioning |
| IV — The Second Reality, Chapters 29–37 | Prediction and proxy communication can have consequences for other people | Separate prediction, identity, speech acts, disclosure and authority; respect recipients and shared channels |
The website’s 37 Language Outlines provide a consistent guide to each chapter’s question, capability, proposed preservation obligations, implementation and limitations. Their obligations remain candidates rather than independently accepted semantic truth. The Capability Index connects the progression.
The outlines are editorial guidance that can accompany an evolving book. They are not 37 separate applications or automatic certificates of preservation.
How the website could become the solution
A website can do more than host the argument. It could become the place where a reader moves from an explanation to an inspectable source, tries a representation, challenges a reading and carries a corrected record into another task.
The existing book and prepared companion provide a modest beginning. A fuller workspace would connect:
- A reading surface: original material, alternative views, source references and accessible fallbacks.
- A meaning workspace: proposed interpretations, open questions, challenges and human decisions.
- An attention workspace: declared interests, candidate evidence, reasons for withholding or surfacing an item, and visible collection limits.
- Scoped personal state: applicable declarations and permitted evidence, with inspection, expiry and correction.
- Participant handoffs: a bounded transfer, a fresh recipient’s response and a way to test a decision that depends on the revision.
- Action boundaries: exact grants and separate records of permission, submission and outcome when an integration can act.
These are proposed product connections, not a description of a completed website. An ordinary reading path remains valuable. Each addition needs to earn its complexity through a real task; the fixed page, a conventional task record or a simpler workflow may be the better result.
Taint belongs to the research horizon here. The book proposes a potentially detectable, co-produced interaction pattern and asks whether a purpose-specific view could improve discovery. It has no demonstrated detector or measured matching benefit. It supplies neither identity nor permission, and the solution does not depend on building it.
What exists today
| Component | Current standing |
|---|---|
| Illustrated 37-chapter book | Argument, research background and explicitly bounded examples; 41 explanatory figures |
| Chapter outlines and Capability Index | Website guidance and navigation; proposed obligations and stated implementation limits |
| Prepared Chapter 11 companion | Static, service-free source/view/correction demonstration |
| Standalone Reader prototype | Local prepared views and deterministic fake pathway; a separately gated hosted adapter has offline readiness |
| Language Workbench | Local conversation, proposal review, acceptance, correction, transfer and simulated-action tooling |
| Hosted Runtime/Workbench observations | Exploratory evidence under their individual protocols, with retained failures and limitations |
| Integrated personal mediation and proxy environment | Proposed direction; bounded reference mechanisms do not establish the complete system |
The static companion, local Workbench and research adapter have different execution and evidence boundaries. Availability of one does not qualify the others.
What the evidence supports
There is engineering evidence that bounded state, source references, corrections and permission checks can be implemented and inspected. Scripted and deterministic demonstrations exercise parts of those mechanisms. Some Runtime and Workbench runs also contain actual hosted model responses.
One useful comparison tested four decisions with DeepSeek V4 Flash under a conventional task-record representation and the Language Runtime representation. Both achieved 4/4 mechanism agreement, with no observed false permissions in those four cases. The result supports bounded feasibility and establishes no representation advantage. A separate HTTP 429 attempt remains a provider failure rather than a scored answer.
Inspect that comparison and its limits.
Those observations do not establish that readers understand more, that an interpretation captures all intended meaning, or that a fresh participant can reliably handle arbitrary revisions. The Reader adapter’s offline qualification work is readiness evidence, not a qualified real-model reader result.
The next valuable tests compare meaningful consequences: can a recipient apply a corrected exception to a new decision, under the same information and revision opportunities as a competent conventional workflow? Does a transformed view improve the reader’s task while retaining its governing qualifications? What errors and burdens does the mechanism introduce?
Successful field repetition or schema validation alone cannot answer those questions.
Applying the design to the book itself
The manuscript presented a useful test. It asked readers to keep difficult distinctions apart, but sometimes introduced several abstractions before grounding them. The task was to make the explanation easier to follow while preserving its claims, qualifications, citations and authorial voice.
That became an editorial workflow with two explicit obligations: improve the explanation and retain the meaning that constrains it. A candidate revision had to be compared with its source, rather than accepted because it sounded fluent.
The executed design
The LANG-SELF-01 pilot gave three models different responsibilities. claude-haiku-5-5 examined conceptual preservation; qwen3.8-flash examined teaching and comprehension gaps; deepseek-v4.1-flash examined prose and flow. A further claude-haiku-5-5 call produced the revision. Local JavaScript scripts called the configured OpenCode Go inference service and saved the responses.
Identified chapter + desired improvement + preservation requirements
|
Preservation / teaching / prose analyses
|
Revision prompt with the source and expert context
|
Candidate text + raw response archive
|
Source comparison, repairs and author review
The subsequent full-book runner supplied at most 800 visible characters per expert to the revision prompt. Several expert calls returned no visible text, and the runner could proceed with incomplete advice. These are material limits on what “three-expert editing” meant in practice.
This was prompt-based collaboration using Language’s preservation principles. The editorial runner did not exchange schema-validated language/0.1 envelopes or invoke the portable runtime’s comparison modules. The independent runtime and Studio adapter are real implementations, but their existence does not make them executed stages of this editing process.
How it helped
Chapter 1 provides a concrete example. Its original introduction said:
More exactly, the book asks what happens to the gap when intelligence enters it:
The expert-guided candidate clarified the referent and explained the term before relying on it:
More precisely, the book asks what happens to that gap when intelligence enters the channel between them. Here “intelligence” covers two things: the human judgement already present in every exchange, and the computational systems that increasingly select, transform or generate messages inside it.
The reason for preferring the change is inspectable: a newcomer receives a definition where the argument needs it. The candidate also retained source details that the direct-editing baseline changed, including “perhaps ten minutes”, the technical word “encode”, and the quoted “keep an eye on him”. An editor can discuss those decisions individually, instead of comparing two overall impressions of fluency.
| Result | What it tells us |
|---|---|
| Pilot report: 12/14 preservation concerns addressed by the guided candidate, compared with 2/14 by direct editing | A useful editorial signal from reported concern-coverage judgements; no blinded independent score |
| Local manuscript: 37 of 38 numbered files changed; Chapter 3 retained its calibration revision | Broad revision coverage; the local book had previously gained a chapter, so this is a different inventory from the website’s older 37-chapter guide |
| Full-book archive: 144 retained responses, including 108 expert responses | Real model execution with inspectable artifacts; 51 expert responses had no visible text |
| Later source audit: incomplete references found in four chapters despite passing heading checks | The audit exposed a failure the completion report had missed |
| Local repairs: original references restored; exact front matter, heading lists, figures and reference lines match the pre-production baseline | Specific preservation objects can be verified; this does not certify every paragraph’s semantics |
The full-book revisions entered Git in 8420d10; 1de1e5b recorded later cleanup, and 5354ce5 recorded the extra reference repairs. Capstone II remains a local draft for author review. No human reader-comprehension gain has been measured. The pilot also gave the guided candidate more context than the direct baseline, so it does not isolate an advantage caused by the Language protocol.
The practical benefit was a reviewable editorial process and concrete revision candidates. Separate expert responsibilities made concerns explicit. Source comparisons made some losses detectable. Retained originals made repair possible. The failure was equally instructive: a References heading can survive while the citations beneath it are cut off. A successful build cannot detect that kind of damage.
Reproduce the evidence before making another model call
The manuscript, reusable capabilities and portable protocol have separate homes:
| Repository | Responsibility in this solution |
|---|---|
language |
Manuscript, candidate revisions, reports, model transcripts and source history |
project-language |
Reusable Language capabilities and Studio; not imported by the editorial runner |
language-runtime |
Portable protocol and its own tests; not executed by the editorial runner |
The historical evidence is under experiments/LANG-SELF-01/: candidates/, transcripts/, fingerprints/ and reports/. The source-preservation audit and candidate-only replay preparation are supplied in the local Capstone II package:
Set-Location C:\Projects\language
git show --stat 8420d10 -- content/books/language
python scripts/capstone_ii_audit.py --output planning/capstone-ii/audit.json
python scripts/capstone_ii_audit.py --prepare-replay C:\Temp\lang-self-replay
node --check C:\Temp\lang-self-replay\process-chapter.mjs
These commands inspect recorded evidence and prepare an isolated candidate-only runner. They do not call a model. The replay directory must not already exist. The audit compares the numbered chapters with baseline c7e7953, reports differences and reads retained response metadata without reading credentials.
After separately authorising a new inference run and supplying OPENCODE_API_KEY securely in the process environment, node C:\Temp\lang-self-replay\process-chapter.mjs 20 generates a new Chapter 20 candidate in the scratch directory. The recorded runner uses 3,000-token expert limits and a 16,000-token revision limit. Model IDs identify the historical configuration; current service availability is not guaranteed. No key belongs in the page, command history or evidence files.
The historical runner overwrote canonical chapters; the prepared replay removes that write. A transport failure, missing expert analysis, token-limit stop or incomplete citation should remain a recorded failure requiring review. Preserve each attempt in a fresh directory, compare it with the source, and keep promotion to the manuscript as a separate author decision.
The retained full-book responses contain a list-cost subtotal of 0.41862931 in provider metadata. This excludes overwritten retries and pilot work and is not an invoice or a complete project cost. It is useful for auditing what was recorded, alongside the failures, rather than claiming the workflow is universally cheap or more effective.
Inspect the pilot report · Inspect the full-book completion record
The next research question is whether typed, complete, source-linked Language exchanges improve on equally resourced ordinary expert collaboration. This case study has not answered it. It has provided a real manuscript, a reproducible artifact trail and specific failures against which a stronger implementation can be tested.
Run the current prototypes
Clone the repository and enter its root:
git clone https://github.com/ernanhughes/language.git
cd language
For the Reader’s prepared local interface:
python experiments/language-capstone/serve.py 8001
For the Workbench’s local interface, using an available port:
python experiments/language-workbench/app.py serve --port 0
Open the loopback address printed by the chosen launcher. These commands do not enable hosted inference. Use mock/prepared controls to inspect the workflow first. The project READMEs describe dependencies, execution modes, evidence export and the separate steps required for hosted participants.
- Reader setup and operating limits
- Workbench setup, Python classes and browser-free walkthroughs
- Book and implementation repository
Where to begin
If your problem is a summary that loses an exception, begin with the Reader and Chapter 11.
If your problem is an interpretation that changes across participants, begin with the Workbench’s publication-boundary scenario.
If your problem is too much information or adaptation that knows too much about you, follow Parts II and III. They set out requirements and bounded reference examples; the full website workspaces remain to be connected.
Language’s ambition is a communication environment that people can inspect, correct and control. Its current tools offer concrete places to examine that ambition, while the book keeps asking whether a smaller mechanism would do the job better.