Skip to content

symfonic.capabilities.prompting.compiler

compiler

The prompt/context compiler: one entry point, one total sequence.

The sequence is fixed — accept, validate, admit, resolve, gate, order, budget, region, freeze — and there is exactly one implementation of it. A second pipeline would be the forbidden thing, however reasonable its motivation looked: the moment domain instructions, standing blocks, or hydrated memory each get their own assembler, ordering and cache decisions stop being decidable from one place, and the region boundary is where that failure shows up as a cache that never hits.

S01 (TA8.51) gave that sequence a second door, not a second pipeline. :func:compile_prompt calls its sources and :func:compile_prompt_async awaits them; every other step -- _prepare before the read and _finish after it -- is the same function called with the same arguments from both, so no ordering, gating, budget or region decision exists twice. The distinction is the one thing to check when editing this module: a step that moves into either door rather than into the shared pair is the second pipeline arriving.

Domain instructions are therefore not special-cased. They compile into the pinned, platform-tier L0 contribution kernel.instructions and travel the same eight steps as everything else, which is what makes "the system prompt is in the cached prefix" a property of the pipeline rather than a coincidence.

compile_prompt 

compile_prompt(request: PromptCompileRequest) -> CompiledPrompt

Compile one prompt from one request. Reads sources; performs nothing else.

The synchronous door onto the one sequence. A contribution whose source only offers aread is refused here by name (see :func:~.sources.resolve_source) rather than dropped.

Source code in src/symfonic/capabilities/prompting/compiler.py 
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
def compile_prompt(request: PromptCompileRequest) -> CompiledPrompt:
    """Compile one prompt from one request. Reads sources; performs nothing else.

    The synchronous door onto the one sequence. A contribution whose source
    only offers ``aread`` is refused here by name (see
    :func:`~.sources.resolve_source`) rather than dropped.
    """
    diagnostics: list[PromptDiagnostic] = []
    estimator, admitted = _prepare(request, diagnostics)
    admitted = gated(request, admitted, diagnostics)
    rendered: list[RenderedContribution] = []
    for contribution in admitted:
        resolution = overridden(request, contribution, diagnostics)
        if resolution is None:
            resolution = resolve_source(
                contribution,
                scope_path=request.scope_path,
                turn=request.turn,
                store=request.last_known_good,
            )
        row = _render_row(request, contribution, resolution, estimator, diagnostics)
        if row is not None:
            rendered.append(row)
    return _finish(request, tuple(rendered), diagnostics)

compile_prompt_async async 

compile_prompt_async(request: PromptCompileRequest) -> CompiledPrompt

The same sequence, with step 4 awaited (S01, TA8.51).

This is not the forbidden second pipeline, and the difference is worth stating because the module docstring above forbids one by name. A second pipeline is a second place ordering, gating, budgeting and region planning are decided; those steps are :func:_prepare and :func:_finish here, and both doors call the same two functions with the same arguments. What differs is one line: whether the source read is called or awaited. A contribution's position in the prompt cannot depend on which door compiled it, because neither door decides positions.

The alternative -- asyncio.run or a thread hop inside a synchronous read -- was refused for the reason S01 states: it would block the loop every turn, trading a missing port for a latency defect.

Source code in src/symfonic/capabilities/prompting/compiler.py 
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
async def compile_prompt_async(request: PromptCompileRequest) -> CompiledPrompt:
    """The same sequence, with step 4 awaited (S01, TA8.51).

    **This is not the forbidden second pipeline**, and the difference is worth
    stating because the module docstring above forbids one by name. A second
    pipeline is a second place ordering, gating, budgeting and region planning
    are decided; those steps are :func:`_prepare` and :func:`_finish` here, and
    both doors call the same two functions with the same arguments. What
    differs is one line: whether the source read is called or awaited. A
    contribution's position in the prompt cannot depend on which door compiled
    it, because neither door decides positions.

    The alternative -- ``asyncio.run`` or a thread hop inside a synchronous
    ``read`` -- was refused for the reason S01 states: it would block the loop
    every turn, trading a missing port for a latency defect.
    """
    diagnostics: list[PromptDiagnostic] = []
    estimator, admitted = _prepare(request, diagnostics)
    admitted = await gated_async(request, admitted, diagnostics)
    rendered: list[RenderedContribution] = []
    for contribution in admitted:
        resolution = overridden(request, contribution, diagnostics)
        if resolution is None:
            resolution = await resolve_source_async(
                contribution,
                scope_path=request.scope_path,
                turn=request.turn,
                store=request.last_known_good,
            )
        row = _render_row(request, contribution, resolution, estimator, diagnostics)
        if row is not None:
            rendered.append(row)
    return _finish(request, tuple(rendered), diagnostics)