Seed-Mediated Generated Interface // the interface begins at the loading path
A system pattern: a seed — a static artifact such as a repo, an assembled packet, or a prompt/prompt-wrapper — supplies enough structured material and behavioral instruction for an AI runtime to render the operative interface in conversation. The interface is generated — caused to happen inside a runtime — not built as application chrome. The static artifact is the seed; the interface is the guided, AI-mediated interaction the seed produces.
The hard case is the user's own opaque runtime — a runtime the author can neither see nor control (see the runtime-context axis below). That is where the doctrine has its bite.
seed (repo / packet / prompt) + delivery wrapper + user loading path
>> an AI runtime renders the interface (the user's own opaque tool is the hard case)
>> the interface is the guided interaction the seed causes to happen
on this page
The path // illustrated
Illustrative — this doctrine is the source of truth, not the diagram. The figure carries the instantiation path and the loading-boundary seam: where the authored seed either remains governing or is demoted before its contract runs. Source: docs/diagrams/method-ASK_seed-mediated-generated-interface.html. The embedded raster is the dark full-page mirror; both themes and a chrome-free diagram-only view remain exportable from the HTML, but are not committed.
Two orthogonal axes: carrier and runtime context
The family is classified on two independent axes. Conflating them creates a category error: it mistakes what the runtime can access for what the user loaded.
Carrier — what the seed is (the primary loading object):
repo-mediated the repo is the primary seed / loading object packet-mediated an assembled packet is the primary seed / loading object prompt-mediated a prompt or prompt-wrapper is the primary seed / loading object
Repo-mediated is one carrier species, not the genus. A prompt or packet may reference a repo, and a runtime may have live repo access, without making the interface repo-mediated by carrier — carrier is what is loaded, not what is merely referenced or reachable. (The doctrine was formerly titled after this species; the genus is seed-mediated.)
Carrier is classified by the primary loading object for the realization. Later host-internal operations performed as part of that object's loading path — such as matching, invocation, or progressive resource loading — are runtime mechanics inside the already-classified realization, not additional carrier-classification events.
Runtime context — what the generated interface runs against, and how opaque it is to the author:
self-contained opaque the runtime has no authorized live access to the author's context;
the author can neither see nor control it >> the HARD case
connected authorized the runtime has authorized live access to the author's repo / context
author-controlled null the author's own runtime >> the NULL case (no opacity, no delivery failure surface)
The two axes are orthogonal — the same carrier can run in any runtime context, and the same runtime context can carry any species. Worked polarity (below): on carrier, PCS and AP-external are opposite; on runtime context they are the same (self-contained opaque), while UO-4TMK is the outlier — the runtime with the most authorized context access, though it is packet-mediated by carrier. Do not let "repo access at runtime" bleed into "repo-mediated delivery."
The hard case is runtime opacity. The author ships behavior and the loading path, but the generated thread is not itself an authority surface. A seed-mediated interface running in a runtime the author does control (the null case) has none of this failure surface — opacity is the condition that gives the doctrine its bite, not the carrier name.
Relation to bounded generativity
Seed-mediated generated interface is bounded generativity delivered into a runtime the author cannot see or control — the bounded-generativity spine (docs/bounded-generativity.md) shipped past the author's observability. There, the brief / grammar grants the aperture, execution fills it, selection closes, and governance binds — and the author can, in principle, observe that the judicial (selection / closure) and governance functions ran as authored. Under runtime opacity that back half of the spine is partially exiled from the author's observability: the runtime is the renderer, and the author cannot directly confirm the generated thread selected, closed, or recorded as specified.
The author compensates two ways: behavior travels with the seed (the process is carried, not left to a standing prompt to infer), and the generated thread is stripped of authorizing force — authorization stays in the repo / packet / governance record, never in the runtime conversation. This is why a generated thread cannot self-authorize is an invariant rather than a caution: the record is produced inside a runtime the author does not control. So the distinction from bounded generativity is not "one more shipping step" — it is the same spine with its judicial + governance tail moved out of the author's line of sight, compensated by seed-carried behavior and a de-authorized thread.
So the seed governs two behaviors at once:
the model's behavior inside the generated interaction >> the aperture (permitted variance)
the user's setup before the interaction can begin >> the loading path (what to paste / open / upload;
the failure mode · the fallback · the return shape)
A grammar cannot govern a realization it never arrives as. Bounded generativity governs the candidate space; seed-mediated generated interface governs the instantiation path. Aperture and operator distance are orthogonal control dials: the aperture meters permitted output variance; operator distance meters the setup-encoding burden the seed must carry. They interact, but neither is the delivery-side version of the other. (These control dials are distinct from the carrier and runtime-context classification axes above — a held question of whether stakes / blast-radius is a further dial is noted under What remains local or held.)
Governed elicitation as an application
A prominent application of seed-mediated generated interface is governed elicitation: a domain expert engages a guided conversation rather than operating the repository, schema, taxonomy, or workflow that will receive the result.
Elicitation names the interaction's purpose, not a carrier species or runtime-context class. A governed elicitation may be prompt-mediated, packet-mediated, or repo-mediated, and may run in any defined runtime context: self-contained opaque, connected authorized, or author-controlled null.
The seed carries the review grammar, source material, behavioral instructions, loading path, and return contract. The grammar grants the aperture. The generated interaction realizes questions, reformulations, corrections, interpretations, and judgment inside it.
A conversational stop and capture return a status-bearing record. They do not themselves select, close, authorize, or absorb the result. Recipient governance preserves any advisory or delegated-binding status already conferred on the expert's contribution and owns classification, validation where required, selection, closure, and durable handling.
Conversation alone is not bounded generativity. The term applies where an authored grammar bounds the inquiry and the return enters a governed selection and closure path.
The interface begins before the AI answers
The first move of a generated interface is not the model's first reply. It is the user's loading action — pasting a prompt, dragging a folder, clicking a link. If that action is wrong, confusing, or fails silently, no interface comes into being. Therefore:
Setup UX is method-bearing, not packaging trivia. File names, open-first instructions, message wrappers, folder shape, the named failure mode, the fallback path, and the expected user actions are part of the interface. They are designed, not decorated.
Governing-role integrity at load
The seed must reach the runtime as the governing entry contract, not merely as material the runtime can see. The grammar grants the aperture only if the grammar is still governing when the interaction begins. Wrapping, transport, or a later import performed under the seed's own rules does not break that condition; the failure is the runtime reconciling, retargeting, summarizing, or rewriting the seed before its contract runs. Source material governed by the authored grammar is ordinary; source material participating in the authorship of a replacement grammar, before the seed governs, is the failure.
A fork-at-load is the derivative grammar produced by that substitution and then run as though it were the authored interface. It may inherit names, read order, visible shape, and causal provenance while losing the aperture, authority boundaries, version discipline, selection, closure, audit, recourse, or the substrate mechanism that made those forms operative. Seed provenance is not seed conformance.
Prevention has a low ceiling in an opaque runtime: a seed can make an accidental mixed load visible, but it cannot compel a user or runtime to preserve it. Detection is therefore behavioral, not morphological — test whether the seed's declared governance properties operate in the delivered artifacts; never infer conformance from resemblance, provenance, or a marker the artifact carries about itself. This is the loading-boundary case of a generated thread cannot self-authorize: a runtime-produced rewrite does not authorize the derivative as the authored interface.
Operator distance — the encoding-budget dial
How much the seed must encode is a function of operator distance: how far the consumer sits from an operator who already holds the protocol.
The farther the consumer is from the operator who knows the protocol, the more the seed / wrapper must itself encode: the first action · the loading instruction · the fallback path · the expected AI behavior · the return shape · the routing / provenance marker.
When an operator performs the load, the seed can lean on that operator's standing context. When the consumer loads it alone, the seed must be idiot-proof — self-explaining, the first action obvious, with a named recovery path when the channel misbehaves.
Distance is fitted, not maximized. Operator distance is an encoding-and-support dial set to fit the consumer and the delivery context, not a maturity score to drive upward. A low-distance realization is a legitimate realization posture, not a degraded one.
Externality is not operator distance. The two answer different questions and vary independently:
externality who supplies the judgment operator distance how the activation is supported
An outside party can supply genuinely external judgment through an operator-assisted activation; conversely, an unassisted load establishes nothing about externality on its own. Reading distance as a proxy for externality overstates what a delivery posture can settle. This is a distinction between two things already named here, not a further classification axis.
The categories // illustrated
Illustrative — this doctrine is the source of truth, not the diagram. Where the figure above carries the path, this one carries the category boundaries: mechanism classifies, application names purpose, authored control meters, and conformance decides membership. The distinction it exists to hold is that carrier and runtime context classify members of the population, while governing-role integrity decides membership in it — so a fork-at-load is failed conformance, not another kind of interface. The two axes are shown as inventories, not a populated matrix: no claim is made that every carrier × runtime cell has been observed. Source: docs/diagrams/method-ASK_seed-mediated-generated-interface-ontology.html. Dark full-page mirror as above.
Worked cases — classified by carrier and runtime context
The genus is observed across two carrier species (packet, prompt); the repo-mediated delivered species is not yet instantiated — it is the forward form of AP + UO at launch, intended, not yet observed. So these are worked cases of the genus, not evidence of the repo-named species.
Case Carrier Runtime context Operator distance Personal Context System prompt-mediated (repo fallback) self-contained opaque high (self-setup) Internal domain review (4TMK) packet-mediated connected authorized low (operator-loaded) External review (AP) packet-mediated self-contained opaque intended high · observed low
Personal Context System (PCS) — prompt-mediated (repo fallback), self-contained opaque runtime, high operator distance. The consumer loads a setup prompt into their own AI tool with no operator present; the repo is the fallback link, not the primary loading object — so this is prompt-mediated with a repo fallback, not a repo-mediated case. Setup is delivered as a social-channel setup wrapper: explain the purpose; tell the user to paste the prompt rather than understand it; give the raw setup URL; name the fetch-failure mode (the tool that cannot open links says so verbatim); provide a fallback repo link. PCS is the clearest evidence that the interface is generated, not built, and the strongest lightweight example of social-channel setup UX. Load-bearing lessons: first-action clarity and a fallback when the fetch fails.
Internal domain-expert review (governed elicitation; UO 4TMK) — packet-mediated, connected authorized runtime, low operator distance. An operator loads the whole packet into a known, trusted-collaborator reviewer's standing advisor thread, which has authorized live read access to the repo (+ scratch + EXTERNAL via the Dropbox connector) — the runtime with the most authorized context access of the three, yet still packet-mediated by carrier. The package-loading burden on the consumer is low, so this case is not the source of heavy package-load UX; it is the source of three other durable lessons: the packet carries the review behavior (the standing advisor prompt infers none of it), and the human artifact must survive its actual access path — the reviewer can reach the artifact by clicking it inside the AI thread, which downloads the bare file and leaves the package folder behind. That access-path failure, not complex loading, is why the human artifact must render self-sufficiently.
External review (AP) — packet-mediated, self-contained opaque runtime; intended high operator distance, one completed run observed at low. The design target is an outside reviewer who receives, processes, and loads the packet directly, with no operator between and no authorized repo access. That target is why the case carries the strongest package-loading UX pressure: the packet must be self-explaining, must separate the human-facing artifact from the AI-facing facilitator materials (the AI works from machine-readable source, not the heavy sealed artifact), and must carry an explicit return shape.
The outside-reviewer run has now occurred. It confirms an operator-assisted external-review instance while modifying the intended high-distance realization. One external producer completed a review of a shipped release and reached a defensible approve decision, judging implementation able to proceed. Two facts hold together and neither may be dropped: the judgment was genuinely external — the operator supplied activation, never the judgment — and the activation was operator-assisted at low distance, after an unassisted attempt failed. The decision ask was not self-evident on cold entry; it became legible only once a facilitator surfaced it. The run does not validate the unassisted onboarding path. The review did not independently surface the author-known open risks, and adversarial pressure on those risks was not demonstrated. One case.
So the settled reusable / self-service external-review packet protocol remains a held subtype (see What remains local or held). The next evidence condition for the self-service realization is a property, not another event: a completed review in which the consumer reaches the decision ask and the role split unaided, through the actual delivery path. That would validate the unassisted realization; broader reusable-wrapper generality remains held pending repeated or differently situated evidence.
The null case (bracketed). Author-controlled self-use is the null case: in-category by mechanism (a repo-shaped context loaded into the author's own AI tool each session), but running in an author-controlled runtime — operator distance zero, no runtime opacity, none of the delivery failure surface that gives the doctrine its bite. In-category by mechanism, but outside the hard runtime-opacity case; named here only so the count is honest, not counted as a delivered case.
Evidence, stated honestly:
packet-mediated observed 2x (AP external, UO 4TMK) prompt-mediated observed 1x (PCS setup, repo fallback) repo-mediated // delivered observed 0x (AP + UO launch form — intended, forward-looking, not yet instantiated)
The earlier repo-mediated label named one carrier species, while the observed evidence establishes the broader seed-mediated genus.
Negative pressure case — fork-at-load (PCS setup prompt, 2026-07-09). The authored seed was loaded into a session already holding another project's exports and the runtime was asked to reconcile them; it produced a retargeted scaffold that was then run as the system. The derivative inherited the bootstrap/index morphology, read order, and causal provenance, and lost version discipline, grant boundaries, the no-self-authorization rule, and the substrate mechanism the copied filenames depended on. Not a conforming instance — it is recorded here as the first observed loading-boundary failure and deliberately kept outside the positive counts above, which are unchanged.
Invariants
- Behavior travels with the governing seed. The seed carries the process only if it survives the loading boundary in its governing role — visible shape or causal provenance alone does not establish conformance. Do not rely on a standing reviewer/advisor prompt to infer the process.
- The interface begins at the loading path. Setup UX is method-bearing.
- Operator distance sets the encoding budget — and is fitted, not maximized. The farther the consumer from the operator, the more the seed must carry on its own; but the distance is chosen to fit the consumer and the delivery context, not driven upward as a maturity value. Externality is distinct from operator distance — who supplies the judgment is not the question of how the activation is supported.
- The first action must be obvious — and unambiguously targeted. An action whose object the consumer must infer has not been made obvious. Human setup actions are minimized and named in the artifact itself; where a name carries an instruction, name the object by what the consumer must do with it, and supply identity only where the consumer needs identity in order to act.
- Presence is not governance. A governing instruction has not successfully travelled when it is merely present but not perceptually dominant at cold entry. Information carried is not hierarchy transmitted: if surrounding explanation, internal vocabulary, or a stale instruction wins the first-screen contest, the controlling rule did not arrive, however completely it was written.
- Test the consumer's actual access path, not the author's intended folder structure — the delivery channel may strip context the author assumed survives.
- Separate consumers, separate surfaces. Where a seed serves multiple consumers, keep the human-facing artifact, the AI-facing facilitator materials, and the operator-side audit / provenance distinct, and ship each consumer only what it needs.
- Markers are distinct concepts. Reviewer-routing markers ≠ ingestion-state markers ≠ provenance handles; one string must not carry all three.
- A generated thread cannot self-authorize. A setup or review interaction produces a record that informs the owner's next decision; it does not promote, publish, or authorize anything (
docs/governance.md). This invariant is strongest in the opaque runtime and is what any future delivered form must not violate.
Variation by consumer
self-setup user prompt-mediated; social-channel wrapper; idiot-proof first action; fetch fallback
internal domain expert packet-mediated; operator loads; behavior-carrying + artifact survives the access path
outside reviewer packet-mediated; direct consumer load is the design target and an
operator-assisted activation is a legitimate fitted posture;
self-explaining + AI-facilitator split + return handle
The invariants hold across all carriers, runtimes, and distances; the realization is set by the consumer, the carrier, and the operator distance.
What remains local or held
This doc lands the broad genus pattern. The following are surface-local realizations, still-held subtypes, or out-of-scope for this doctrine:
- a specific delivery-wrapper's copy and channel;
- a project's reviewer-routing suffix mechanics and its exact artifact-class taxonomy;
- exact packet folder names and provenance-handle strings;
- sealed single-file HTML as a universal requirement — it is the right realization where the access path strips the folder, not a law;
- the settled reusable / self-service external-review packet protocol — still held. The outside-reviewer run has occurred and is recorded above as an operator-assisted instance, so the hold no longer waits on that event. The next evidence condition for the unassisted realization is a completed run in which the consumer reaches the decision ask and role split unaided; that would validate the unassisted realization only, and reusable-wrapper generality across reviewers, products, channels, and relationships remains held pending repeated or differently situated evidence;
- whether stakes / blast-radius is a third control dial (beyond aperture × operator distance) — a held analytical thread. The earlier framing, that the external-review corner co-maxes operator distance and stakes while running a tight aperture, is retired as a fixed characterization: the one completed external review ran at low operator distance, so external review does not occupy a fixed corner. The question is unresolved, and the evidence that would resolve it is comparative — vary distance at comparable consequence, or vary consequence at comparable distance — since one run at a single point cannot separate a corner, a latent third axis, and an interaction effect;
- consumer-owned renderer / sealing tooling;
- a settled cross-carrier behavioral conformance test — the principle (test whether the governance properties operate) is doctrine; the reusable checklist or score is held pending a second case;
- independently verified seed attestation, and whether it can support a larger evidence stack — a self-carried marker does not independently establish conformance and is not added here;
- a generalized derivative-label taxonomy, and whether repeated cases warrant a standalone seed-integrity doctrine rather than this section;
- delivered launch form (e.g. "the user clones the repo and uses it") — a plausible B2B form for AP + UO, but stated intent, not a landed instance; it is not the universal launch form. Consumer-facing delivery, hosted-runtime, and monetization reasoning are out of scope for this doctrine and stay live on their originating surface, not method doctrine. Runtime-native skill packaging is one possible substrate-specific delivery form inside this same held seam and may carry a host-specific activation path. A
SKILL.mdbundle or host installation wrapper would still classify through the existing carrier axis and would not, by itself, establish SMGI membership. The current ASK evidence set includes no observed skill-packaged SMGI instance; this held possibility creates no method-level implementation requirement.
The broad genus thesis is doctrine; the review-packet subtype, the stakes dial, and the delivered launch form stay held or out until their own gates land.