Repository navigation
Bind prepared native requests to qualified backend accounting and scheduler permits before serving #173
Description
Scope
Priority: P1 integration gate; bounded child of #150, not a new umbrella or a claim of an existing serving exploit. Connect the artifact-bound native request path to the existing placement/scheduler authority without converting logical CPU reports or caller-supplied JSON into physical execution permission.
The #167 completion record already names backend-specific qualified resource accounting and admission composition as the next contract. This issue makes that contract independently implementable and testable from the current code at bb1e7468c3397d2c74ec27f5798d69bb9df3bd81.
Evidence and current boundary
crates/text/src/lib.rs:218-291defines an opaquePreparedGenerationwith immutable rendered prompt/token IDs, a request-specific execution plan and a consuminggenerate. Its documentation explicitly excludes prompt/template/tokenizer storage, process RSS, GPU memory and physical reservations from the decoder report. This is a sound CPU preparation boundary, not yet service admission.crates/placement/src/lib.rs:1-5,20-35,75-86intentionally consumes declared capacity and suppliedMemoryEstimateinputs. It neither probes hardware nor reserves memory.crates/sched/src/lib.rs:426-475binds a controller and admission preparation toPlanRequest/placement accounting.begin_use/finish_useissue and track controller-local permits. No native decoder/service adapter currently consumes those permits to authorize execution of the corresponding prepared request.sched::RuntimeCommandKindis explicitly non-authoritative data, and the executor is documented as future work. Completion validation cannot by itself prevent a stale physical command from being executed before acknowledgement.- Native Qwen3 embedding/reranking requirement reports likewise describe logical CPU payload bounds, not qualified host/device reservations.
Why this matters
The important missing connection is not another planner. It is a derivation and authorization boundary between already-owned facts: verified bytes, model structure, prepared request, qualified backend requirements, externally granted resources, placement lease, resident allocation and actual execution.
Without that connection, a future server could accept a correct native preparation and a separately correct scheduler ticket that refer to different artifacts, contexts, devices or budgets. It could also reserve one workspace estimate while allowing several concurrent uses, or release accounting before an asynchronous physical allocation is actually reclaimed.
These are design risks to rule out before integration, not behaviors demonstrated against a running server.
Required contract
- Derive backend-specific requirements from the same artifact/model/request owners that will execute the work. Do not add a parallel model-size table or infer memory from a filename/parameter count.
- Bind qualification evidence to exact artifact/tokenizer/template identities, execution policy, backend/toolchain and device capability; keep quality evidence, logical accounting and measured physical overhead distinct.
- Convert trusted requirements plus the current host grant into admission through existing placement/scheduler owners. Untrusted request hints and serialized reports cannot mint qualified requirements or increase the grant.
- In the service execution adapter, require a matching live admission/use capability for the exact prepared request and resident allocation. Revalidate at dispatch; a matching completion after an unauthorized start is not sufficient.
- Account shared residency separately from per-use KV/recurrent state, transaction copies, workspace and retained results. Admit concurrent uses only when their simultaneous peak is accounted.
- Preserve explicitly standalone CPU qualification APIs as such. Do not force all low-level mathematical references through a server scheduler merely to create an appearance of integration.
Done when
A GPU-denied deterministic fake-executor suite proves:
- A prepared request cannot be substituted with another artifact, tokenizer, context, output cap, profile, backend or resident allocation after admission.
- Serialized copies, fabricated estimates, foreign controllers and stale grant generations cannot authorize service execution.
- Revocation between prepare/commit/load/dispatch refuses new work without partial allocation or unaccounted residency.
- Concurrent-use accounting includes per-use peaks; finishing one use cannot free another's retained resources.
- Load failure, cancellation and failed eviction retain or release accounting only according to explicit physical acknowledgement.
- Pure planning stays action-free, and existing v1 supplied-estimate planning remains truthfully distinct from qualified runtime authority.
Physical capacity, numerical quality and performance remain separately reserved qualification work. No incumbent displacement, host-mode change, provider retargeting, GPU probe or model workload is authorized by this issue.
Ownership
Use the existing loader/model/native-request owners, placement, sched and the eventual service adapter. Aletheia owns workload/session intent and privacy; host lifecycle remains outside Logismos. #46 owns GDN GPU execution, #47 deferred KV compression, and #168 the local denied bootstrap. Do not implement a second host-mode controller or a general orchestration framework.
Activity
feat(sched): retire admissions without revoking peer workloads (#179)
forkwright commentedon Sep 9, 2026
Fresh source/architecture check at main
022436fa0024ba09a4d3e7e2afc8c5a931b4b16cconfirms why a thin prepared-request/permit wrapper would not close this issue:Loadedagainst that lease. A CPU-first service remains a valid future topology, but needs its own honest host-resource/grant and qualified requirement owners; full GPU allocation ownership is not inherently prerequisite.PreparedGenerationalready binds the request, while its pipeline/weights borrowVerifiedArtifact. A resident adapter must own the actual immutable backing or establish an explicit safe scoped owner whose memory is correctly charged. Relabelling the borrow as residency supplies neither ownership nor eviction proof.Generationretains text and token-ID allocations after computation. Execution completion alone must not release their charge while a returned result is still alive. LikewiseEvictedfollows actual release, not the desire to retire.The next coherent package therefore owns backend-specific requirements, actual resident lifetime/registry, a private request/ticket/resident binding, final dispatch validation, and retained-result ownership under the real host-grant contract. Keep v1 supplied-estimate planning and standalone CPU qualification APIs distinct. A key falsifier is equal-shape/equal-total request B substituted for resident A with a different artifact/tokenizer/profile: refuse before session allocation, consume no use capacity, then allow a valid A request. Also hold a completed response during retirement and prove its allocation charge does not disappear.
These are integration requirements, not a demonstrated live-server exploit or an external blocker merely because implementation is larger. No CPU/GPU/model/service action or schema change was performed by this check.
feat(cache): integrate execution-private paged KV (#183)
feat(kernels): integrate checked paged decode attention (#184)
feat: execute native gfx1100 hybrid main models (#187)
feat: refuse invalid native arithmetic before publication (#188)
forkwright commentedon Sep 9, 2026
Merged #188 advances the actual native executor prerequisite: one session-owned numerical status, owner-derived requested bytes, and post-sync numerical validation before any state/result publication. Exact source and hosted proof.
This issue remains open for the complete private executor: persistent shared weights/residency, independent per-use state, dispatch-bound grants, retained-result accounting and truthful release. A one-request load/generate/evict adapter would not satisfy those requirements; requested allocation extents are not qualified host/device overhead. Missing private integration is implementation work, not an authority blocker. Physical execution, host resource grants and external consumer contracts retain their separate boundaries.
feat: bind shared native residency and prepared request ownership (#189)
forkwright commentedon Sep 9, 2026
Shared-residency and requested-accounting foundation #189 merged as
e9a72383809a4006e564030fdae2207da64b6024; merged tree verified identical to the checked candidate. Exact hosted proof and source-review scope.Implemented: shared immutable artifact/model ownership; independently planned native per-use state; owned prepared text profile and common driver loop; native resident/per-use/retained-result requested-byte accounting in the existing ledger; separate host-result envelope; shared bounded custody and conservative quarantine.
This issue remains open. Active next work: explicit mixed-buffer/stream teardown with no implicit release acknowledgement, custody on partial construction (including per-token allocation), then the hermeneus private adapter binding actual resident/request/result owners and current backend/grant/profile at dispatch. Requested bytes are not authenticated grants or qualified allocator overhead. No live serving, GPU execution, model-payload qualification, provider cutover or completed #175 wire contract is claimed.
feat: preserve native and generated-output resource custody (#190)
forkwright commentedon Sep 9, 2026
PR #190 is merged with identical checked/merged tree; the final proof receipt records the native construction/teardown and complete bounded-decoder implementation, 764 workspace +147 release-kernel tests, hosted boundary/object/security results and independent review closure.
Next owner-binding prerequisites are now being implemented together: an additive recycled-logits text port that preserves the existing Vec-returning API without a second legacy row/copy, and scheduler-native host charges for resident backing, mutable execution scratch and retained results competing under one supplied host envelope. These remain requested accounting, not authenticated capacity. Actual native per-use/output teardown and non-Clone result ownership are the subsequent consumer, not another generation loop.
Read-only producer check reconfirmed the current gap: Arche-rendered Tropos exposes host-mode/service/readiness/declared-VRAM lifecycle facts, not the planned proposal-bound current inference-grant/verifier API. No native service is admitted from that observation, a caller PlanRequest/JSON, or Kanon/forge development admission. The separately owned host producer gates serving/admission, not safe source implementation and synthetic custody proofs. No host-mode, service, GPU or provider operations are authorized by this batch.
feat: bind native host accounting and recycled logits ownership (#191)
forkwright commentedon Sep 9, 2026
Planning reconciliation before the next #173 package found an unresolved boundary: the corpus-wide product floor requires useful standalone adoption without running the other main fleet applications, while Logismos's current vision makes every execution depend on a matching Tropos grant. The typed Tropos issuer itself is still absent in registered source. No implementation in #190/#191/#192 supplies or authenticates that grant. Proposed direction for operator alignment: one typed host-authorization contract, with a fleet Tropos provider and a supported standalone shape sharing canonical mechanisms, not a consumer-local copied engine or caller estimates promoted into permission. This is a decision question, not accepted protocol scope or authorization to deploy/change host modes. Complete the owned qualified-native custody package, then pause before defining or implementing the host-authorization expansion.