Custom-function admission is AXIS-only and excludes memory-free PLATE declarations #500

Boundary and owner

Source-only triage owner: Planck. No active custom admission/projection implementation claim was found in the current open PR roster. Previous custom persistence #230/#233 and canonical lookup #379/#409 are implemented; this is a distinct scope-admission gap.

Root394 owns current callable_contract.py and compiled_plate_execution.py work. Those shared files remain protected; this issue does not authorize competing changes there. PR494 and its source-bearing Points custody remain unchanged.

What is established

Pinned current main72ae6bf2dd3ddc990c282eb2be200dab717cbd05 and frozen ordinary engineering490-main target have byte-identical determining sources: custom_functions/{manager,validation,runtime_registry}.py, callable_contract.py, funcstep_contract_validator.py and compiled_plate_execution.py.

CustomFunctionManager._prepare_source (around499-524) recognizes declarations only when input/output/execution memory metadata is present. validate_function_signature requires image as first parameter; validate_function_attributes requires input and output memory declarations. list_custom_functions also rejects absent input memory.

project_custom_function (runtime_registry.py509+) injects ProcessingContract.FLEXIBLE when absent, before applying the registry wrapper. That would violate the PLATE contract even if the initial admission filters were relaxed alone.

FuncStepContractValidator.validate_plate_callable_contracts (933+) requires the opposite: no axis-local memory/processing declarations, required keyword-only artifact_batch: RuntimeArtifactBatch, and that batch as the sole runtime-bound type.

The existing built-in OpenHCSRegistry._metadata_for_function (645+) already recognizes PLATE scope without memory declarations and avoids adding processing metadata. LibraryRegistry.apply_contract_wrapper (1485+) has the existing PLATE wrapper behavior. Reuse those owners rather than create a second registry, wrapper or alternate decoder.

The public custom-function authoring guide currently instructs users to use a memory decorator. Therefore classify this as an unsupported public custom PLATE route/capability gap, not a claim that a promised successful PLATE registration regressed.

Independent source-only ABI witness (NOT executed)

This intentionally contains no biology, images, paths or statistics:

from openhcs.core.artifacts import ArtifactSpec, SpecialArtifactType
from openhcs.core.callable_contract import FunctionStepExecutionScope
from openhcs.core.pipeline.function_contracts import (
    artifact_outputs, execution_scope, runtime_bound_parameters,
)
from openhcs.core.runtime_stores import RuntimeArtifactBatch

@execution_scope(FunctionStepExecutionScope.PLATE)
@runtime_bound_parameters(RuntimeArtifactBatch)
@artifact_outputs(ArtifactSpec.output("engineering_plate_abi", SpecialArtifactType))
def engineering_plate_abi(*, artifact_batch: RuntimeArtifactBatch):
    return {"engineering_only": True}

This supplies the memory-free PLATE callable ABI and one Special output portion; it is not a complete compiled-plate execution/metadata-owner qualification. Through the declared openhcs_register_custom_function request on a future approved owned endpoint, source analysis predicts custom admission selects zero eligible functions. Adding fake array memory declarations is not a valid repair: it contradicts the PLATE validator.

No such registration, imports, runtime, test, build, install or scientific execution was performed for this triage.

Original uncertain observation stays uncertain

The triggering retained request used explicit localhost/TCP6012, native PID1155281/create_time1790986691.33 and its exact admitted custom storage, persistent=true/persist=true. Original journal returned custom_function_registration_uncertain, not a definitive contract rejection. No replay or scientist hint was sent.

Ledger/source observation says later lookup did not find that declaration, but that does not retroactively prove that the source-bearing request had no side effects. The source contradiction above is independent determining evidence, not a proven explanation of the transport/observation failure.

Technical determining journal: next-h004-preparation-20261002/successor490-main/BBBC013/author-workspace/output/runtime/mcp.stdin line158 and mcp.stdout39686-39718 under /home/ts/wt/openhcs-issue-batch-20260929. Do not copy scientific source or inspect pixels/measurement tables to qualify this issue.

Separate unsupported declaration, not bundled into the repair

The attempted reducer declared two MeasurementsArtifactType outputs. Current compiled_plate_execution._validate_plate_invocation requires exactly one SpecialArtifactType output, and CallableContract canonical PLATE return matching selects the first output. That restriction is also present at Root394 head2d3d75e. It is an execution-contract limit, not an admission filter to weaken.

Fixing custom PLATE admission alone must not claim the original two-table reducer becomes supported. Any generic typed multi-output PLATE extension needs its own full declaration/return/storage/materialization/metadata-owner migration coordinated with the shared owner.

Complete acceptance family

• One scope-owned admission/validation contract consumed by source preparation, register/update/reload, runtime projection, discovery, persisted listing and its UI consumer; existing source namespace and lifetime remain canonical.
• Preserve genuine PLATE memory absence; retain AXIS memory/type and source-declaration rejection controls.
• No injected FLEXIBLE processing declaration on a memory-free PLATE function; reuse existing registry/wrapper behavior.
• Verify stable custom identity, lifecycle/collision, fresh source reload and listing without pretending None is an array backend.
• After full source/AST owner-consumer review and explicit implementation release, execute a tiny original public registration/discovery/compile/execution journey in an approved terminal slot, with exact persistent bytes and original uncertainty receipts retained.
• No guard removal, fake image/memory parameters, alternate runner/registry/codec, foreign source edits or hot-installed fleet changes.

Current disposition: source-only defect/capability receipt. No production implementation, AST refactor proof or installed acceptance is claimed. A draft implementation checkpoint follows source-change/complete-family ownership release; current authorization explicitly prohibits source edits.