Phod Lang

Conventional software development puts implementation in the privileged position. Tickets, prose documentation, comments, tests, and review threads orbit the codebase, but the code is treated as the artifact that finally matters. That works until the actual problem is not syntax, but intent drift: the thing that should have been built is distributed across conversation, memory, review context, and unstated constraints.

Phod inverts the authority chain. The durable artifact is a structured specification. The generated implementation is disposable in the strict sense: if it stops satisfying the specification, it can be discarded and derived again. This makes the developer's primary question sharper: not "does the code look plausible?", but "is the specification complete enough that any accepted artifact has to preserve the intended behavior?"

This is the language-level expression of Citium's broader PSI/SI program. A solution cannot be structurally inevitable when the source problem is scattered. Phod asks whether the source problem can be made machine-readable enough that derivation and verification operate on the same declared structure.

A Phod source unit is organized around three ordered regions: intent, constraints, and derived output. The first two belong to the author. The last belongs to the compiler. That ownership split is the core language move: humans write what must be true; the toolchain writes what can be regenerated.

===INTENT===
name: record_normalizer
purpose: Normalize records while preserving declared invariants.
behavioral_contracts:
  - Accept only records matching the declared shape.
  - Report invalid records without silently repairing them.

===CONSTRAINTS===
target.language: rust
target.runtime: cli
safety.no_network_access: true
verification.required_checks:
  - compile
  - syntax
  - exit_code_zero

===DERIVED===
compiler-managed output

The exact surface is research-active, but the public shape is stable: section order is part of the contract; intent and constraints are explicit; derived output is not treated as sacred. The format is meant to be legible to a human, strict enough for deterministic parsing, and narrow enough that errors can point back to specification defects instead of dissolving into model behavior.

Phod does not assume derivation is trustworthy because it is fluent, local, or generated from a well-written prompt. The trust boundary is verification. A candidate artifact that cannot pass its declared checks is not a successful compile, even when it is syntactically plausible and semantically attractive.

This creates a hard split between deterministic and nondeterministic work. Parsing, normalization, hashing, diagnostics, and verification must be stable. Derivation may involve search, pattern selection, or model-backed generation, but it never gets to define its own success condition.

A specification-first language becomes more interesting when its compile history is not thrown away. Every accepted or rejected derivation can preserve source hash, artifact hash, verification result, target profile, failure detail, and replay context. That record turns compilation into a research substrate.

The long-term question is whether a corpus of verified spec-to-artifact mappings can improve future derivations without weakening the source-of-truth relationship. The corpus should make the toolchain more capable, but it must not become a hidden authority. If prior examples conflict with the current specification, the current specification wins.

Phod is active compiler and toolchain research inside Citium. It is not merely a concept, and it is not a public paper. The appropriate public posture is between those poles: enough implementation proof exists to place the project on the roadmap, while the research is still too active for broad language claims.

The open work is substantive: deeper derivation coverage, stronger runtime verification, corpus and replay truth, reconciliation between evolving format work and frozen public claims, and clearer evidence about where specification-first derivation outperforms ordinary code generation. Those are research gates, not marketing tasks.

• Not a GUI-first authoring product. Editor, REPL, CI, or future visual surfaces are adapters over the language core, not the identity of the project.
• Not a general-purpose replacement claim. Phod does not present itself as a replacement for Rust, Zig, package managers, deployment systems, or operating runtimes.
• Not prompt magic. Natural-language generation is not accepted as authority; the specification and verifier decide.
• Not implicit cloud dependence. Local-first derivation remains the default posture; optional external services cannot become silent requirements.
• Not publication of implementation machinery. Citium can publish the research thesis while keeping compiler internals and working material out of scope.

The next credible public artifact is not a product announcement. It is a technical report: the source format, the trust boundary, the verification model, observed derivation limits, corpus effects, and the cases where the approach fails. A weak report would say "specs generate code." A Citium-grade report has to show when specification reduces ambiguity enough to change the verification problem.

Until that evidence is mature, Phod belongs here: visible on the roadmap as active research, linked to a public explanation of the thesis, and kept out of the paper index.