The Language Should Be Writable

1 day ago

A semantic language is not serious if it only exists as JSON.

JSON is useful as an interchange format. It is good for tools, checkpoints, sidecars, proofs, and snapshots. But humans should not have to write a large object graph by hand to describe software. If the universal layer is meant to become a real substrate, it needs a source form.

It needs to be writable.

That changes the idea.

The system is no longer just:

JavaScript -> semantic record -> TypeScript

It is also:

Frontier source -> semantic record -> TypeScript
Frontier source -> semantic record -> Rust
Frontier source -> semantic record -> SwiftUI
Frontier source -> semantic record -> HTML + CSS + JavaScript

The source language is not a replacement for every target language. It is a way to author the parts of software that are more stable than any one target: state, actions, effects, capabilities, views, invariants, migrations, ownership boundaries, proofs, and projection constraints.

One Authored Contract

Durable source: .frontier fileA human-writable program, not only a generated JSON graph.
Semantic graph: state, actions, effects, views, capabilitiesThe stable meaning that target languages project from.
Target output: TypeScript, Rust, SwiftUI, HTML, CSS, JavaScriptEach target chooses its own idioms while preserving declared meaning.
Projection evidence: source spans, identities, losses, gatesLowering is not trusted unless it can explain what survived.

The important boundary is not JSON. It is the authored contract that can become many concrete programs.

Source Before Projection

Most cross-language systems start from an existing language.

That is useful when the world already contains code. You lift TypeScript, Rust, CSS, HTML, Swift, or Python into a richer semantic record and then decide what can be preserved.

But a source-first system should not require an original host language.

You should be able to write the semantic program directly:

module TodoApp @id("mod_todo") {
  type TodoInput @id("type_todo_input") {
    title: Text
  }
 
  state TodoDb @id("state_todo") {
    todos @id("collection_todos"): Map<TodoId, Todo>
  }
 
  effect PersistTodo @id("effect_persist") {
    capability storage.write
    input TodoInput
    returns Json
    resources TodoDb.todos
  }
 
  action addTodo @id("action_add") {
    input TodoInput
    returns Patch
    reads TodoDb.todos
    writes TodoDb.todos
    uses storage.write
  }
}

That is not a JSON serialization. It is a program.

It names state. It names effects. It declares what an action may read and write. It binds the action to a capability. It gives the compiler and the merge system something stronger than a file path and something more durable than a line number.

Lowering Is A Decision

The target language is where the program becomes executable in a particular environment.

But the target language should not be where meaning is first discovered.

Authored Once, Lowered Many Ways

1state TodoDb @id("state_todo") {2  todos: Map<TodoId, Todo>3}4 5effect PersistTodo @id("effect_persist") {6  capability storage.write7  input TodoInput8  returns Json9  resources TodoDb.todos10}11 12action addTodo @id("action_add") {13  input TodoInput14  reads TodoDb.todos15  writes TodoDb.todos16  uses storage.write17  returns Patch18}

Authored contractThe source file declares identities, permissions, effects, and state boundaries before any target syntax is chosen.

A source-first semantic language can produce target code, but it also produces the evidence that says what the target code still means.

The Source Is Not The Runtime

Frontier source should not become a new universal runtime.

That would make the wrong thing central.

The point is not that every program should execute inside Frontier. The point is that some parts of software are better authored as target-neutral contracts, then lowered into the runtime that makes sense.

For example:

state and cache shape
public actions
effect permissions
workflow steps
view contracts
capability requirements
adapter boundaries
migration rules
test and runtime proof obligations

Those are the pieces that benefit from being authored once and projected many times.

Target-native code still matters. A graphics loop, a performance-sensitive parser, a Rust unsafe boundary, a Swift animation, a CSS layout trick, or a platform SDK call may stay native. The semantic layer should be able to reference those pieces, preserve them, wrap them, and account for what it cannot model.

That is different from pretending all code is the same.

What A Writable Semantic Language Buys

When the universal layer is writable, several capabilities become easier to imagine.

SurfaceClaimRequired proofCurrent evidenceRoute

ProvedIdentityThe same action/state/effect survivedStable ids and source map links.frontier ids, generated target spansAdmit projection

RequiredAuthorityThe output cannot write more than declaredRead/write/effect descriptor checkAction descriptors and capability bindingsGate target

RequiredRuntimeThe target behaves under declared conditionsRuntime probe or adapter proofBrowser probe, native adapter test, traceRun proof

MissingLossMissing target meaning is explicitProjection loss recordUnsupported feature or native escape hatchReview or block

The value is not only code generation. It is that generated code remains tied to the contract it came from.

A UI can be projected into React, SwiftUI, or HTML.

A workflow can be projected into a server process, a queue worker, or a local-first client.

An action can be projected into TypeScript bindings, Rust traits, test fixtures, dashboard controls, or agent tools.

A capability can be projected into an app permission, a runtime adapter, a mock, a policy gate, or an audit record.

The source contract becomes the thing that many environments agree on.

The Compiler Should Fail With Shape

A writable semantic language also changes what failure means.

If a target cannot express something, that should not be hidden inside weak generated code. The compiler should say what failed:

RouteSignalRequiresProduces

EmitTarget can represent the contractSource ids, descriptors, target spansTarget code plus proof

Emit With LossTarget can run but cannot preserve all meaningExplicit loss record and reviewable caveatCode plus loss evidence

Require AdapterMeaning depends on host runtimeDeclared capability bindingAdapter task or runtime proof

Keep NativeTarget-specific code is the right sourceNative source boundary and source mapOpaque but tracked region

BlockThe projection would lieNo compatible target representationFailed lowering with a durable reason

Projection should not be magic. It should route each contract through the safest available target decision.

This is the same philosophy as semantic merge.

Automate where the proof is strong. Refuse where the proof is missing. Turn the refusal into a sharper adapter, fixture, target feature, or source constraint.

The Bigger Picture

If Frontier is only a JSON graph, it is a tool format.

If Frontier is only an importer, it is a compiler backend for existing languages.

If Frontier is writable, it becomes something larger: a semantic source layer for software that wants to move across runtimes.

That does not mean everything should be written in Frontier.

It means the system should let you choose the right source of truth for each part:

write stable contracts in Frontier
write target-native performance code in the target
write layout where the browser is the real runtime
write platform-specific affordances in the platform
bind them together with identities, capabilities, source maps, and proof

That is the practical shape.

The semantic language is not above the target languages because it is more expressive in every local detail. It is above them because it can hold the cross-language contract that each target needs to honor.

And once that contract is writable, the system stops being only a way to understand existing code.

It becomes a way to author software that is already prepared to be projected, merged, adapted, audited, and moved.

SHAPE

SHIFT