system-ASK // one apex, recursive ecology
Projection boundary — canonical compression, not system authority. This file is the maintained
high-level public projection of system-ASK as an ASK-specific worked example. It owns this compression,
its diagram relation, and its lineage. It does not own the distributed system it depicts, and it is
not the authority it depicts — those are two separate statements, and the second is the one a reader of
a compression is most likely to lose. Named method, protocol, repo, grounding-note, context, and operator
owners remain authoritative for their claim classes; ASK remains the source-of-intent and authorization
apex. A disagreement is an audit finding, and it settles nothing by itself: named owners establish
current fact; ASK adjudicates whether the system, this compression, or both should change. No correction
target follows automatically from a mismatch. The file deliberately omits fast-moving state and local
mechanism, and confers no permission, scope, conformance obligation, or operative authority.
on this page
What this is
system-ASK is a human-governed, AI-mediated system-building system: a practice for carrying a source of
intent through definition, realization, selection, governance, and correction — without letting the tools
that execute or critique the work become its normative source.
Three names, one relation:
system-ASK human ASK, apex-bound to the realization field
ecology-ASK the bounded realization field of specialised surfaces
method-ASK the portable methodology, abstracted from the practice and
reapplied to it
The apex sits inside the system-ASK boundary while remaining outside the field it governs —
membership without derivability. That is the whole architecture in one sentence: intent originates at the
apex and is never synthesized upward from the field.
See docs/normative-apex.md §Membership and derivability are different axes,
and examples/system-ASK-bounded-generativity.md, which maps the same
practice onto the bounded-generativity primitive at one altitude down.
Membership in the realization field is functional. A surface is inside it when its function is realization — which includes the project repositories and the public surfaces that render and articulate the work. Being durable, or being public, does not place a surface outside the field; it places it at a different point within it.
The same relations are projected as a figure:
docs/diagrams/method-ASK_system-ASK-hero.html. The
prose and the figure are one delivery unit with two representations. This compression is source of
truth for the figure; neither is authority for the distributed system they depict. The figure is
generated against this accepted claim set, never authored beside it.
Core operating logic
one apex distributed truth plural reasoning singular mutation recursive execution governed return
These six labels are this file's compression vocabulary. They are not established method-ASK terminology, and no owner carries them as terms of art. Each names a relation that is owned, and the owners are cited below.
method explains protocol operates design expresses projects realize + pressure operator planes coordinate + preserve public surfaces render + articulate ASK authorizes · selects · adjudicates · closes · answers
One apex
The governing standard is supplied to the execution function and is never legitimated by executing it.
Delegation deepens execution; it never raises source-role height. However deep the recursion runs, the
normative apex does not multiply.
→ docs/normative-apex.md §The apex, §Delegation does not propagate the apex.
How the upstream layers stand to each other
Method doctrine, execution protocol, and project realization are not peer layers. Method doctrine governs the execution protocol, and the execution protocol governs project realization — an ordered relation, not a federation. A project does not originate protocol, and the protocol does not originate method doctrine; each layer supplies the standard the next one operates under.
Design crosses that stack rather than occupying a rung in it. design-system-ASK is an upstream owner
on its own visual-inheritance axis, reaching named consuming surfaces through the routes its owner
declares. Its upstream relation is the separate visual-inheritance axis just named, not a rung in the
method-to-protocol-to-project authority chain; ordering it into that chain would assert a relation no
owner states.
→ README.md §Layer relationship; docs/bounded-generativity.md;
control-surface/protocol/README.md;
control-surface/docs/architecture.md.
Conformance runs on a separate axis, and it runs the other way. method-ASK is itself a repository, and
it resolves the execution protocol like any other consumer — so on the conformance axis it is downstream of
control-surface, while on the authority axis it remains upstream of it. Collapsing the two axes inverts the
model: it would make the protocol the source of the doctrine it operates under.
Distributed truth
There is no single document that holds what the system is. Truth is distributed across owners by aging
rate: artifacts that track state age fast and live with the thing they track; artifacts that point at
state age slowly and stay useful across sessions; a carrier that mixes rules, context, and state ages at the
rate of its fastest content. Claims are assigned to owners whose maintenance posture fits their aging rate;
where one carrier mixes rates, it inherits the rate of its fastest-changing limb.
→ docs/source-of-truth-and-aging-rate.md; the execution-side
rule is §Source-of-Truth Boundaries / Aging-Rate Principle in
control-surface/protocol/AGENTS.shared.md;
docs/method.md restates it in one sentence.
This file is subject to that rule, which is why its caveat is the first thing in it.
A repository's authority is bounded, and the bound is easy to overrun. A repo is authoritative for
repo-owned project truth and current repo state — not for everything the project currently is. Purpose,
workflow, identity, operator state, and delegated domain judgment each have their own owners, and a repo
holding an artifact about one of them has not thereby acquired the claim.
→ docs/source-of-truth-and-aging-rate.md.
Persistence is not authority. A carrier that survives across sessions has not thereby acquired standing:
a durable operator note, a retained working memory, a cached map — each may persist indefinitely while
remaining non-authoritative operator context, owned by no claim class and settling nothing. Longevity is a
property of storage, not a source of warrant.
→ docs/source-of-truth-and-aging-rate.md.
Plural reasoning, singular mutation
Several differently situated surfaces reason over the same work before any of it is mutated; one
authorized writer holds each branch or declared mutation aperture. The discipline is per-aperture, not a
global serialization of unrelated work. The advisor surface holds no write authority and reviews from
outside the execution thread; the execution surface plans and performs authorized work under a single-writer
discipline; ASK relays and adjudicates between them. Occupancy is operational, not architectural — the roles
are slots, not models.
→ control-surface/README.md
§Operating Model; control-surface/docs/architecture.md
§Role Model; control-surface/protocol/AGENTS.shared.md §Session Topology / Single-Writer Discipline.
The mutation side is stricter than it looks, and its scope is exact: a write to shared mutable state must declare the exclusion guarantee it actually has — observed-state checks, cooperative exclusion among participants, or a backend-enforced conditional write — and a caller that needs a stronger guarantee than the backend provides must get a failure rather than a silent downgrade. Two boundaries hold that rule in place. It governs writes to shared mutable state, not every write, so an ordinary single-writer edit acquires no concurrency ceremony. And it is a requirement on such writes, not a report that every write path in the system already enforces one. Claiming more than the substrate delivers is the failure the rule exists to prevent; claiming the rule is already satisfied everywhere would be the same failure at a larger scale.
Recursive execution
Standing intent reaches work through nested delegation:
standing intent >> execution grant >> derived task intent >> task brief
>> realization inside the granted aperture
>> parent verification + selection + integration
>> program-level authorization + closure
>> authorized program result
Each link changes operational form or granularity without changing normative origin. A parent decomposing an
objective sets subgoals under the standard; discovering mid-execution that the standard should change
routes as candidate correction, never as silent local revision. Ordinary delegate output is candidate
material until an authorized parent accepts it. Local completion is not program closure. Authority attenuates
downward and never accumulates upward.
→ docs/source-of-intent.md §Runtime delegation through the execution span;
docs/bounded-generativity.md §Nested realization fields and recursive
delegation — nesting creates brackets, not apexes.
Governed return
The system leaves its own frame, produces, and brings back what it made — but return is not ascent. Evidence,
critique, and candidate correction travel upward and enter through a governed absorption gate: material
is classified before it changes anything, the recipient owns the absorption decision, and nothing becomes
operative by arriving.
→ docs/absorption-discipline.md;
docs/method.md §The swing, which additionally names absorption and closure as strokes
of the same maintenance pass; docs/source-of-intent.md §Intent repair targets current standing intent,
which holds the load-bearing case: repair instrumentation measures distance, governance classifies
warrant. A divergence measure registers movement away from the target; it cannot tell whether that movement
is damage or warranted correction. So a candidate correction is preserved and surfaced to the role authorized
to revise — neither silently adopted nor silently repaired away. Governed return is this file's framing;
the absorption limb is owned doctrine.
How the method itself changes
The three circuits below are all relations within a pass. None of them says how the practice's own
abstraction moves, and that movement is the reason method-ASK exists as a separate thing from the practice
it came from. The methodology is abstracted from the practice and reapplied to it, and each pass is tested
against the practice rather than against itself — adversarial iteration across time, not a fourth loop
inside any single pass. An abstraction validated only against its own prior generation stops tracking the
thing it abstracts.
→ docs/method.md §The swing; docs/bounded-generativity.md.
Raking, and what a raked state can claim
Periodically the practice stops producing and passes back over what it has made: it re-reads the current
owners, restores visible order, and routes what drifted to the owner authorized to correct it. Producing a
representation does not itself complete that pass. Completion requires the material findings to receive an
explicit disposition — and a representation is not a disposition. A standing map earns its keep because it
makes distributed relations visible across a field no single document holds; it is dangerous for the same
reason, because it can drift out of agreement with its owners, or be mistaken for the authority it
summarizes.
→ docs/method.md.
That danger has a discipline attached. A claim about a raked state is dated, banded, owner-relative, and
explicit about what it excluded. A pass covers the sources it actually read, at the altitude it actually
read them, on the day it ran. Reporting it without those qualifiers converts a bounded pass into a stability
claim the pass never established — and a stability claim is exactly what a reader will act on.
→ docs/method.md.
Rake basis // 2026-09-09. Band: the stable public relations projected in this worked example, owner-relative to the public owners cited inline. Excluded: claims deliberately omitted or held at operator altitude, live rosters and state, private-instance topology, and the process and review mechanics by which it was prepared. This records the bounded basis of the pass. Calibration // adjudicated 2026-09-08; corrections landed 2026-09-10. This compression is the corrected result of the bilateral calibration it requires, run on a proposal-stage version of it. Completion belongs to that calibration, not to this file, which still certifies neither itself nor any permanent stability.
Three coupled circuits
PRODUCTION intent >> grammar / aperture >> authorized realization
>> selection + closure >> artifact governance >> governed artifact
LEARNING pressure >> evidence >> critique + classification >> adjudication
>> a disposition: the correct durable owner and governed propagation,
OR an explicit nomination, hold, or no-retentionCONTINUITY fresh context >> bootstrap + index >> named live owners
>> current work >> lineage preserved >> what remains open
The three share one apex and one owner topology. They do not share one artifact — which is why no single document, including this one, can carry the system.
The learning circuit terminates in a disposition, and propagation is only one of them. An unearned generalization becomes an explicit nomination or a hold; material that earns no durable retention is retained nowhere. A circuit in which everything that enters propagates would describe a system that cannot refuse, and refusal is the part that keeps the doctrine small.
The circuit names are this file's vocabulary; the mechanisms are owned by the execution protocol
(control-surface/protocol/AGENTS.shared.md — plan-before-execute, the exact-scoped-diff gate, review
objects, PR and post-merge discipline; §Learning Disposition; §Verification Claims and §Session-Start
Discipline).
Stable roles
Roles, not rosters. A new project instantiates an existing role without changing the model.
human ASK source of intent · authorization · relay · selection ·
adjudication · recourse
method-ASK the portable primitives and their cross-surface relations
control-surface the execution protocol, review mechanics, and reusable carriers
design-system three kinds of material, and only three: visual foundations,
artifact-inheritance scaffolds, and live surface patterns
project repos domain truth, implementation, artifacts, a local workflow delta,
and the pressure from which protocol rules get discovered —
authoritative for repo-owned project truth and current repo state
operator planes grounding, retrieval maps, coordination, intake, evidence, lineage —
they coordinate and preserve, and never own repo truth
Public expression is federated by claim class. The front door, the publication surfaces, and the public context scaffold each own what they own; no owner holds a general public-expression role, and grouping them under one heading is this file's orientation lens rather than a relation any owner declares. Read as a lens it is useful; read as a role it invents an owner.
The front door is a build artifact that renders public identity and proof; it does not become the source of
what it renders.
→ ASK/README.md.
The design-system's three kinds are the owner's own taxonomy. Shared implementation support beneath them —
a helper consumed by several patterns, for instance — is subordinate to those kinds and does not become a
fourth.
→ design-system-ASK.
Within execution, the operating roles are bounded and differently authorized — advisor, executor, critic,
domain authority, delegated subagent. Each role is owned separately; naming them as one set is this
file's framing. They are distinguished by authority, not capability: a surface that
can do a thing is not thereby permitted to. Domain authority carries two independent axes — whether the
expertise sits outside the execution surface, and what its judgment actually binds. Both are declared per
engagement, and neither is fixed by the role's name.
→ control-surface/docs/domain-authority-review-protocol.md.
How material moves
The protocol is resolved, not copied: a shared body resolves verbatim into a consumer's own carrier, so one
rule has one owner and many resolutions.
→ control-surface/protocol/README.md.
Design material reaches its consumers by more than one owner-declared route. A first-party surface in the
design-system's own repository consumes it by reference; a downstream repository vendors it at a pinned
commit; and the owner may declare further routes for particular material. What is universal is the
prohibition, not the mechanism: nothing is hot-linked at runtime — no CDN, no runtime fetch — so a
consumer's appearance cannot change underneath it, and re-sync is an explicit act. Where an owner
additionally establishes byte-identity for a named carrier, that parity is a property of those named
carriers and is enforced by the owner's own check; it is not a general claim that every vendored file
everywhere is byte-identical to its upstream.
→ the routes and the vendoring rule:
design-system-ASK/README.md; a named public vendored consumer:
ASK/README.md; the named shared carrier whose byte-identity its owner establishes and enforces:
patterns/diagram-static-H/README.md.
A fresh routed handoff that proceeds through first ingestion and classification distinguishes four
events with different actors and different evidence — routing, feeding, ingestion, disposition — and it may
instead exit before ingestion. The path is not an inevitability of routing: an artifact not currently
awaiting first ingestion does not enter it. Absorption is one possible disposition, not the name for all of
them.
→ control-surface/protocol/AGENTS.shared.md §Inbound Handoff TBI Marker;
docs/intent-artifacts.md.
The visual system is organized in three tiers, of which the third is the one that gets assigned to a
surface rather than inherited by it. ASK-the-entity carries ASK Tier 3 by identity. Another surface may
receive that Tier-3 value through explicit local assignment — and the assignment makes it neither ASK-the-entity
nor a member of anything. What each tier contains, and which surfaces currently hold an assignment, are
owned elsewhere and are not stated here.
→ the assignment relation: design-system-ASK/README.md;
the ASK-by-identity case: ASK/README.md.
The wall
Part of the system's context is private and stays private, and the mechanism is worth stating precisely, because overstating it is the more common error. Folder separation defines the boundary and makes it auditable: a narrow subtree is granted, and everything above it lies outside the grant. It does not by itself make the wall structural. For a named operating surface, the wall is structural only where that surface is actually confined to the granted subtree. Under that enforced path-scoped grant, the private parent is outside the surface's reach, and the grant boundary equals the content boundary. Reachability is not a load instruction, and being reachable does not make a file's contents a conformance obligation.
The public form of this pattern, with the private instance omitted, is published as a scaffold:
personal-context-system — a
public method artifact, never a private instance, and never a runtime governor of one. Its generic,
publishable statement of this boundary is
templates/context-architecture-decisions.template.md.
Both links name the stable ref deliberately: the default branch moves ahead of what distribution surfaces
point at.
Non-identities
Distinctions whose collapse would mis-govern the system. Most are stated verbatim by a named owner. Three items in this file carry a different status, and are marked so they are not read as owner language:
technical access != audience authority public abstraction of a wall-safe fact owner inheritance != absorption artifact-local synthesis from public component owners the bounded operating-role SET, and artifact-local framing, in §Stable roles — neither is a the public-expression grouping non-identity, and neither is listed below
delegation depth != source-role height generation != judgment capacity != authority persistence != authority technical access != audience authority storage location != ownership registration != live state live state != authorization applicability != write permission != current conformance routing != feeding != ingestion != disposition advisor output != operative instruction before relay fresh context != epistemic independence inheritance != absorption assigned ASK Tier 3 != inheritance, != entity identity, and != membership public scaffold != private instance diagram != source of truth compression != the authority it depicts role != carrier
Three deserve their own sentence. Fresh context is not epistemic independence — differently situated
surfaces supply adversarial pressure from outside execution momentum, not independent epistemic authority;
convergence between them is neither authority nor truth.
→ control-surface/templates/advisor-project-bootstrap.template.md;
control-surface/docs/critique-protocol.md.
A diagram is not a source of truth — a rendered figure illustrates a relation whose authority lives in
the prose and the repo that own it, and a figure cannot repair an ambiguity the prose left open.
→ patterns/diagram-static-H/README.md §Source-truth boundary.
A compression is not the authority it depicts — which is this file's own status, stated in the caveat
and repeated here because it is the distinction most easily lost by the reader of a summary. The two are
separate: the first is about figures, the second about maps of any kind, and they have different owners.
→ docs/method.md; patterns/diagram-static-H/README.md.
What this file does not claim
It does not claim that every operation in the system is correctly governed, that every judgment is right, or that the system proves its own legitimacy. The structure secures answerability in principle; whether it is discharged well in any given case is a separate question, and not one this file can settle. It does not enumerate repositories, consumers, programs, assignments, or current state — those age at rates this file deliberately does not track. Where it and a named owner disagree, the owner establishes the current fact — and what should change is ASK's to adjudicate: the system, this file, both, or neither.