system-ASK // one apex, recursive ecology

examples/system-ASK.md · 26754 B · source sha256 083fc03bcf28

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-retention
CONTINUITY   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.