products
Phosphor
A semantic programming and execution platform that understands source, builds evidence-backed execution variants, and binds each workload to the right runtime, memory, hardware, and topology without surrendering the observable behavior of the original program.
Regulatory condition
Subject to export-control and licensing review.
Phosphor treats a program as more than instructions waiting to run. It resolves the explicit and implicit behavior of language constructs, library calls, effects, object lifetimes, concurrency, and failure paths into a versioned graph. That graph becomes the shared substrate for editing, compilation, verification, profiling, debugging, memory planning, distributed execution, and adaptation. The system may preserve a sequential region, specialize it behind guards, introduce concurrency, retain a language runtime, emit native or accelerator variants, move computation toward state, or decline a transformation entirely. Each decision carries its evidence, constraints, fallback, and revision identity. Unknown behavior remains unknown instead of being converted into unsafe confidence. Phosphor is delivered through eight connected product suites: Toolchain, Verify, Observe, Debug, Memory, Runtime, Adapt, and Studio. They are independently useful surfaces and parts of one feedback system. Compatibility inputs—including Ray-shaped workloads—translate into this richer model rather than bypassing it.
Phosphor
subtitle: A semantic programming and execution platform that understands source, builds evidence-backed execution variants, and binds each workload to the right runtime, memory, hardware, and topology without surrendering the observable behavior of the original program.
data View: phosphor
Language Semantics Fabric
desc: Executable, versioned language and ecosystem knowledge describes hidden operations, effects, faults, legal transformations, observation bindings, and fallback behavior.
Evidence Lattice
desc: Compiler proofs, guarded runtime facts, deterministic traces, samples, fuzz observations, target calibration, and production evidence remain distinct and carry scope, confidence, and validity.
Variant Laboratory
desc: Baseline, native CPU, SIMD, accelerator, distributed, instrumented, and fallback artifacts can coexist and compete under differential verification.
Physical Execution
desc: Placement accounts for state, NUMA, caches, memory tiers, CXL, PCIe, accelerators, storage, network paths, failure domains, and admitted policy.
First Language Personalities
value: 5
Connected Product Suites
value: 8
Tool Coverage Levels
value: 6
Versioned Program Graph
value: 1
Programs Become Evidence-Bearing Systems
Phosphor treats a program as more than instructions waiting to run. It resolves the explicit and implicit behavior of language constructs, library calls, effects, object lifetimes, concurrency, and failure paths into a versioned graph. That graph becomes the shared substrate for editing, compilation, verification, profiling, debugging, memory planning, distributed execution, and adaptation. The system may preserve a sequential region, specialize it behind guards, introduce concurrency, retain a language runtime, emit native or accelerator variants, move computation toward state, or decline a transformation entirely. Each decision carries its evidence, constraints, fallback, and revision identity. Unknown behavior remains unknown instead of being converted into unsafe confidence. Phosphor is delivered through eight connected product suites: Toolchain, Verify, Observe, Debug, Memory, Runtime, Adapt, and Studio. They are independently useful surfaces and parts of one feedback system. Compatibility inputs—including Ray-shaped workloads—translate into this richer model rather than bypassing it.
data Viz
data View
source: core-products/phosphor
section: product-thesis
One Program, Several Valid Forms
Phosphor does not equate optimization with parallelism. A region can remain sequential, be reordered, run speculatively, become asynchronous, use threads or processes, move to an accelerator, execute near its state, or stay inside the reference runtime. The selected form must improve the real workload after task creation, synchronization, serialization, transfer, contention, warming, and rollback risk are counted. Every optimized form retains a route back to behavior that is already known to be correct. A failed guard invalidates its variant; it does not rewrite the meaning of the source.
data Viz
data View
section: execution-forms
The Complete Feedback System
Developer tools, experiment systems, runtime sensors, and infrastructure controllers operate on stable identities. Their outputs become evidence that can change a build or plan only through an explicit verification path.
data Viz
data View
section: feedback-system
Understand
Lexers, parsers, resolvers, type systems, indexers, alias and ownership analysis, effect analysis, and ecosystem packs expand source into explicit and implicit operational paths.
Explore
Grammar, type, workload, schedule, state-machine, fault, topology, ABI, and differential fuzzers search unobserved or high-risk regions. Reducers preserve the smallest useful case in the workload corpus.
Measure
Profiles, traces, semantic logs, metrics, coverage, hardware counters, heap and GC evidence, network and storage measurements, and flight recordings map back to the exact source, artifact, and plan revision.
Verify
Conformance tests, sanitizers, race and progress detectors, symbolic checks, differential execution, replay, shadow traffic, and canaries decide whether a candidate is safe enough for its intended scope.
Adapt
Only admitted changes alter concurrency, warming, placement, resource envelopes, state movement, graph boundaries, or artifact selection. Promotion and rollback remain revisioned operations.
Language Personalities, Not Language Silos
Rust, Java/JVM, ECMAScript and TypeScript, Python, and Go are the first complete language personalities. Each one uses its authoritative compiler, runtime, debugger, profiler, package, and ecosystem surfaces where they exist. Phosphor normalizes their facts; it does not pretend Tree-sitter output is a substitute for a borrow checker, JVM memory model, CPython object model, V8 runtime, or Go scheduler. C and C++ boundaries receive native ABI, symbol, sanitizer, profiler, debugger, and FFI treatment from the beginning even though they are not in the first five complete source-language personalities.
data Viz
data View
section: language-personalities
Builds Are Programs Too
Phosphor models the outer build graph, compiler query graph, and artifact graph separately. It cooperates through supported APIs, wrappers, plugins, structured output, and cache protocols before falling back to opaque process observation. Cargo, Go, JVM, JavaScript, and Python build ecosystems retain their own semantic authority. The Build Companion reduces duplicated work, critical-path length, data movement, oversubscription, cold toolchains, and invalid cache reuse while preserving hermeticity classifications and reproducible provenance.
data Viz
data View
section: compilation-fabric
Runtime Meets the Physical Machine
The machine graph includes cores, cache hierarchy, NUMA domains, memory bandwidth, DDR and HBM, CXL pools, PCIe topology, accelerators, NICs, storage, network paths, thermal behavior, and failure boundaries. The execution graph is embedded into that graph under policy, locality, cost, and evidence. Linux is the primary deployment environment for the deepest topology and device-control surfaces. Development hosts remain broader. Kubernetes and Docker are supported as execution personalities with explicit ownership of scheduling, cgroups, storage, networking, state, and failure behavior.
data Viz
data View
section: physical-execution
Compatibility Without Capability Loss
Ray and Anyscale compatibility is a migration surface, not an execution ceiling. Tasks, actors, object references, placement groups, Serve deployments, data and training graphs, jobs, and runtime environments translate into Phosphor identities, effects, evidence, variants, and physical plans. Where the input representation lacks facts, Phosphor may infer, observe, guard, request metadata, or remain conservative. A capability-loss report makes imperfect translation explicit. Compatibility never authorizes invented certainty or disables Phosphor's verification and adaptation machinery.
data Viz
data View
section: compatibility
Eight Surfaces, One Evidence Chain
Each suite is a real customer-facing product surface and an internal plane. The value comes from their shared identities and evidence, not from placing eight unrelated tools under one license.
data Viz
data View
section: product-suites
Toolchain
Language intelligence, live diagnostics, refactoring, compilation, build cooperation, artifact synthesis, and reproducibility.
Verify
Tests, fuzzing, coverage, sanitizers, race and progress analysis, differential execution, conformance, policy, and assurance evidence.
Observe
Profiles, traces, semantic logs, metrics, flight recordings, workload regimes, hardware evidence, and target calibration.
Debug
Cross-language debugging, logical async stacks, failure analysis, deterministic record and replay, graph-level diagnosis, and regression extraction.
Memory
Ownership and object semantics, allocation, heaps, garbage collection, serialization, locality, tiers, movement, retention, and pressure response.
Runtime
Tasks, actors, processes, state, routing, scheduling, distribution, execution capsules, reference fallbacks, and recovery.
Adapt
Cost and risk models, candidate plans, canaries, guarded promotion, rollback, warming, scaling, placement, migration, and continuous refinement.
Studio
Code, execution, hardware, state, performance, deployments, evidence gaps, physical plans, what-if analysis, and explanations tied to the current revision.
Correctness Contract
- Observable semantics
- Source-language and ecosystem behavior remains authoritative.
- Proven regions
- Transform directly only when the governing semantics establish legality.
- Guarded regions
- Specialize while explicit validity conditions remain true.
- Speculative regions
- Validate, retire, roll back, or deoptimize before effects escape.
- Effect barriers
- Ordering, retry ownership, transactionality, reversibility, and external authority remain explicit.
- Opaque regions
- Execute through the reference implementation instead of fabricating meaning.
- density
- operator
- surface
- product-page
- section
- correctness-contract
Execution Capsule
- Fallback
- Guest or reference-runtime artifact preserving known behavior.
- Variants
- Generic and ISA-specific CPU, SIMD, accelerator, WASM, distributed, and instrumented forms where valid.
- Guards
- Validity, deoptimization, capability, and selection rules.
- Mappings
- Source, semantic graph, artifact, native address, profile site, and plan identities.
- Physical plan
- Default placement, memory, warming, routing, and recovery intent within an admitted envelope.
- Evidence
- Provenance, coverage, verification, calibration, SBOM, attestation, and replay material.
- density
- operator
- surface
- product-page
- section
- execution-capsule
Operating Questions
data View: phosphor
Section 1
Does Phosphor automatically parallelize every program?
No. Parallel execution is one candidate among sequential, asynchronous, threaded, process, actor, accelerator, distributed, and reference-runtime forms. Phosphor selects only forms whose measured benefit and correctness contract justify their overhead and risk.
Section 2
Does compatibility reduce Phosphor to Ray semantics?
No. Ray-shaped APIs and artifacts are translated into Phosphor's semantic, effect, evidence, memory, placement, verification, and execution model. Untranslatable behavior is reported instead of silently discarded.
Section 3
Does Phosphor replace language compilers and runtimes?
Phosphor integrates authoritative compiler and runtime facts wherever they exist, emits additional variants where justified, and retains reference fallbacks. It does not reimplement mature semantic authorities merely to own their code paths.
Section 4
Can Phosphor operate in disconnected environments?
Disconnected and air-gapped operation are explicit required product contracts. Licensing, policy, evidence retention, updates, revocation, clock trust, and control-plane independence require dedicated profiles and cannot depend on a permanent Internet connection.
tech specs
Specifications
- source status
- product-design discussion
- deployment posture
- Linux-first deployment; broad development-host support; local, cluster, container, Kubernetes, managed, edge, disconnected, and air-gapped shapes remain explicit product contracts rather than one universal runtime promise.
- source status
- product-design discussion
- deployment posture
- Linux-first deployment; broad development-host support; local, cluster, container, Kubernetes, managed, edge, disconnected, and air-gapped shapes remain explicit product contracts rather than one universal runtime promise.