---
id: LSN-0061
ticket: multi-frontend-pvm-neutrality
title: PBX is the language-neutral runtime boundary
created: 2026-09-18
tags: [vm-arch, runtime, pvm, pbx, compiler, multi-frontend]
---

# PBX is the language-neutral runtime boundary

## Original Problem

PBS was the first implemented frontend, so its name still appeared in a few
common compiler specification titles. That editorial residue made it easier to
misread the architecture as if PBS owned bytecode, IRVM, or the PVM execution
model.

The implementation was already mostly neutral: the compiler emitted PBX, the
runtime loaded PBX, and the common backend did not import PBS frontend packages.
The real risk was future drift. In particular, IRVM could be mistaken for a
runtime input, `PBS\0` could be confused with the executable magic, and duplicated
VM-architecture documents could silently become competing authorities.

## Consolidated Decision

The executable pipeline is:

```text
language frontend -> IRBackend -> IRVM -> PBX -> loader/verifier -> PVM
```

`IRBackend`, `IRVM`, optimization, and PBX emission are compiler-owned.
`IRVM` is an internal compiler representation and never crosses the runtime
boundary. PBX is the only executable artifact consumed by the runtime.

The runtime repository owns PBX binary layout, Core ISA, loader behavior,
verification, and PVM execution. Studio owns the common compiler transformations
that produce conforming PBX. Studio copies of VM-architecture documents are
mirrors, not independent authorities.

`PBS` names a language, frontend, stdlib, and explicitly language-specific
integration. It does not name the executable format, magic, ISA, ABI, program
image, or runtime type. The canonical persisted artifact is `program.pbx`, and
its binary magic is `PBX\0`.

## Final Implementation

The common compiler specifications now identify bytecode/PBX and IRVM
optimization as language-neutral surfaces. They explicitly state that IRVM is
internal to the compiler and that PBX is the compiler/runtime boundary. Existing
PBS references were retained where they describe legitimate frontend-specific
publication or metadata behavior.

Studio's copies of `ARCHITECTURE.md`, `ISA_CORE.md`, and `INTRINSICS.csv` were
synchronized with the runtime repository. A mirror policy now identifies the
runtime repository as canonical and provides byte-for-byte comparison commands.

Existing Studio tests already proved two important invariants:

- `BytecodeModule` serializes the exact `PBX\0` header;
- common backend contracts neither import nor publicly expose PBS frontend
  types.

Runtime conformance was strengthened in three focused places:

- the bytecode invalid-magic regression now explicitly proves that legacy
  `PBS\0` is rejected;
- the PVM initialization regression now creates a `BytecodeModule` directly,
  serializes it, loads and verifies it, prepares the boot call, and executes it
  through `HALT` without any frontend;
- a quality check inspects the `prometeu-bytecode` and `prometeu-vm` manifests
  and rejects dependencies whose identities belong to compiler or frontend
  layers.

No production VM behavior, ISA, ABI, or binary format changed.

## Examples

Language-specific work stops before the common backend:

```text
PBS AST and semantic model
  -> PBS lowering
  -> neutral IRBackend data
  -> common IRVM lowering and optimization
  -> PBX\0
```

A future frontend follows the same boundary:

```text
FutureLanguage AST and semantic model
  -> FutureLanguage lowering
  -> neutral IRBackend data
  -> the same common IRVM and PBX stages
```

The runtime sees the same PBX contract in both cases. It does not receive a
`languageId`, source extension, AST object, IRVM object, or frontend service.

## Pitfalls and Anti-Patterns

- Do not expose IRVM as a convenient runtime protocol. It is optimized for
  compiler transformations, not binary compatibility or runtime loading.
- Do not rename PBX concepts after the first frontend. `PBS\0` is invalid even
  when PBS produced the program.
- Do not globally ban the word `PBS` from runtime documentation. PBS is a valid
  guest-language example; guards should inspect dependencies, public types, and
  format identities instead of raw text.
- Do not duplicate tests when an existing guard proves the entire invariant.
  Extend coverage only for the missing distinction, such as explicit `PBS\0`
  rejection.
- Do not let a documentation mirror become a second authority. Synchronize it
  against runtime or replace it with an explicit reference.
- Loading a PBX image is not the same as beginning execution. The PVM boot test
  must prepare the published boot call before running the instruction budget.

## References

- `docs/specs/compiler/15. Bytecode and PBX Mapping Specification.md`
- `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md`
- `docs/specs/compiler/21. IRVM Optimization Pipeline Specification.md`
- `docs/vm-arch/README.md`
- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/bytecode/BytecodeModule.java`
- `prometeu-compiler/prometeu-build-pipeline/src/test/java/p/studio/compiler/specs/CommonBackendArchitectureTest.java`
- Runtime: `crates/console/prometeu-bytecode/src/model.rs`
- Runtime: `crates/console/prometeu-vm/src/virtual_machine.rs`
- Runtime: `crates/dev/prometeu-quality-checks/tests/pvm_frontend_neutrality.rs`

## Takeaways

- PBX is the stable, language-neutral executable boundary.
- IRVM stays private to the compiler pipeline.
- Runtime authority and compiler authority are complementary, not competing.
- Small dependency and artifact tests are enough to protect this boundary
  without introducing a plugin platform or a second language.