Skip to content

Design and Architecture

Bifrost provides interactive program analysis to editors, coding agents, automation, and embedded tools. Every result records its source evidence, proof status, analysis scope, and completeness. A missing result supports an absence claim only when the relevant analysis completed inside a stated boundary.

The design chapters describe how Bifrost is built and where its current contracts end. Entries marked Direction or Research identify unshipped work. The linked product docs cover API details.

Requests pass through one protocol-neutral runtime into structural, usage, and flow analysis. Durable facts are persisted, while expensive semantic graphs are materialized under explicit bounds.

ChapterCentral question
System ArchitectureHow do clients, runtimes, analyzers, and stores fit together?
Identity and Language Front EndsHow does Bifrost turn incomplete multi-language source into resolvable identities?
Storage and Cache StrategyWhat is persisted, reused, invalidated, and recomputed?
Usage Analysis EngineHow are definitions, references, calls, and receiver-sensitive candidates connected?
Dataflow EngineHow do the bounded IFDS-family and IDE-style kernels power value flow, taint, and typestate?
Semantic Models and SummariesHow does external behavior participate while retaining its own provenance?
Evidence and Result ContractWhen may a client claim that something is present, absent, or unresolved?
Decisions and OutlookWhich choices are settled, which are current directions, and what remains open?
Related WorkWhich adjacent systems influenced the design, and where is Bifrost’s emphasis different?

Source-derived structural facts are durable. Semantic artifacts and graph projections are validity-keyed, and interprocedural analysis materializes only the region a request needs. Protocol adapters reuse the runtime’s analysis semantics.

See Representation lifetimes for the full table and Analysis storage layers for the persistence and reuse rules.

Status labels distinguish shipped behavior from planned and open work:

  • Current describes behavior present in the repository version documented by this site.
  • Direction describes an intended design still under implementation.
  • Research describes a question whose contract or engineering trade-off is still being evaluated.

The Decisions and Outlook chapter collects all Direction and Research entries. Each states its readiness conditions; roadmap labels carry no release dates.

For user-visible behavior, start with Capabilities and Code Querying. Use Agent Result Safety to interpret a particular response, and Evidence and Evaluation Methodology to see what public tests and benchmarks establish.