Design Guidelines

Adaptive Information Design Guidelines

For designers and engineers: let users see enough relevant information for their current task, and still be able to find, understand, and complete it after the information changes.

6 principles · 24 rules · MUST 21 · SHOULD 3

Contents

For designers and engineers: let users see enough relevant information for their current task, and still be able to find, understand, and complete it after the information changes.

These guidelines consist of six principles and 24 rules, paired with Design Token and reference sources. The clauses are this project's design requirements; facts from external sources and this project's own inferences are stated separately, and no claim is made that this has already received product validation.

1. Scope and definitions

Information adaptation design: the interface adjusts the selection, level of detail, order, presentation form, and timing of appearance of information according to the current task, the user's explicit preferences, the operating context, and system state, while keeping necessary content visible, changes understandable, and the user in control.

These guidelines apply to information-dense scenarios such as task panels, result lists, dashboards, editing tools, detail pages, and agent work surfaces. Adaptation may be implemented through explicit rules or through model inference; whether AI is used does not change the requirements of these guidelines.

Information detail level and visual density are modeled separately. Detail level determines how many fields, explanations, and pieces of evidence appear; density determines spacing, line height, and other layout. Equally detailed information can use a comfortable layout, and a summary mode does not require a smaller font.

These guidelines do not treat "showing less" as the default goal. Comparison, verification, and troubleshooting may require more information; whether an adaptation succeeds depends on task outcomes and the cost of change.

2. The six principles

Principle	Object of regulation	Design direction	Rules
A1 Adaptation is grounded	Adaptation inputs and decision scope	Decide based on valid task and context, distinguishing facts, preferences, and inferences	A1-1～A1-4
A2 Information stays complete	Content selection and expression	Allow reduced default display while retaining the semantics and access needed for understanding and action	A2-1～A2-4
A3 Change stays continuous	Update timing and position	Control the scope and frequency of change; protect reading, positioning, and input	A3-1～A3-4
A4 The user retains control	Decision authority between user and system	Explicit choices take effect, persist, and can be reversed	A4-1～A4-4
A5 Presentation stays understandable	Explanation of change and access methods	Let users understand the current view and access content through usable means	A5-1～A5-4
A6 Effect is verifiable	Evaluation and failure recovery	Compare against a stable baseline, verify the benefit, and retain a usable fallback form	A6-1～A6-4

Each rule is assigned to one principle by its primary object of constraint; a single scenario is often constrained by several rules at once. This grouping supports division of responsibility and does not claim to have proven mutual exclusivity or completeness.

2.1 Normative terms and how to read clauses

MUST / MUST NOT / forbidden: hard constraints of these guidelines.
SHOULD / SHOULD NOT: followed by default; when deviating, record the rationale, the alternative, and the verification result — no additional approval step is required.
MAY: an optional implementation that adds no obligation.

Judgments take the independent obligation clauses in the main text as their unit: a declarative sentence without a normative term carries the strength of its rule heading; a clause with an explicit normative term is judged at its own strength — a MUST / MUST NOT / forbidden clause inside a SHOULD rule remains a hard requirement, and strength annotations on rule headings or quick-reference tables do not replace clause-level binding force. Prohibited behavior is always expressed with "MUST NOT"; "cannot" is used only for statements of fact or capability, never for obligations. Examples, design applications, and counterexamples reveal requirements and failure paths; they add no obligations.

The "Rule" section states the requirement, and "Applies to" bounds its scope; verification examples and counterexamples aid understanding and add no further requirement. Source links indicate a reference relationship; they do not mean the source prescribes this clause word for word. Conflicts among hard-constraint configurations MUST be resolved first, not bypassed by relying on a token's override order.

3. Rules in detail

A1 Adaptation is grounded

A1-1The task and the object of adaptation are explicitMUST

Applies toany scenario that automatically selects, condenses, highlights, or reorders information.

RuleEach adaptation MUST make explicit the task it serves, the adjustable information unit, the allowed dimensions of change, and the triggering event. "Smarter" or "more concise" alone is forbidden as a basis for adaptation. While a user is comparing, checking, or recovering a task, the system MUST retain the information those activities require.

Acceptance evidence: user side — the user can state which task the adaptation helps accomplish; implementation side — the task, region, trigger, and allowed dimensions of change are all defined.

Paired counterexamples: Under-delivery — fields are reduced because dwell time was short; over-delivery — every card requires the user to pick a mode first.

Verification examplesSwitch the same result list between browsing and comparison tasks, and check whether the comparison fields appear as specified, and whether the selected objects remain in the comparison set.

A1-2Distinguish facts, preferences, and inferencesMUST

Applies toadaptation that uses behavioral history, task signals, or model judgments.

RuleAdaptation inputs MUST state their source and scope, treating current-task facts, explicit preferences, and inferred results separately. The current, explicit task and the user's choices within it take precedence over historical inference. Behavioral frequency may influence recommendations, but MUST NOT alone serve as grounds for permanently reducing a feature or its explanation. When using behavioral feedback such as clicks for inference, unshown, out-of-viewport, failed-to-load, and shown-but-not-clicked MUST be distinguished; content the user never had a chance to see MUST NOT be judged as "not interested."

Acceptance evidence: user side — explicit choices take effect, and unfamiliar tasks still receive an explanation; implementation side — facts, preferences, inferences, and non-exposure events are distinguishable.

Paired counterexamples: Under-delivery — content is permanently hidden after not being clicked once; over-delivery — the user is asked about intent on every single visit.

Verification examplesA frequent user of the product still receives explanations on first entering an unfamiliar task; after selecting "always show details," usage frequency no longer triggers automatic collapsing.

Reference: R01, R05.

A1-3Unknown and stale signals have a fallbackMUST

Applies toautomatic adaptation where signals may be missing, delayed, conflicting, or stale.

RuleThe product MUST define validity conditions and failure behavior for the signals it uses. When reliable judgment is not possible, fall back to the standard presentation or retain the current, still-valid presentation; unknown MUST NOT be treated as "not needed." If change is triggered by model confidence, the relationship between that score and actual error MUST be verified; a model's self-reported confidence MUST NOT be directly interpreted as accuracy.

Acceptance evidence: user side — the task can still be completed when a signal is unavailable; implementation side — injecting missing, conflicting, and stale inputs yields a deterministic fallback.

Paired counterexamples: Under-delivery — unknown is treated as no need; over-delivery — any uncertainty blocks the page from opening.

Verification examplesTurn off historical data, delay task state, and return conflicting predictions, then check that necessary information remains visible and the interface remains usable.

Boundaries: No unified confidence percentage or validity duration is prescribed across the whole product; verify per signal and per consequence.

A1-4Adaptation does not change permissions or business semanticsMUST

Applies toadjusting the interface by role, location, sharing state, or personalized information.

RuleThe system MUST apply permissions and content visibility scope first, and only adapt within the permitted content afterward. Summaries, search, explanations, and "show all" entries MUST NOT bypass permissions. User preferences may take effect only within the permitted range; collapsing information MUST NOT be interpreted as deletion, completion, or cancellation of a task. Only signals actually needed for the current adaptation, and cleared for that use, may be used; a sensitive profile MUST NOT be built up just to simplify ordinary information defaults.

Acceptance evidence: user side — unauthorized content cannot be obtained through a summary or by restoring a view; implementation side — permission filtering covers caches, search, and full detail views.

Paired counterexamples: Under-delivery — a pinned field bypasses a revoked permission; over-delivery — denying one field clears all authorized content.

Verification examplesAfter a permission is revoked, neither a previously pinned field nor a restored historical view can show the restricted content again; collapsing a task does not change its execution state.

A2 Information stays complete

A2-1Necessary information is not cut by a budgetMUST

Applies tosummarizing, collapsing, truncating, previewing, or ordering information.

RuleThe product MUST define necessary content per the current task, including object identity, key state, exceptions affecting the current decision, consequences of an action, and required conditions. Necessary content MUST NOT be hidden merely because of a count, line, or density budget. When space is insufficient, the product MUST adjust the container, provide a dedicated detail path, or route the relevant action into a step with adequate disclosure first; a confirmation MUST NOT be required when the basis for judgment is missing.

Acceptance evidence: user side — key exceptions and the consequences of actions are discoverable; implementation side — the necessary set is not cut by an ordinary count budget.

Paired counterexamples: Under-delivery — a fourth exception is cut off by a cap of three; over-delivery — every field is marked necessary.

Verification examplesWith a preview cap of three, insert a fourth critical exception and check that it still enters the visible necessary region; bulk exceptions may be aggregated, but the count, impact, and access entry MUST be shown accurately.

Reference: R03.

A2-2Detail-level tiers have a defined contentMUST

Applies toproviding multiple levels of detail for the same information unit.

RuleEach tier MUST define the fields it includes and its default behavior. When drilling into the same object, its identity, main conclusion, and qualifying conditions MUST be retained; a level hierarchy MUST NOT be implemented as an arbitrary character-count truncation. A change of task phase may replace related modules, but MUST NOT cause unresolved issues or unfinished input to be lost. Supplementary explanation and visual spacing are configured separately.

Acceptance evidence: user side — the meaning stays consistent as the tiers are expanded; implementation side — the field set for each mode is defined and retains qualifying conditions.

Paired counterexamples: Under-delivery — mechanical character truncation changes the conclusion; over-delivery — every mode shows the full explanation.

Verification examplesExpand the same object through each tier and check whether numeric units, statistical scope, time, and conclusion qualifiers stay consistent; check whether "detailed + comfortable layout" is a valid combination.

CounterexamplesA summary reads "succeeded," while the detail view is the only place that mentions a partial failure; a so-called expert mode is just a smaller font.

A2-3Omitted content is discoverable and reachableMUST

Applies tomoving content the user is authorized to access out of the default view.

RuleAn entry with an unambiguous meaning MUST be provided, stating what content will appear. If a count is shown, it MUST accurately distinguish what is loaded, currently filtered, and the total; when the total is unknown, an exact count MUST NOT be fabricated. Adaptive omission MUST NOT cause content to disappear from a search or full-detail path the product has promised.

Acceptance evidence: user side — the user finds collapsed content and can retry after a load failure; implementation side — the entry point, permissions, and count basis match the real data.

Paired counterexamples: Under-delivery — the "more" entry is broken but shows "no more"; over-delivery — every minor field gets its own persistent button.

Verification examplesA user unfamiliar with the page finds a collapsed field; when loading fails, the entry states the failure and offers a retry, instead of showing "no more."

Reference: R04.

A2-4Representation conversion preserves verifiable meaningMUST

Applies toconverting a table to a chart, a number to text, detail to a summary, or using generated content.

RuleA conversion MUST preserve the task-relevant units, range, time, source, and uncertainty; it MUST NOT change the conclusion for the sake of simplification. When calculation, comparison, or exact verification requires the original value, an accessible path to that original value MUST be provided. A generated summary MUST be bound to a traceable input snapshot; when key meaning cannot be preserved, fall back to a validated template or the original content.

Acceptance evidence: user side — the user can verify against the original value and identify uncertainty; implementation side — the summary and the original value come from the same valid input snapshot.

Paired counterexamples: Under-delivery — a partial failure is summarized as a success; over-delivery — every summary repeats the entire original text.

Verification examplesAfter converting content that contains missing values, negative values, partial failures, and stale data, it is not described as complete, normal, or up to date.

Reference: R01, R02 support the direction of representation adaptation; the input-consistency and fallback constraints for generated summaries are this project's own derivation.

A3 Change stays continuous

A3-1The object being interacted with is protected during interactionMUST

Applies toupdates that occur while editing, selecting, dragging, pressing, or using a menu.

RuleAn automatic update MUST NOT replace the target currently being operated on, and MUST NOT clear input, composition state, or a selection set. An update that would move the target's position MUST be deferred to an interaction boundary, or implemented in a way that does not move the target. When an urgent business change genuinely requires terminating an operation, the reason for invalidation MUST be made explicit and recoverable input MUST be retained; the original click MUST NOT land on a different action.

Acceptance evidence: user side — input and the selected object are retained, with no accidental activation; implementation side — asynchronous updates are injected during composition input, pressing, and dragging.

Paired counterexamples: Under-delivery — a new button at the old position receives the original click; over-delivery — even a revocation is queued while protecting input.

Verification examplesInject an update while typing Chinese input, holding a button, or selecting multiple rows, and check that content is retained and no other action is triggered by accident. Out-of-order scenario: prediction A returns late → the user manually pins a choice → prediction B returns → A finally arrives even later — only a presentation consistent with the latest valid choice may be shown; also test revoking permission, switching objects, and turning on reduced motion during the wait, confirming the stale result does not come back and necessary exceptions remain reachable.

A3-2Ordering has a stable pathSHOULD

Applies toadjusting the order of menus, lists, or cards by relevance or usage history.

RuleA stable navigation and full-list path SHOULD be retained, with preference for a fixed recommendation region. User-specified ordering and fixed positions MUST be honored; automatic ordering MUST define a stable order for ties and the timing of reordering. For products that genuinely need dynamic reordering, such as live rankings, the product SHOULD let users understand how updates happen and provide a pause or snapshot suited to reading (the contractual requirements for a reading pause are given in A4-1).

Acceptance evidence: user side — the stable entry and manual ordering remain usable; implementation side — tie-break ordering is deterministic, and explicit ordering is not overridden by predictions.

Paired counterexamples: Under-delivery — positions randomize on every refresh; over-delivery — a task that needs ranking never updates.

Verification examplesReturning to the same task repeatedly, the primary action can still be located; new recommendations do not change a user-set chronological order.

Reference: R05, R07.

A3-3Update scope and frequency are boundedMUST

Applies topages that continuously sense context or update automatically.

RuleThe product MUST define the update boundary, the regions allowed to change, and a mechanism suppressing back-and-forth flips. When a continuous signal fluctuates near a threshold, use a verifiable approach such as stable conditions, hysteresis, or merged updates. An exception that genuinely needs immediate presentation may bypass ordinary throttling, but MUST NOT bypass interaction protection or content constraints.

The wait between an adaptation decision and its actual application may be arbitrarily long (for example, until the interaction ends). A deferred adaptation MUST, before it is actually applied, re-check whether the current object, content snapshot, permissions, explicit user choice, and policy are still valid; a result superseded by a later decision, or no longer applicable, MUST NOT be applied. Pending updates that affect only the same presentation purpose SHOULD be merged, without replaying a stale intermediate form. Every kind of update boundary MUST define its specific triggering event and the disposition when that event never occurs, to prevent a necessary update from waiting indefinitely.

Acceptance evidence: user side — the page does not flip back and forth, and necessary exceptions are known promptly; implementation side — stale decisions are re-checked and discarded before application, and the queue can be terminated.

Paired counterexamples: Under-delivery — a late-arriving result overwrites a newer choice; over-delivery — a cooldown period is used to block an urgent exception.

Verification examplesMake an input signal repeatedly cross a threshold; the page does not keep flipping between summary and detail. Check that an update pending during the wait eventually appears at the appropriate boundary.

Reference: R05 supports controlling the scale and frequency of change; the specific suppression mechanism is this project's own derivation.

A3-4Reading position and focus are retained after an updateMUST

Applies toinserting, collapsing, replacing information, or switching detail level.

RuleThe current object's position, a reasonable scroll anchor, and logical focus MUST be retained. When focused content disappears because the user collapsed it or it became business-invalid, focus MUST move to its triggering control or a reasonable successor position. Visual order and programmatic reading order MUST preserve the task's meaning; the page MUST NOT jump back to the top without reason, nor leave focus on an inaccessible element.

Acceptance evidence: user side — the user can continue the original reading task after expanding or collapsing; implementation side — logical focus and the object anchor remain valid.

Paired counterexamples: Under-delivery — focus lands on a hidden element; over-delivery — every ordinary data refresh forcibly moves focus.

Verification examplesExpand, collapse, and update a list with a keyboard and with a screen reader respectively, and confirm the current task can continue.

Reference: R10; scroll-anchor protection is a further design requirement of this project.

A4 The user retains control

A4-1Support viewing and pinningMUST

Applies tothe system automatically reducing or changing the information presented.

RuleThe user MUST be able to access the complete authorized content, and MUST be able to pin the needed level of detail, fields, or order within an appropriate scope. Control may live on the object, the view, or in settings; a toggle next to every piece of information is not required. Pinned information MUST still receive normal business-data updates; a pinned presentation is not the same as freezing the facts.

Background data refresh and the reader's page turning over are two different things: the former is facts continuing to change; the latter is when the reader sees the new content. For regions with automatic updates that the user needs to read (including regions that make no prediction at all and only continuously refresh a metric), the product MUST define a reading-pause contract with at least four items:

Item	Requirement
Scope of presentation affected by the pause	Which regions stop refreshing, and which are unaffected
Data timestamp indicator	Which moment's data is shown during the pause; MUST be visible to the user
Resume method	Who triggers it; resuming reads the currently valid data — a stale snapshot MUST NOT be labeled as current
Events that MUST still take effect during the pause	Permission revocation takes effect immediately; necessary exceptions are presented in a way that avoids accidental activation while still being perceivable

In Web content where WCAG SC 2.2.2 applies, provide the control that criterion allows; when adopting its essential exception, the rationale MUST be recorded for that specific activity, and the exception MUST NOT be claimed merely by calling something "real-time." A reduced-motion setting does not substitute for a reading pause — the two do not constrain the same thing.

Acceptance evidence: user side — the effects of pinning, pausing, and resuming are distinguishable; implementation side — background facts and permission checks keep working during the pause.

Paired counterexamples: Under-delivery — a pinned view causes a failure state to never appear; over-delivery — every piece of data forces the user to refresh manually.

Verification examplesAfter pinning a field, it still appears within the agreed range when the user returns across tasks; the field still updates with new values. A non-predictive auto-refreshing dashboard can pause for reading; moving focus away does not force a resume; a revoked permission during the pause still hides the restricted field; on resuming, the current data is shown; the applicability of the essential exception is recorded separately.

A4-2Preference scope and duration are explicitMUST

Applies toremembering a user's manual display choices.

RuleThe product MUST define whether a preference applies to this viewing session, a view type, a workspace, or an account, and when it expires. Every preference MUST bind four things — subject, target dimension, scope identifier, and target object — none of which may be omitted or it cannot be resolved. A more specific explicit choice takes precedence over a broader default preference; within the same scope, the most recent explicit choice governs.

"More specific takes precedence" is a principle, not a complete precedence relation: object and view_type can cross without nesting (the same object appears in multiple views; the same view hosts multiple objects), and this rule does not determine which of the two wins. The product MUST select and declare a single, deterministic order at the configuration-contract level (see §1.1 of the companion dictionary); if an "object × view" combined scope is supported, it MUST be stated explicitly that this combination is more specific than either alone. A temporary override MUST be explicitly scoped to the current viewing session.

Modifying a preference at a broader scope only updates that layer; when a more specific override exists and causes the current view to show no change, the user MUST be told why and given an entry to cancel that override — the user MUST NOT see "saved" with no visible change. Concurrent modifications within the same scope are resolved by server-side event order or a declared deterministic conflict rule, not by local clocks across multiple devices alone. A one-time temporary expansion MUST NOT silently become a permanent profile, and restoring the default MUST NOT delete business content.

When persistent behavioral inference is used, the user MUST be able to learn what category of information is used and for what purpose, and MUST be given an entry to stop using it and to clear the personalization basis within that scope; the result of clearing MUST be reported accurately, and stopping future use MUST NOT be described as having deleted all historical records. Feedback that only informs a recommendation and a control that immediately changes the view MUST state their scope and timing separately; "feedback received" MUST NOT be used to impersonate "the setting has taken effect."

Acceptance evidence: user side — the user understands the scope of a choice and can clear the personalization basis; implementation side — scope conflicts, persistence, and clearing receipts are verifiable.

Paired counterexamples: Under-delivery — a temporary expansion becomes a permanent preference; over-delivery — changing one setting clears all business content.

Verification examplesCheck whether preference behavior after a refresh, re-login, or switching object and workspace matches the specification. Also test five crossing scenarios and confirm each has a unique expected result with an understandable explanation: the same object in two views, two objects in the same view, an object preference conflicting with a view-type preference, modifying account settings during a temporary override, and returning after exiting a temporary session.

Reference: R08 supplies the dimension of preference duration; R15 supports explaining feedback's purpose and expected effect. Scope precedence and the clearing contract are this project's own design.

A4-3Noticeable adaptation can be reverted or restoredMUST

Applies tothe system automatically reordering, collapsing, or switching a view the user is already using.

RuleA path to restore the previous or standard presentation MUST be provided; restoring MUST use the currently valid permissions and data, and MUST NOT revive content that has since become invalid. After a user reverts a class of adaptation, that change MUST NOT be immediately repeated automatically within its declared scope.

Acceptance evidence: user side — the same kind of change does not immediately recur after restoring the presentation; implementation side — restoring uses current data, and the suppression scope is enforced.

Paired counterexamples: Under-delivery — restoring the old interface also restores old permissions; over-delivery — reverting once permanently disables all adaptation.

Verification examplesAfter reverting automatic condensation, the same signal no longer causes collapsing next time; restoring the display does not replace the current failure state with a historical success state.

A4-4Automatic adaptation can be turned offMUST

Applies toproducts that provide personalized, predictive information adaptation.

RuleThe product MUST allow turning off predictive presentation adjustment within that scope, and a usable standard interface MUST remain after doing so. Normal business-state refresh, permission changes, and necessary-exception display continue to take effect. Entries for turning off, restoring, and pinning SHOULD be organized around user understanding, without requiring the user to know algorithm names or configure every internal field.

Acceptance evidence: user side — the task can still be completed after turning off prediction; implementation side — the prediction toggle does not block fact, exception, and permission updates.

Paired counterexamples: Under-delivery — the toggle exists but prediction keeps changing the order; over-delivery — turning off prediction also disables business refresh.

Verification examplesAfter turning off predictive adaptation, the task can still be completed and exceptions remain visible; the user is not required to turn off dozens of component switches one by one.

Reference: R06.

A5 Presentation stays understandable

A5-1Explain the reason for a noticeable changeSHOULD

Applies toautomatic changes that noticeably affect the user's understanding of current information.

RuleThe change SHOULD be explained with an understandable, factually grounded reason, such as "execution failed; recovery actions have been expanded." Ordinary numeric refreshes need no repeated explanation; minor changes such as fades or spacing need no popup. Personalized reasons MUST NOT be fabricated, nor MUST a model score with no explanatory value be exposed to the user. When adopting the explanation approach recommended by this rule, its policy MUST be defined in configuration; when deviating from it, citing the rationale, the alternative, and the verification record suffices — it is not judged a failure merely because the configuration enum lacks a matching entry — but "reasons MUST NOT be fabricated" is a hard constraint that this deviation does not lift.

Acceptance evidence: user side — the user understands a noticeable change without being bombarded by prompts; implementation side — the explanation comes from an actual matched basis.

Paired counterexamples: Under-delivery — a fabricated "because you like this style"; over-delivery — a popup explains every single numeric change.

Verification examplesThe user can state why an error's detail appeared; routine updates do not produce continuous prompts or announcements.

A5-2Displayed scope and business state are expressed separatelyMUST

Applies tosummary, filtered, aggregated, recommended, or partially loaded views.

Rule"Only part is shown" MUST be distinguished from "this is all there is," "collapsed" from "processing complete," and "unknown" from "no exceptions." An explanation of a simplified display scope MUST sit close to the corresponding content; when a count cannot be determined, use an honest, inexact description. Using the view's presentation state as a stand-in for business state is forbidden.

Acceptance evidence: user side — the user can tell apart partial display, unknown, and processing complete; implementation side — loaded count, filtered count, and total are provided separately.

Paired counterexamples: Under-delivery — a failed load is labeled zero results; over-delivery — the full scope statement is repeated for every single record.

Verification examplesAfter collapsing ten task records, the user does not mistakenly believe the records were deleted or the task is complete.

A5-3Every tier remains accessibleMUST

Applies toany information-adaptive component.

RuleEvery tier MUST retain the needed semantic structure, accessible name, keyboard operation, and readability. Expanded state SHOULD be expressed programmatically — in Web components where an accessibility standard applies, the programmatic determinability of name, role, and state is judged by that standard; this rule's "SHOULD" does not lower its strength, nor may it be used as grounds to bypass it; applicable status messages MUST be perceivable by assistive technology, while avoiding frequent, meaningless announcements. Information MUST NOT be condensed by shrinking text, lowering contrast, or relying on color alone. A user's accessibility settings, such as reduced motion, MUST continue to take effect.

Acceptance evidence: user side — each tier can be used to complete the task with a keyboard and assistive technology; implementation side — semantics, focus, state, and user settings all take effect.

Paired counterexamples: Under-delivery — condensing relies on color or small text alone; over-delivery — every refresh is set as an interrupting announcement.

Verification examplesComplete the same task using a keyboard, a screen reader, a large font size, and reduced-motion settings; when switching language, using long labels, or reading right-to-left, the summary still retains units, negation words, and qualifiers, and the expand control remains operable.

Reference: R10, R11. Full accessibility conformance is still verified against the standard the product has adopted.

A5-4The mode of expression allows task-based correctionSHOULD

Applies tothe system choosing a chart, text, table, or level of explanation.

RuleThe user SHOULD be allowed to choose a supported alternative expression suited to the task, while the same data range is preserved. Familiarity with information and proficiency with operation are considered separately; help MUST NOT be permanently removed just because someone uses the product often. A switching entry SHOULD be named after the user's goal, such as "view as data table," rather than requiring the user to choose an internal renderer.

Acceptance evidence: user side — the user can switch to an expression suited to verification; implementation side — the object, range, units, and selection are not lost after switching.

Paired counterexamples: Under-delivery — switching from a chart to a table silently resets the filter; over-delivery — dozens of internal rendering options are exposed.

Verification examplesA proficient user can get an explanation when handling an unfamiliar metric; after switching a chart to a table, the filter conditions and object selection are retained.

Reference: R01, R08.

A6 Effect is verifiable

A6-1Compare against a stable baselineMUST

Applies tointroducing or expanding an information-adaptation capability.

RuleTask success criteria MUST be defined and compared against an available standard presentation. When comparing a fixed baseline, a user's manual choice, and automatic adaptation, the task, population, and reading conditions MUST remain comparable, and understanding, error, recovery, and change burden are recorded separately. Evaluation MUST cover at least task correctness, necessary-information omission, and search cost; automatic change MUST also cover misoperation and recovery cost. Not-exposed, failed-to-load, and shown-but-not-clicked are counted separately; hidden ratio, click-through rate, and dwell time MUST NOT serve alone as evidence of adaptation success. Evaluation MUST cover first-time use, familiar use, and assistive-technology use, and report results for applicable populations separately; an overall average benefit MUST NOT mask a critical omission for a specific population. When using historical feedback to tune ordering, feedback bias caused by exposure changes MUST be checked, and a stable arrival path for the full content MUST be preserved.

Acceptance evidence: user side — task outcomes improve and search burden is acceptable; implementation side — benefit and cost against the baseline are recorded per task and per population.

Paired counterexamples: Under-delivery — a rise in click-through rate stands in for correctness; over-delivery — all content is spread out to chase zero expansions.

Verification examplesObserve outcomes for browsing, comparing, executing, and troubleshooting separately; a short-term speed gain must not mask an increase in critical omissions.

Reference: R07, R08 provide research leads on accuracy, predictability, and customization complexity.

A6-2Exceptions and interaction combinations enter acceptance testingMUST

Applies toevery component with automatic adaptation enabled.

RuleAcceptance testing MUST cover missing signals, stale signals, conflicting signals, fluctuating signals, content exceeding budget, permission changes, and changes occurring during reading and input. Combinations of detail level, density, task phase, and accessibility settings MUST be checked; a risk-driven combination coverage MAY be used, and an exhaustive, meaningless Cartesian product is not required.

Acceptance evidence: user side — the task can still continue under a combination of exceptions; implementation side — real capability combinations are covered, with reasons recorded for what does not apply.

Paired counterexamples: Under-delivery — only three static visual mockups are accepted; over-delivery — exhausting meaningless combinations delays an actual fix.

Verification examplesRecord pass, fail, not-applicable, and the reason for each component per Appendix B.

A6-3A usable interface remains when resolution failsMUST

Applies topresentations that depend on policy, tokens, a remote model, or a content-conversion service.

RuleA standard form that works without any predictive service MUST be provided. When policy and token do not match, content conversion fails, or the remote service is unavailable, the fallback MUST NOT lose business content or user input. A user's pinned preference continues to be honored while still legal and compatible; when incompatible, only the affected part falls back, with a necessary explanation given.

Acceptance evidence: user side — the user can still read and operate after a service failure; implementation side — a partial failure falls back while retaining input, permissions, and legal preferences.

Paired counterexamples: Under-delivery — a resolution failure hides the entire component; over-delivery — one bad optional value resets the whole page.

Verification examplesLaunch the page with an unknown mode, a missing token, a model timeout, and an unrecognizable configuration, and confirm the core task can still be completed.

A6-4Decisions are traceable, and tuning does not relax the baselineMUST

Applies toproduction operation, experiments, and configuration iteration.

RuleAn adaptation decision MUST be traceable to the applicable rule that fired, the input category, the chosen presentation, and the reason for any fallback; the minimum necessary scope is recorded, and complete personal content is not stored by default. Configuration experiments MUST NOT bypass necessary information, permissions, or input protection. Rollback conditions MUST be defined before launch, so that a problematic policy can be disabled once a critical omission or misoperation is discovered.

Acceptance evidence: user side — the standard view becomes available once a problematic policy is stopped; implementation side — a minimal decision record can locate the rule and verify that it was disabled.

Paired counterexamples: Under-delivery — extensive logs exist but cannot pinpoint the cause; over-delivery — all personal content is stored for the sake of traceability.

Verification examplesFrom one erroneous collapse, locate the rule that fired and its input basis, without reconstructing a user's entire behavioral history; after disabling that rule, the standard presentation is restored.

4. Information units and state modeling

4.1 Minimal design description per information unit

Item	Question design must answer
Semantics and identity	What object is this? Which task needs it?
Necessary content	Which fields, consequences, and exceptions must not be dropped by an ordinary display budget?
Form	What does summary, standard, and detailed each contain? How does an unsupported form fall back?
Context	Which task states or signals can trigger a change? What is the validity period?
Boundary	Which regions may change? When do they update? What happens during an ongoing operation?
Control	What can the user expand, pin, and restore? What is the scope and duration of effect?
Data state	How are loading, empty, failed, stale, and partial success expressed?
Fallback	How is the task still completed when input, service, or configuration fails?

These descriptions can live in component documentation, a state diagram, or a code contract; a separate form does not need to be created for each.

4.2 State axes maintained separately

Axis	Examples	Must not be conflated
Task phase	Browse / Compare / Execute / Check	Executing does not automatically mean the detailed mode
Information detail level	`summary` / `standard` / `detailed`	Summary does not mean the data is incomplete or errors can be hidden
Visual density	`comfortable` / `compact`	Compact does not mean the user is proficient
Business state	Pending / In progress / Succeeded / Failed / Unknown	Collapsed does not mean complete
Content state	Loading / Complete / Partial / Stale / Unavailable	Failing to load does not mean there is no content
Control state	Automatic / User-pinned / Predictive adaptation off	A pinned display does not mean data refresh has stopped

State axes may jointly affect one component, but there must be an explicit combination rule. For example, "execution failed + summary + user-pinned" must still show the necessary exception, while other explanations remain at the summary level.

4.3 Lifecycle of an adaptation decision

Stage	Entry condition	Exit and user feedback
Candidate	Valid context obtained, matches a decision rule	The interface has not changed; nothing is claimed to have been applied
Pending	The candidate affects a region currently being operated on or read	The current presentation is retained; "update available" is shown when needed, allowing the user to apply it proactively
Applied	The object, input snapshot, permissions, and explicit choice are re-verified as still valid	The affected region updates atomically; input, logical focus, and necessary information are preserved
Discarded	Superseded by a new decision, the object changed, or the basis became invalid	Not replayed; if adaptation is still needed, a new decision is made from the current facts
User-restored	The user reverts or reselects	The presentation is restored, reading the currently valid facts, suppressing repeated adaptation within the declared scope
Fallback	Configuration or service is unavailable	A usable standard form takes over; preferences that can still be honored are retained

A stage is an operational fact, not a business task state, nor a shared token. A "pinned" acknowledgment in the interface SHOULD correspond to the pin actually taking effect; if saving fails, the temporary choice is retained and the lack of persistence is stated.

4.4 End-to-end case: a troubleshooting task board

A user enters the board to browse tasks, with the standard presentation by default. Necessary content is identity, status, pending items, and exception impact; the ordinary preview count limits only auxiliary records.
The user starts comparing two tasks and explicitly selects comparison fields. Historical browsing preferences cannot hide comparison fields; the two tasks use the same data basis.
A prediction suggests collapsing a record while the user is typing Chinese input. The candidate waits, and the input and button positions are retained; if the task fails, the exception region updates immediately, but the target being pressed is not moved.
The user selects "always show details for this view." The pending collapse candidate is invalidated; a later-arriving prediction must also defer to this choice. The interface states the pinned scope, and normal progress continues to refresh.
The user pauses reading, and the page marks the data's timestamp. The backend keeps receiving facts, a revoked permission immediately hides the restricted field, and a necessary exception is expressed through a fixed region. On resuming, the current data is read, without replaying every backlog change one by one.
The user clears the view preference and turns off predictive adaptation. The standard presentation takes over; content and business state are not rolled back; a predictive-service failure also does not hinder troubleshooting.

The above process is an implementation example; acceptance testing also observes whether the operation was protected and whether the user was burdened with too many toggles and prompts.

Appendix A: Component examples at the same width

The following are design examples, not a universal standard for business fields.

Component and scenario	Default information	On-demand information	Key constraint
Task card: browsing	Name, status, owner, next step	Steps and records	Keep identity and the primary action in place
Task card: executing	Current step, progress, items pending user action	Input, output, and step record	No reordering while the user is providing input
Task card: failed	Failure location, impact, recovery action	Log and detailed reason	Exceptions are not subject to the ordinary preview cap
Result list: browsing	Primary result, task-relevant summary	Secondary fields	The recommendation region does not replace the full list
Result list: comparing	Comparison fields on the same basis	Supplementary explanation	Selected objects are not lost, and comparison basis does not vary per object
Detail panel: checking	Original value, input/output, basis, and time	History	Switching detail level retains the object, permissions, and data timestamp

Appendix B: Acceptance checklist

Scenario	Passing condition	Corresponding rule
First entry, no user history	The task can be completed in the standard presentation, with no speculative default omissions	A1-2, A1-3, A6-3
Inference conflicts with the user's explicit choice	The legal explicit choice takes effect	A1-2, A4-2
Necessary exceptions exceed the budget	Accurately aggregated or expanded presentation, not silently cut	A2-1, A5-2
A continuous signal keeps fluctuating	The view stays stable, and necessary business updates are not deferred indefinitely	A3-3
An update occurs during Chinese input, dragging, or bulk selection	Input, target, and selection are retained, with no accidental operation	A3-1
Content is expanded, collapsed, or inserted	The reading anchor and logical focus can continue	A3-4
The user reverts, pins, or turns off automatic adaptation	The scope of effect is clear, and the same adaptation does not immediately recur	A4-1～A4-4
An old view is restored after a permission revocation	Restricted content is not restored	A1-4, A4-3
An error, partial result, or stale data is converted to a summary	Key qualifiers are retained, and the original basis is accessible	A2-4
Keyboard, screen reader, large font, reduced motion	Every tier can complete the task	A5-3
Missing token, service timeout, stale configuration	The affected region falls back, and the core task can still be completed	A6-3
Comparison against the standard presentation	Task outcome, omission, search, and recovery cost are reported	A6-1
A non-predictive automatic-refresh region	Reading can be paused; moving focus away does not force a resume; a revoked permission during the pause still hides the restricted field; the current data is shown on resume; the essential-exception rationale is recorded separately	A4-1, A3-2
Out-of-order arrival of delayed adaptations	An earlier, stale result does not override a later, valid decision; the stale result does not return after a permission revocation or object switch during the wait	A3-3, A4-3
Object and view-type preferences cross	Each of the five crossing scenarios has a unique expected result; when nothing changes, the user is told why and can cancel the override	A4-2
An overlay omits the line-count field	The inherited line count is still honored; only an explicit unbounded-line policy lifts the limit	A2-2
Four capability tiers (standard view only / static disclosure / automatic detail level / automatic ordering)	Every tier can obtain a complete, legal minimal configuration; a field with no corresponding capability is recorded as not applicable	A4-1～A4-4, A6-3

Appendix C: Evidence and items pending verification

Source facts, verification scope, and maturity are given in reference.md. These guidelines have not undergone product testing, user experiments, or a systematic literature review.

What needs to be verified within a project: the division of necessary content, the field range of each mode, how well users understand the control entries, the frequency and stability conditions of adaptation, the specific information budget, and the search and learning cost after long-term use. All example values and field names should be treated as testable design proposals.

Appendix D: Acceptance records and measurement basis

Every acceptance record includes: the rule and applicable capability, input condition, triggering event, expected presentation, prohibited behavior, user-side evidence, implementation-side evidence, result, and unresolved issues. The result is pass / fail / not applicable; not applicable is accompanied by a reason. Documentation review passing, mechanism testing passing, and user comprehension passing are recorded separately and do not substitute for one another.

Metric	Measurement basis	Purpose of the judgment
Task correctness	Correctly completed tasks / valid task attempts, reporting sample size and task difficulty	Compared against the standard presentation; speed does not mask errors
Critical omission	Number of events where a user lacked necessary information while deciding, listing the impact of each	Permission leaks, necessary-information omissions, lost input, and accidental activation are not offset by an averaged benefit
Search cost	Time and failure count from a given goal to locating the needed information	Reported separately for first-time and familiar use; time may be reported as median and high percentile
Recovery cost	Time, steps, and failure count from discovering a bad adaptation to restoring a usable presentation	Tests whether the recovery entry and its scope are understandable
Control comprehension	Number of people who correctly predict the behavior of pinning, pausing, and turning off, / number tested	Have users operate and explain their expectation first; do not substitute reading a description
Repeat interference	Number of times the same class of adaptation recurs within the suppression scope after being reverted	Checks for suppression failures, not for suppressing reasonable user corrections

Numeric targets are set before testing, based on the task's consequences and the target population, without using a generic "percentage improvement." Total task time, together with the extra cost of setup, checking, and recovery, should be observed together, covering both first attempts and repeated use. Finding no problem within a sample does not prove reliability across all use scenarios.

Implementation acceptance scenarios

The following scenarios turn existing clauses into reviewable acceptance inputs, without setting an additional generic performance threshold. Select by the product's applicable capability, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an untested item MUST NOT be recorded as passed.

Clause	Test input and exception	Expected behavior and failure criterion
A1-2	An item never enters the viewport, and the model then suggests hiding it.	Non-exposure is not interpreted as disinterest; a discoverable path is retained.
A4-1	After the user pins detailed information, a historical preference suggests the summary.	The current, valid, explicit choice takes precedence, and necessary content is not removed by the preview budget.
A6-3	A new configuration reference for some region becomes invalid.	That region falls back to a legal baseline, while other regions and task state are preserved.

Each scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as either success or failure.

Express information-presentation decisions with reusable fields, so design, components, and runtime policy share the same definitions of "what to show, how much to show, and when it changes."

Companion to Adaptive Information Design Guidelines. Fields use the aui.* prefix; for sources and evidence boundaries see reference.md.

This file records both presentation tokens and the behavior vocabulary that works alongside them, but draws a clear exchange boundary: visual values and numeric parameters may use DTCG-supported types; content semantics, conditions, enums, and adaptation policy use the product's own schema. This dictionary is not a complete file that can be imported directly into a design tool, nor does it claim every field is a standard design token.

1. Three parts and the boundary with runtime data

Part	Responsibility	Field range	Exchange and implementation
Presentation tokens	Shared values for typography, spacing, color, motion, etc.	`aui.visual.*`	References the existing visual system; applicable values can map to DTCG types
Information presentation parameters	Default count, summary line count, number of auxiliary fields	`aui.presentation.*`	Numeric values can be expressed as `number`, but business meaning, integer ranges, and exceptions need their own validation
Adaptation policy	Mode, trigger, stability condition, user control, and fallback	`aui.context.`, `aui.content.`, `aui.adaptation.`, `aui.control.`, `aui.fallback.*`	Product-level behavior configuration; not a DTCG standard enum or condition type
Content metadata and runtime state	The fields, exceptions, input snapshot, user choice, and current focus of an object	Not a shared token	Provided by the business model and the component's runtime model

"The standard mode previews five items" is a reusable parameter; "task 123 is currently failed" is business state; "show a recovery entry when a failure occurs" is an adaptation rule. A format being able to store a value does not mean a token tool understands its business meaning.

1.1 Resolution order

Restrict visible scope: determine accessible content based on current permissions and privacy requirements.
Determine necessary content: within the allowed scope, determine the required fields, exceptions, and action explanations for the current task and its consequences.
Apply explicit choices: within hard constraints, apply the current selection, applicable saved preferences, and pinned settings.
Select the adaptation form: use valid task rules, context cleared for use, and inference; fall back to the standard form when there is no reliable basis.
Resolve presentation values: resolve tokens and information parameters according to the selected mode, density, accessibility needs, and component contract.
Schedule the actual update: present after passing interaction-protection and stability-condition checks; fall back the affected region on validation failure.

Internal priority of explicit choices: the current temporary choice takes precedence over a persistent preference; within the same scope, the most recent explicit choice governs. Among persistent preferences, object and view_type can cross without nesting, and "more specific takes precedence" is not sufficient to decide between them — the product MUST declare a single deterministic order here, for example:

view_session > object > view_type > workspace > account > product

A product that supports an "object × view" combined scope MUST state explicitly that this combination is more specific than either object or view_type alone. Every preference MUST bind a subject, target dimension, scope identifier, and target object; a temporary override is scoped to the current viewing session. Modifying a broader scope only updates that layer; when a more specific override exists, the product MUST explain to the user why the current view has not changed and provide an entry to cancel the override. Concurrent modifications within the same layer are resolved by server-side event order or a declared deterministic conflict rule, not by local clocks across multiple devices alone. A product need only enable the scopes it actually supports, but the order among the scopes it does enable MUST be fully resolvable. Users cannot use these choices to relax permissions or omit necessary information for the current decision.

Business updates and predictive adaptation are toggled separately. Turning off personalization or pinning a presentation does not stop updates to task progress, failure state, or permission changes.

1.2 Required, conditionally required, and optional

Level	Meaning
Required	A decision that must be resolvable when this system is enabled; may inherit a product preset
Conditionally required	Must be defined once the corresponding capability is enabled; not required when that capability is not enabled
Optional	Introduced only when an actual component needs it; not forced just to fill out the dictionary

Fields in all tables are given by their full names. Rule numbers correspond to the relevant clauses in the Design Guidelines; a field does not cover the full scope of applicability stated in the rule's own text.

1.3 Decision authority, inheritance, and taking effect

Configuration source	Decisions it is responsible for	Timing and feedback
Product preset	Supported capability, standard form, information parameters, and stability rules	Takes effect on first entry or at a safe update boundary; does not override an explicit choice
Content contract	Necessary fields for the current task, conversion semantics, and access path	Re-evaluated whenever data or task changes
User display choice	Mode, fields, order, and representation	Applied as soon as possible; when interaction protection applies, wait explicitly, and on a save failure distinguish temporary effect from persistent save
System accessibility preference	Reduced motion, font, and other presentation needs	Re-resolved whenever the relevant preference changes; does not change business meaning
Runtime decision	Which rule matched, whether a candidate can be applied	Re-checked before actual application; a stale candidate is discarded, not published as shared configuration

Hard constraints filter legal values first; the selection order only decides conflicts among already-legal values. An override within the same layer MUST declare its order; a set is replaced wholesale by default and is not implicitly unioned; a field's absence means continued inheritance, an empty set means empty only where the field explicitly allows it, and null does not serve as a delete instruction. A duplicate definition with no declared tiebreaker, a reference cycle, a dangling reference, a type mismatch, or an unknown enum are all resolution errors, and are not silently guessed at.

Every product preset records: the decision-maker / responsible role, the rationale for adoption, the applicable component and task, the source of the value, the triggering event, required dependencies, validation evidence, and fallback. Prototype values are not industry thresholds; a value must not be copied on its own while omitting these conditions.

2. Presentation tokens: how each form is displayed

This group of fields references the product's existing visual tokens through mapping, rather than inventing a separate set of brand colors and font sizes. A reference MUST be locatable to its source and definition; the names below are a proposed semantic interface.

Level	Design decision	Field	Type and value	Purpose and rule
Required	Visual source	`aui.visual.sourceRef`	Reference into the product's token set, including a set identifier	Resolved at implementation time; this metadata MUST NOT be declared as a generic DTCG string token; A6-3
Conditionally required	Inter-group spacing	`aui.visual.groupGap`	`dimension`, non-negative, exchanged in `px` / `rem`; references an existing spacing value	Used by components with multiple information groups; resolved separately from detail level and density; A2-2
Conditionally required	Primary-information typography	`aui.visual.primaryTypography`	`typography` or an alias of an equivalent type	Used by text-information components; identity and primary state stay readable; A2-1, A5-3
Conditionally required	Secondary-information typography	`aui.visual.secondaryTypography`	`typography` or an alias of an equivalent type	Defined when auxiliary information exists; condensation is not implemented through an overly small font size; A5-3
Conditionally required	Secondary-information color	`aui.visual.secondaryColor`	`color` or an alias of an equivalent type	Defined when secondary information has a distinct color; target readability MUST still be met; A5-3
Conditionally required	Disclosure transition duration	`aui.visual.disclosureDuration`	`duration`, non-negative, exchanged in `ms` / `s`	Defined when an expand animation is used; a reduced-motion mode MUST have a resolvable value, which may be 0; A3-4, A5-3

Visual tokens do not decide which content can be collapsed. The state color used for a necessary error continues to use the existing state semantics; this system does not map "important" to red by default.

3. Information presentation parameters: how much is shown by default

Level	Design decision	Field	Type and legal values	Purpose and rule
Optional	Preview item count	`aui.presentation.previewItemCount`	Positive integer; DTCG may use `number`, with the integer constraint validated separately	Constrains only omittable preview items; necessary regions are outside the budget; A2-1, A2-3
Conditionally required	Summary line-count policy	`aui.presentation.summaryLinePolicy`	`bounded` / `unbounded`	Defined when a summary form is used. With `bounded`, `summaryMaxLines` MUST be a positive integer; with `unbounded`, the component applies no line limit, and an inherited numeric value does not take effect. When a mode does not define this policy, it may only inherit a policy with a stated source, not be judged by "field missing"; A2-2
Optional	Summary line count	`aui.presentation.summaryMaxLines`	Positive integer. "Unset" means the parameter is absent from the final effective configuration, not that a particular override layer lacks the field	Used only for a summary that already preserves key meaning; the original text MUST NOT be mechanically truncated and passed off as a semantic summary; A2-2, A2-4
Optional	Default auxiliary field count	`aui.presentation.metadataVisibleCount`	Non-negative integer	0 means optional auxiliary fields are not shown by default, without hiding identity and task-required fields; A2-1
Optional	Default expanded group count	`aui.presentation.expandedGroupCount`	Non-negative integer	Applies to groups that allow collapsing; necessary groups and user-pinned groups are outside the ordinary budget; A2-1, A4-1

These parameters are not the actual total. When there are actually two items, only two are shown — they are not padded to five; when there are actually more items but loading fails, this MUST NOT be used to claim "there are only two."

3.1 Mode preset examples

The following values are for prototype discussion only; they carry no universal cognitive threshold or literature-validated meaning. A product should first define the field range for each mode and only then validate the counts; the detailed mode may still paginate and does not promise loading all content at once.

Parameter	`summary`	`standard`	`detailed`
`previewItemCount`	3	5	10
`summaryLinePolicy` (product config)	`bounded`	`bounded`	`unbounded`
`summaryMaxLines`	2	4	does not consume an inherited value
`metadataVisibleCount`	1	3	6

A component may not use every one of these parameters. Omitting an override value does not delete an inherited value — if the base set already has 4 lines, a detailed mode that does not declare the same-named field still resolves to 4 lines, not to unbounded. When a mode genuinely needs no line limit, declare summaryLinePolicy = unbounded explicitly, and the component does not consume an inherited summaryMaxLines. Every summary form MUST be able to resolve this policy; a missing policy is treated as a configuration error. Under no circumstance is a negative number, the string unlimited, or 0 used to substitute for positive-integer semantics. When bounded but summaryMaxLines is missing, 0, or negative, treat it as a configuration error and fall back the affected part locally. Validation MUST compare the final effective configuration, not just the override file.

4. Context policy: what a form is chosen based on

The following fields belong to the product's own schema, not DTCG token types.

Level	Design decision	Field	Type and legal values	Applicable condition and purpose
Required	Supported detail modes	`aui.context.supportedModes`	Non-empty set drawn from `summary`, `standard`, `detailed`, and MUST include `standard`	A mode the component has not implemented MUST NOT enter the selectable range; A2-2, A6-3
Required	Baseline form	`aui.context.defaultMode`	Fixed at `standard`	The product baseline when uncertain; does not override an explicit preference that is still valid; A1-3
Required	Signal allowlist	`aui.context.allowedSignals`	Reference set of signal definitions; may be empty	Defines the source, scope, category (fact / preference / inference), and legal use range; A1-2, A1-4
Conditionally required	Signal validity condition	`aui.context.signalValidityRef`	Rule reference	Defined when using a signal that can become stale, covering time-to-live, event validity, and conflict resolution; not all signals need the same TTL; A1-3
Conditionally required	Mode decision table	`aui.context.modeRulesRef`	Ordered rule-table reference, including applicable task, signal, target mode, and conflict handling	Required when automatic mode selection is enabled; the result MUST belong to the component's supported set; A1-1～A1-3
Conditionally required	Unknown-signal policy	`aui.context.onUnknown`	`standard` / `retain_valid`	Defined when using automatic selection; `retain_valid` retains only the current presentation that is still legal and applicable, otherwise falling back to standard; A1-3

The current task ID, model score, reading position, and similar are runtime inputs; they are not written into shared presets. If a new predictive threshold is introduced, its unit, calibration basis, and consequence boundary should be defined within the signal rule, rather than adopting a globally uniform "80% means adapt."

5. Content contract: what each mode contains

Level	Design decision	Field	Type and legal values	Applicable condition and purpose
Required	Content definition source	`aui.content.contractRef`	Reference to the component's content schema	Defines object identity, fields, necessity conditions, data state, and supported forms; A2-1, A2-2
Required	Necessary-content overflow	`aui.content.onEssentialOverflow`	`grow` / `aggregate_with_access` / `dedicated_view`	Expand the container, accurately aggregate with access provided, or route to a dedicated detail view; no value may silently drop consequences or necessary action information; A2-1
Conditionally required	Full-content path	`aui.content.fullAccessRef`	Reference to a definition of the user-accessible path	Required when omission occurs; resolved against current permissions, not an object URL inside the shared token; A2-3, A1-4
Conditionally required	Representation-conversion contract	`aui.content.representationRulesRef`	Conversion-rule reference	Defined when switching between table, chart, text, or summary: preserved fields, an entry to the original value, input consistency, and conversion-failure fallback; A2-4

dedicated_view means the current region retains a necessary summary and routes to a page that can fully present the content; any related confirmation action MUST occur only after the user has the necessary information. It does not allow an exception to be moved away entirely while a confirmation with no supporting basis remains in place.

The responsibility of content metadata is illustrated below; this is not a token file:

{
  "component": "task-card",
  "identityFields": ["title", "status"],
  "essentialWhen": [
    { "state": "failed", "fields": ["failureImpact", "recoveryActions"] }
  ],
  "optionalFieldsByMode": {
    "summary": ["nextStep"],
    "standard": ["nextStep", "owner", "currentStep"],
    "detailed": ["nextStep", "owner", "currentStep", "inputs", "outputs", "history"]
  }
}

The final visible field set is made up jointly of identity fields, currently necessary fields, the current mode's optional fields, and legally pinned user fields. The information budget applies only to the part that can be omitted.

6. Change policy: when updates are allowed

Level	Design decision	Field	Type and legal values	Applicable condition and purpose
Conditionally required	Update boundary	`aui.adaptation.updateBoundary`	`view_entry` / `task_boundary` / `interaction_end` / `live`	Defined when an automatic change occurs; `live` is still subject to target and input protection. Every value MUST state its specific triggering event explicitly in the consuming contract (e.g., `interaction_end` corresponding to the end of IME composition, the end of a drag, the end of a selection, etc.), the condition for canceling a queued update, and the disposition when that event never occurs, to prevent a necessary update from waiting indefinitely; no product-wide generic millisecond value is prescribed. A pending decision MUST, before it is actually applied, re-verify that the object, content snapshot, permissions, explicit choice, and policy are still valid; a decision superseded by a later one MUST NOT be applied; A3-1, A3-3
Conditionally required	Mutable region	`aui.adaptation.mutableRegions`	Set of stable region identifiers	Automatic updates act only on defined regions; an empty set means no automatic presentation change; A1-1, A3-2
Conditionally required	Reordering policy	`aui.adaptation.reorderPolicy`	`fixed` / `fixed_recommendation_region` / `stable_at_boundary` / `live_ranked`	Defined when using ordering adaptation; a user's explicit ordering takes precedence, and dynamic ranking MUST have a reading path; A3-2
Conditionally required	Fluctuation-suppression rule	`aui.adaptation.stabilityRuleRef`	Rule reference	Required when driven by a continuous signal; defines the stability condition, merging, hysteresis or cooldown, and exceptions; A3-3
Conditionally required	Tie-break rule	`aui.adaptation.tieBreakRef`	Stable-ordering rule reference	Required when using automatic ordering, to avoid random position swaps for equal scores; A3-2
Conditionally required	Update explanation	`aui.adaptation.explanationPolicy`	`on_material_change` / `persistent_context` / `custom` (references a product-defined custom explanation policy, together with its rationale, alternative, and verification record)	Defined when an automatic change noticeably affects understanding; presented on an actual basis, not a popup every time. The enum lacking a matching entry does not itself constitute an A5-1 deviation failure; record it with `custom`; "personalized reasons MUST NOT be fabricated" is not lifted by this; A5-1
Conditionally required	Reading control	`aui.adaptation.readingControlRef`	Reference to the product's reading-control contract	Required whenever a region has automatic updates and needs to be read, regardless of whether prediction is involved — a dashboard that only refreshes a metric applies equally. The contract includes the scope of presentation affected by the pause, a data-timestamp indicator, a resume policy, and the events that MUST still take effect during the pause (permission revocation, necessary exceptions). It may reference an existing product control component; a new button is not required. "This user is currently paused" is runtime state and is not written into this field; A4-1, A3-2

Interaction protection is not a togglable boolean field. Preserving IME composition input, presses, drags, selection, and focus is a baseline of these guidelines and cannot be written as protectInput: false in an experimental preset.

Animation duration and adaptation cooldown are also not the same parameter: the former decides how a transition is shown, the latter decides whether another presentation decision may be made again. Both can be expressed as a duration, but their semantics and where they are validated differ.

7. User control: how choices persist

Level	Design decision	Field	Type and legal values	Applicable condition and purpose
Conditionally required	Pinnable dimensions	`aui.control.pinnableDimensions`	Non-empty set drawn from `mode`, `fields`, `order`, `representation`	Required whenever the product automatically changes the presentation of a dimension, and MUST cover every dimension that actually changes; when the capability does not exist, do not configure this field and record "not applicable" with a reason. "No such capability" and "capable but missing configuration" are two different states — the former is legal, the latter is a configuration error; A4-1
Conditionally required	Supported scopes	`aui.control.preferenceScopes`	Non-empty set drawn from `view_session`, `object`, `view_type`, `workspace`, `account`	Defined when supporting a user display choice's duration; does not default to synchronizing across all objects; A4-2
Conditionally required	Control entries	`aui.control.controlsRef`	Reference to a definition of user-interface entries	Defined when omission or adaptation control exists; references only controls actually applicable: among expand / full content, pin, restore, and turn off predictive adaptation, only those the product actually has the capability for. Organize by capability combination; four separate buttons are not required, and this field must not be used to derive that all four entries must exist. A product with a static information budget still MUST meet A2's requirements for necessary information and a full-content entry; A4-1～A4-4
Conditionally required	Preference resolution	`aui.control.preferenceResolutionRef`	Preference-resolution rule reference	Defined when multiple scopes or persistent saving is enabled, covering order, same-layer conflicts, taking effect, and save-failure handling; A4-2
Conditionally required	Personalization-data control	`aui.control.personalizationDataRef`	Reference to a data-use control contract	Defined when using persistent behavioral inference: category, purpose, retention scope, an entry to stop use and clear, and a receipt; a runtime instance is not part of the token; A1-4, A4-2
Conditionally required	Suppression after reverting adaptation	`aui.control.onRevert`	`suppress_in_scope` / `until_explicit_resume`	Defined when an automatic change can be reverted; the same class of change MUST NOT immediately recur after reverting; A4-3
Conditionally required	Handling an invalid preference	`aui.control.onPreferenceInvalid`	`fallback_affected_only`	When a field or mode referenced by a persistent preference is removed, only the affected part falls back; a permission change immediately restricts visible scope; A4-2, A6-3

pinnableDimensions defines what the product supports; which field a particular person pinned is a user-preference instance and should be stored in the preference record for the corresponding scope, not published into a token shared by all users.

Four capability tiers of a legal minimal configuration: standard view only, static disclosure, automatic detail level, automatic ordering — every tier MUST be able to obtain a complete, legal configuration; a field with no corresponding capability is recorded as not applicable — only "capability enabled but missing a dependency" is a configuration error.

8. Fallback: how it is displayed on failure

Level	Design decision	Field	Type and legal values	Applicable condition and purpose
Required	Compatible component contract	`aui.fallback.compatibilityRef`	Reference to component capability and type constraints	Configuration, component, content contract, and visual source MUST be jointly resolvable; A6-3
Required	Resolution-failure path	`aui.fallback.onResolutionError`	Fixed at `standard_affected_region`	Falls back the affected region to a usable standard form, retaining legal preferences, current data, and input; A6-3
Required	Standard-form implementation	`aui.fallback.standardViewRef`	Reference to an executable component / preset	Does not depend on a predictive service; covers data states such as loading, failed, empty, and stale; A6-3
Required	Decision-record scope	`aui.fallback.tracePolicyRef`	Minimized-record rule reference	Records the matched rule, signal category, presentation result, and fallback reason; complete personal content is not stored by default; A6-4

Fields in this section do not require all fallback code to live in a module literally named "fallback"; the prefix is only a dictionary organization convention.

9. Interfacing with DTCG

The DTCG Format supports design types such as number, duration, dimension, color, and typography; the signal allowlist, conditional rules, and custom enums in this dictionary are not standard token types of that format. The Resolver can resolve values according to context supplied by the caller, and is not responsible for sensing a task or deciding whether some information is important. Both are community-group specifications, not W3C formal standards.

Below is a partial numeric sample that can be expressed in DTCG format, not a complete implementation preset; the example's 150ms is only a prototype value:

{
  "aui": {
    "presentation": {
      "previewItemCount": { "$type": "number", "$value": 5 },
      "summaryMaxLines": { "$type": "number", "$value": 4 },
      "metadataVisibleCount": { "$type": "number", "$value": 3 }
    },
    "visual": {
      "disclosureDuration": {
        "$type": "duration",
        "$value": { "value": 150, "unit": "ms" }
      }
    }
  }
}

Modes can respectively generate summary.tokens.json, standard.tokens.json, and detailed.tokens.json, with the Resolver's context selecting the corresponding value. A caller may supply a string input such as {"detail":"standard","density":"comfortable","motion":"reduced"}, provided these modifiers and their legal values are declared in the Resolver. The file names and input above are organizational suggestions; a complete Resolver file has not been generated or validated in this instance.

To avoid combinatorial bloat, detail level should preferably affect information parameters, density should preferably affect layout values, and motion preference affects animation; where overlap exists, a deterministic resolution order must be defined. The Resolver's value-override order carries no authority to relax a behavioral constraint.

10. Dependencies and handling of missing configuration

Enabled capability	Must be defined together	Handling when missing
Automatic detail-level selection	Supported modes, content contract, valid signals, decision table, update boundary, control entries	Use the standard form; predictive adaptation does not start
Content omission	Necessary fields, overflow path, full-content entry, an honest scope statement	Retain standard content, or route to an already-defined full detail view
Automatic ordering	Stable path, tie-break rule, user ordering precedence, update boundary	Retain the current legal stable order
Continuous context adaptation	Signal validity condition, fluctuation suppression, interaction protection, necessary-update exception	Do not flip repeatedly based on an unstable signal
Generated summary or chart conversion	Data range, must-retain semantics, original-value entry, input snapshot, failure fallback	Use a template or the original content
Persistent preference	Supported scopes, a single deterministic order among the enabled scopes, restore entry, an entry to cancel a more specific override, invalidation handling	Do not persist silently; take effect only within an explainable temporary scope
A region with automatic updates that needs reading (including non-predictive refresh)	`aui.adaptation.readingControlRef`: pause scope, data-timestamp indicator, resume policy, events that must still take effect during the pause	Do not enable automatic refresh for that region; if already enabled, keep the current content at the standard form and accurately label the data timestamp
Summary form	`aui.presentation.summaryLinePolicy`; `summaryMaxLines` when `bounded`	Resolve via an inheritance policy with a stated source; provide no summary form when no policy is resolvable
Disclosure animation	Duration, logical focus, reduced-motion resolution	No animated update, while semantics and position are preserved

An unmet dependency does not mean sending an incorrect configuration directly to the component. A usable standard fallback MUST already exist; "hide the module when configuration is missing" is not a legal fallback.

10.1 Minimum content of a reference contract

A Ref is a resolvable definition entry, not a "to be filled in later." All of the following are product schemas; a design tool is not responsible for interpreting the business semantics.

Reference	Minimum definition	On missing or invalid
A signal definition within `allowedSignals`, and `signalValidityRef`	Source, category, applicable task, time obtained, validity condition, handling of unknown and conflict; a behavioral signal distinguishes exposure from not-clicked	Do not use that signal
`modeRulesRef`	Rule identifier, condition, target mode, match order, conflict resolution, no-match result	Retain the legal explicit choice, otherwise the standard form
`contractRef`, `representationRulesRef`	Identity, necessity condition, optional fields per mode, data range and timestamp, original-value entry, expression of empty / partial / failed	Use readable original content or a validated template
`stabilityRuleRef`	Entry and exit conditions, timing unit and starting point, merge scope, cancellation condition, necessary-update exception	Do not perform continuous automatic switching
`readingControlRef`	Pause region, data timestamp, resume trigger, how resuming reads data, events that still take effect	Turn off automatic refresh for that region, retaining the current data indicator and necessary exceptions
`preferenceResolutionRef`	Complete scope order, same-layer resolution, end of a temporary override, save-failure receipt, override-cancellation entry	Do not persist an ambiguous choice; a legal temporary choice continues to work
`personalizationDataRef`	Category and purpose of use, retention scope, scope of stopping and clearing, effect receipt, failure retry	Do not enable persistent behavioral inference
`tracePolicyRef`	Minimum fields, purpose, accessor, retention and cleanup condition	Do not start a predictive policy that cannot be debugged; the standard presentation continues to be usable

The tie-break rule, full-content entry, control entry, compatible capability, and standard-component reference must likewise point to an actually consumable definition; the accessed object's URL, personal preference, and focus position are supplied at runtime.

10.2 Legal minimal configuration per capability tier

Every tier defines a visual source, standard mode, content necessity, and an executable fallback. The table below lists only the increments; "not applicable" is written in the verification record and is not passed to an enum field as a string.

Capability tier	Legal configuration outline	Configuration not needed
Standard view only	`supportedModes=[standard]`, `defaultMode=standard`, `allowedSignals=[]`; no omission, no automatic change	Pinning, predictive off, preference scope, automatic boundary
Static disclosure	Full-content entry, expand control; if summary is supported, define the line-count policy; if choices are remembered, declare the scope	No mode decision table when there is no prediction
Automatic detail level	Supported modes, valid signals, decision table, change region and boundary, `pinnableDimensions=[mode]`, restore and predictive-off; a continuous signal additionally needs a stability rule	No tie-break rule when there is no ordering
Automatic ordering	Stable path, ordering rule and tie-break resolution, change region and boundary, `pinnableDimensions=[order]`, restore; reading refresh additionally needs reading control	Not required to provide three detail modes

Stacked capabilities require stacked dependencies. For example, when automatic detail level changes both fields and ordering at once, the pinnable dimensions MUST cover both; adding persistent behavioral inference adds data-use control, and a view-off toggle alone cannot substitute for it.

11. Validation and maintenance

When implementing, check the following invariants:

All modes belong to the component's supported set, and a standard form exists that does not depend on a predictive service.
Values satisfy this dictionary's integer and non-negative / positive constraints; duration and dimension carry units. Default and zero values MUST NOT be mixed. "Unset" is judged against the final effective configuration, not against a single override layer; lifting an inherited limit requires an explicit policy value, not omission.
Rule references, visual source, and component contract can be resolved to a jointly satisfied capability and type definition; a failure can fall back locally.
Necessary fields and legally pinned user fields are not cut by an ordinary information budget.
Field pinning, detail mode, and the predictive toggle do not freeze business state, and do not bypass permissions.
Automatic change passes interaction-protection, update-boundary, and stability-condition checks; it does not replace a target currently being operated on. A deferred decision re-verifies the current object, content snapshot, permissions, explicit choice, and policy before being applied; a decision superseded by a later one is not applied, and a stale intermediate form is not replayed.
Every user-visible form supports the keyboard and assistive-technology access it needs; the reading pause of an automatic-update region and "reduced motion" are validated separately, and the latter does not substitute for the former.
Every new field can be traced back to a design rule and an actual component need; a value used temporarily on only one page need not be immediately turned into a global token.

A newly added enum value cannot assume every component understands it; an unsupported mode or field only causes the related preference to fall back locally. See Appendix B of the Design Guidelines for acceptance scenarios.

11.1 Configuration consumption example

Below is a product configuration snippet for a task card, consumed separately from the DTCG value file in Section 9; the reference must be resolved within the product, and this snippet does not claim to run standalone.

{
  "aui": {
    "context": {
      "supportedModes": ["summary", "standard", "detailed"],
      "defaultMode": "standard",
      "allowedSignals": ["task-stage"]
    },
    "presentation": { "summaryLinePolicy": "unbounded" },
    "adaptation": {
      "updateBoundary": "interaction_end",
      "mutableRegions": ["optional-details"],
      "readingControlRef": "task-card-reading"
    },
    "control": {
      "pinnableDimensions": ["mode"],
      "preferenceScopes": ["view_session", "view_type"],
      "preferenceResolutionRef": "task-card-preferences",
      "onRevert": "until_explicit_resume"
    }
  }
}

Consumption process: the content contract and current necessary fields are resolved first, then the user's detail choice is adopted; unbounded makes the component ignore the inherited four-line cap. If Chinese IME input has not ended, only changes that would move the target are queued; failure impact updates within the necessary region. After input ends, the candidate is re-checked, and a summary candidate already superseded by the user's choice is discarded outright. until_explicit_resume suppresses only automatic presentation within the reverted scope, and the resume button's scope of effect must match it.

Input combination	Expected result
A base of 4 lines + an override layer omitting the line count	Still 4 lines
A base of 4 lines + `unbounded`	The line limit is not consumed
`bounded` + missing / zero / negative / non-integer line count	The form's configuration is rejected; the standard region falls back
`metadataVisibleCount=0` + a necessary owner field	The optional auxiliary field is not shown; the necessary owner field is still shown
`previewItemCount=3` + five necessary exceptions	The ordinary preview may be capped at three; exceptions are fully presented or accurately aggregated and reachable
A user's pinned detail view + a stale summary candidate arriving late	The detail view is retained; the candidate is discarded
Reduced motion + a normal-motion override	Resolves to the reduced-motion value, and cannot be overridden by the ordinary mode
Dangling reference / alias cycle / wrong type	Outputs a locatable configuration error and adopts an independently usable standard form

DTCG's dimension example is {"value":12,"unit":"px"}; dp, sp, and % cannot be used directly as units for this exchange type. When a platform needs those units, define a conversion layer and scaling semantics, rather than an unconditional one-to-one conversion. duration uses ms or s; counts use number but need additional validation of the integer range; modes, boolean capabilities, and conditional rules stay in the product's own schema.

Configuration delivery and validation

The preview count constrains only omittable items, not the evidence, exceptions, and user-pinned content a task requires. Example values are not a cognitive ceiling; after predictive adaptation is turned off, fact updates and permission tightening continue through their own mechanisms. A local resolution failure falls back the affected region, without clearing other valid content.

The accompanying executable sample covers only aui.presentation.previewItemCount; every other field is validated item by item against this dictionary — not being covered does not mean not applicable or already passed. The sample is a format positive/negative example for the fields it covers, not a product preset that can enable every capability directly. A complete product delivery additionally includes applicability, dependencies, evidence, the execution mapping, and the effective boundary for an in-progress operation.

When field names, types, or meanings change, update the referencing parties and acceptance samples; edits that only clarify wording without changing legal behavior keep the existing field names. Callers read the resolved effective configuration and do not back-infer authority, measurements, or completion facts from UI controls, animations, or model text. See the corresponding scenarios.

References

This file provides source cross-references for Adaptive Information Design Guidelines and Adaptive Information Design Token.

This search located research on adaptive interfaces, content personalization, progressive disclosure, human-AI interaction guidelines, and multi-context token-resolution specifications. Within the scope of this search, no directly adoptable, unified system was found that covers principles, interaction rules, and information-adaptation tokens together. This does not prove that no other public or internal enterprise system exists.

The six principles, the A-series rules, the aui.* fields, the modes, and the precedence rules are all this project's own design proposal. Cited sources support the relevant questions, mechanisms, or directions; they do not mean the original authors formulated or validated this project's complete set of guidelines.

Existing source entries retain their stated reading scope; abstracts and search leads among them are not upgraded to full-text evidence. This update additionally read the relevant body text of R05, R12, R13, R14, and R15; other sources were not individually re-verified. Numeric examples, scope ordering, and runtime state remain this project's own design choices.

1. Verification status and material types

Marker	Meaning
Relevant content verified	Content relevant to this use was verified by reading the original page; this does not represent a review of the full text or a tested implementation
Abstract verified	The abstract and bibliographic information from the author, institution, or author preprint were read; complete methods and effect sizes are not inferred from this alone
Search lead	Relevant content was visible in the search abstract, but the body text was not adequately read; this does not carry the weight of core-clause evidence

Type	What it can support	Boundaries
Author research	The existence of a problem, observations within the experimental scope, and design dimensions	A historical scenario or a limited sample cannot prove the benefit for every product
Design guideline	Interaction principles, practice patterns, and discussed failure modes	Not an external standard every product must follow
W3C draft and explainer document	Public approaches to content semantics and personalization	Cannot be used to claim the relevant properties are widely implemented
WCAG Understanding document	Explanation and examples for a success criterion	An Understanding document is explanatory material; formal conformance requirements should be checked against the WCAG normative text
DTCG community specification	Token value types, references, and a context-resolution mechanism	Not a formal W3C standard, and does not define this project's information-adaptation policy

2. Content adaptation and information architecture

R01 — W3C WAI-Adapt Overview

Source: WAI-Adapt Overview.
Verification scope: the introduction, content-adaptation examples, and document classification were verified.
Source facts: this work discusses adjusting content presentation to individual needs and preferences, including reducing irrelevant information and substituting a form of expression.
Guideline mapping: A1-2, A2-4, A5-4; clarify content semantics and user need first, then choose a presentation.
Boundaries: this is a series overview. The different modules the page lists have different levels of maturity, and the whole series cannot be called a unified, already-deployed standard.

R02 — WAI-Adapt Explainer

Source: primary entry point.
Verification scope: status, abstract, and content-simplification examples were verified.
Source facts: it supports personalization to a user's needs by adding semantic information to content; the examples discuss simplifying content of differing importance.
Guideline mapping: A2-1, A2-4; aui.content.contractRef and content-necessity metadata.
Boundaries: at the time of this reading the entry shows a 2023 Group Draft Note, work still in progress; the example attributes are not a capability this project can assume browsers support directly. This project's terms such as essential are likewise not a standardized substitute for the draft's attributes.

R03 — W3C Cognitive Accessibility: making important content easy to find

Source: Make it easy to find the most important actions and information on the page.
Verification scope: user needs, recommendations, and examples were verified.
Source facts: it stresses that key tasks, necessary actions, and important information should be easy to find and visually highlighted.
Guideline mapping: A2-1; an information budget must not silently hide necessary information.
Boundaries: this is supplemental cognitive-accessibility guidance, and the page explicitly states it is not a new success criterion required to meet WCAG. This guideline's "the necessary region takes precedence over the ordinary budget" is a design inference drawn from it.

R04 — Jakob Nielsen: Progressive Disclosure

Source: NN/g original, 2006-12-03.
Verification scope: the definition, the division of primary and secondary content, and the requirement for a discoverable expand entry were verified.
Source facts: primary options are presented first, and less-needed content is provided on demand; the key is dividing content correctly and making the entry easy to find.
Guideline mapping: A2-2, A2-3; detail-level tiers and the full-content path.
Boundaries: progressive disclosure can be a static design; it cannot be used to derive that a system should automatically guess at the user and continually hide content.

3. Adaptive behavior and user control

R05 — Microsoft HAX Guideline 14: Update and adapt cautiously

Source: Microsoft original.
Verification scope: the guideline body text and its description of the scale and frequency of change were verified.
Source facts: system updates and adaptation should limit disruptive changes and consider the scale and rate of change.
Guideline mapping: A3-2, A3-3; the adaptation update boundary and stability conditions.
Boundaries: this guideline does not provide a product-wide, universal cooldown duration, threshold, or information count. Interaction freezing, hysteresis, and merged updates are this project's own implementation direction, not the sole mechanism the original prescribes.

R06 — Microsoft HAX Guideline 17: Provide global controls

Source: Microsoft original.
Verification scope: the guideline body text was verified.
Source facts: provide a control that lets the user adjust the AI system's behavior overall.
Guideline mapping: A4-4; turning predictive adaptation off and its restore entry.
Boundaries: it does not require an independent switch for every information unit, nor does it imply that turning off predictive adaptation stops normal business updates; that latter separation is this guideline's own definition.

R07 — Gajos et al.: Predictability and accuracy in adaptive user interfaces

Source: author institution page, CHI 2008, 1271–1274.
Authors: Krzysztof Z. Gajos, Katherine Everitt, Desney S. Tan, Mary Czerwinski, Daniel S. Weld.
Verification scope: the abstract and bibliographic information were verified; the full text of this experiment was not read.
Source facts: the study reports that satisfaction improved when accuracy and predictability increased; increased accuracy also improved performance and use of the adaptive interface. The abstract also notes that, in that experiment, accuracy's effect on some metrics was stronger than predictability's.
Guideline mapping: A3-2, A6-1; verify adaptation accuracy, positioning cost, and satisfaction together, not interface stability alone.
Boundaries: the result cannot be turned into "stability is always more important than accuracy," nor can this project's own effect size or the benefit of automatic ordering be inferred from the abstract.

R08 — Jones et al.: "Customization is Key": Reconfigurable Content Tokens for Accessible Data Visualizations

Source: author preprint abstract, paper DOI.
Publication: ACM CHI 2024.
Authors: Shuli Jones, Isabella Pedraza Pineros, Daniel Hajas, Jonathan Zong, Arvind Satyanarayan.
Verification scope: the abstract and conference information were verified; the full text was not reviewed.
Source facts: the study discusses content presence, level of detail, order, and the duration of customization in screen-reader-accessible data visualizations. The abstract reports a study of 13 blind and low-vision participants, where customization helped with recognition and memory of information while also introducing complexity.
Guideline mapping: A4-2, A5-4, A6-1; information parameters, the duration scope of user preferences, and evaluating control complexity.
Boundaries: "Content Tokens" here refers to a configurable content unit within the study's model, and is not the same as DTCG design tokens; the study is also not a universal validation of automatic adaptation for all visual interfaces.

R09 — SAP Fiori: Overview Page – Resizable Card Layout

Source: original entry, entry after redirect.
Verification scope: search lead. The search abstract showed content adjusting to available space and a description of progressive disclosure; opening it directly redirected, and readable body text was not extracted.
May be useful for further reference: the practice of pre-designing components with different content granularities for the same information object.
Boundaries: it mainly concerns content adaptation after a user resizes a card, which is not entirely the same as task-context-driven adaptation; this entry does not carry core evidentiary weight for the A-series rules, nor does it promise a current product capability based on an old abstract.

4. Accessibility and token specifications

R10 — W3C Understanding SC 2.4.3: Focus Order

Source: Focus Order Understanding document.
Verification scope: the success criterion and its intent statement were verified.
Source facts: focus order needs to preserve content meaning and operability.
Guideline mapping: A3-4, A5-3; logical focus after an update and reading continuity.
Boundaries: this guideline's scroll anchor, object pinning, and input protection are further product requirements, not the success criterion's original text. The Understanding document itself is explanatory material.

R11 — W3C Understanding SC 4.1.3: Status Messages

Source: Status Messages Understanding document.
Verification scope: the success criterion and the description of status messages were verified.
Source facts: a qualifying status message should be programmatically determinable through a role or property, allowing assistive technology to present it without receiving focus.
Guideline mapping: A5-3; necessary updates can be perceived by assistive technology, avoiding grabbing focus as a substitute for a message.
Boundaries: this does not mean every content update should be announced, still less that every automatic adjustment should interrupt the user; specific use must distinguish a status message from other content changes.

R12 — DTCG Design Tokens Format Module

Source: Format specification.
Verification scope: status, design value types, references, and the expression of duration / numeric values were verified.
Source facts: it includes design types such as number, duration, dimension, color, and provides an expression and reference mechanism for shared values; the document explicitly states it is not a W3C Standard.
Guideline mapping: Sections 2, 3, and 9 of the Token document; distinguishing exchangeable values, custom content semantics, and the product's own schema.
Boundaries: having a numeric type does not mean defining the business semantics of "how many items a summary should show"; the format does not provide this project's custom rules or generic enum types. This document only gives partial JSON examples and has not validated complete toolchain interoperability.

R13 — DTCG Design Tokens Resolver Module

Source: Resolver specification.
Verification scope: context, modifiers, input requirements, resolution order, and the orthogonality description were verified.
Source facts: it provides a multi-context token-resolution mechanism; input is supplied by the caller, input values use strings, and overlapping values are handled by resolution order.
Guideline mapping: Sections 1, 9, and 10 of the Token document; separating task judgment from value resolution, and minimizing overlap among mode combinations.
Boundaries: the Resolver is not a user-intent recognizer, does not make permission judgments, and does not automatically protect necessary information. This project cannot explain a conflict in a behavioral constraint by "a later value overrides an earlier one."

5. From materials to this project's guidelines

The table below is editorial judgment, not a translation of the source text.

This guideline's design claim	Reference entries	Boundary of the inference
Select information by task and valid context	R01, R02, R07	Signal validity period, explicit-choice precedence, and unknown fallback are defined by this project
Necessary information takes precedence over an ordinary budget	R03, R04	The list of necessary fields must be decided by the product's own task and consequence analysis
Distinguish information detail level from visual density	R04, R08, R13	A modeling choice of this system; it does not claim the literature prescribes two fixed axes
Change is constrained by interaction boundaries and stability conditions	R05, R07, R10	No universal millisecond value is derived from the guidelines; the specific mechanism needs its own verification
The user can pin, restore, and turn off predictive adaptation	R06, R08	Scope, precedence, and revert suppression are this project's own rules
Expression is verifiable, content is accessible	R01～R04, R10, R11	Input-consistency validation for a generated summary and error fallback are this project's own extension
Evaluation must compare task benefit against adaptation cost	R07, R08	It is not claimed that this project has already obtained experimental results
Tokens, content metadata, and behavior policy are maintained separately	R02, R08, R12, R13	`aui.*` is a custom dictionary, not yet a general standard

6. Search record and open items

Item	Record
Search keywords	Adaptive User Interfaces; Adaptive Information Presentation; Context-aware Interfaces; adaptive UI predictability accuracy; progressive disclosure; WAI-Adapt content simplification; reconfigurable content tokens; DTCG resolver contexts modes
Selection basis	Priority given to standards bodies, authors / research institutions, and original design guidelines; a secondary article's summary is not treated as a standard requirement
Completed	Reading the relevant pages or abstracts above, distinguishing material maturity, and establishing the reference relationship between rules and fields
Not completed	A systematic literature review, full-text re-verification of the studies, real product UI testing, user experiments, and complete DTCG Resolver / design-tool interoperability validation
Limits of the search conclusion	Not finding a unified system is only a result within this search's scope; a public specification for a token's context resolution already exists, so it cannot be claimed that this area has no standardization work at all

Four things should be prioritized for further verification: whether the necessary information for different tasks is divided correctly; whether users can understand the scope of pinning and turning off; whether automatic change increases search and recovery cost; and whether the information count, change frequency, and transition duration are reasonable for the target product. Until these are verified, a prototype value must not be written as a universal lower bound or a best practice.

R14 — W3C: Pause, Stop, Hide

Source: success criterion text, Understanding document.
Verification scope: the success criterion, the applicability condition for automatic updates, and the pause and resume description within the Understanding document were read.
Source facts: automatically starting updating information presented alongside other content requires a control the criterion allows, with an exception when it is essential to the activity's nature. The auto-updating branch has no "control is only needed after five seconds" condition.
Guideline mapping: the reading control in A4-1; aui.adaptation.readingControlRef.
Boundaries: reduced motion is not the same as a reading pause. How a necessary exception is presented and how a permission revocation is handled are this project's combined design requirements, not attributed to the criterion's original text. The Understanding document is explanatory material.

R15 — Google PAIR: Feedback + Control

Source: original.
Verification scope: the passages on implicit, explicit, and dual feedback, on explaining how information is used, and on when feedback takes effect and control were read.
Source facts: an interaction does not always mean the user wants to see more of the same content; feedback needs to match a scope of impact and a time expectation the user can understand.
Guideline mapping: signal explanation in A1-2, persistent-inference control and feedback receipts in A4-2, and the feedback-bias check in A6-1; aui.control.personalizationDataRef.
Boundaries: that unexposed content cannot be judged as rejection, the clearing contract, and per-population evaluation are this project's own design inferences on the problem; the original does not prescribe this project's fields, data-retention duration, or preference precedence.

Items pending verification before implementation

Verify content necessity and the fallback interface first, then verify the actual benefit across different tasks and populations. Numeric targets, scope ordering, cooldown conditions, and the component field set all need product-level verification; source verification cannot substitute for real usage studies. Checking document links and JSON syntax also does not prove accessibility conformance or toolchain interoperability have been established.

Adaptive Information Design Guidelines

1. Scope and definitions¶

2. The six principles¶

2.1 Normative terms and how to read clauses¶

3. Rules in detail¶

A1 Adaptation is grounded¶

A1-1The task and the object of adaptation are explicitMUST¶

A1-2Distinguish facts, preferences, and inferencesMUST¶

A1-3Unknown and stale signals have a fallbackMUST¶

A1-4Adaptation does not change permissions or business semanticsMUST¶

A2 Information stays complete¶

A2-1Necessary information is not cut by a budgetMUST¶

A2-2Detail-level tiers have a defined contentMUST¶

A2-3Omitted content is discoverable and reachableMUST¶

A2-4Representation conversion preserves verifiable meaningMUST¶

A3 Change stays continuous¶

A3-1The object being interacted with is protected during interactionMUST¶

A3-2Ordering has a stable pathSHOULD¶

A3-3Update scope and frequency are boundedMUST¶

A3-4Reading position and focus are retained after an updateMUST¶

A4 The user retains control¶

A4-1Support viewing and pinningMUST¶

A4-2Preference scope and duration are explicitMUST¶

A4-3Noticeable adaptation can be reverted or restoredMUST¶

A4-4Automatic adaptation can be turned offMUST¶

A5 Presentation stays understandable¶

A5-1Explain the reason for a noticeable changeSHOULD¶

A5-2Displayed scope and business state are expressed separatelyMUST¶

A5-3Every tier remains accessibleMUST¶

A5-4The mode of expression allows task-based correctionSHOULD¶

A6 Effect is verifiable¶

A6-1Compare against a stable baselineMUST¶

A6-2Exceptions and interaction combinations enter acceptance testingMUST¶

A6-3A usable interface remains when resolution failsMUST¶

A6-4Decisions are traceable, and tuning does not relax the baselineMUST¶

4. Information units and state modeling¶

4.1 Minimal design description per information unit¶

4.2 State axes maintained separately¶

4.3 Lifecycle of an adaptation decision¶

4.4 End-to-end case: a troubleshooting task board¶

Appendix A: Component examples at the same width¶

Appendix B: Acceptance checklist¶

Appendix C: Evidence and items pending verification¶

Appendix D: Acceptance records and measurement basis¶

Implementation acceptance scenarios¶

1. Three parts and the boundary with runtime data¶

1.1 Resolution order¶

1.2 Required, conditionally required, and optional¶

1.3 Decision authority, inheritance, and taking effect¶

2. Presentation tokens: how each form is displayed¶

3. Information presentation parameters: how much is shown by default¶

3.1 Mode preset examples¶

4. Context policy: what a form is chosen based on¶

5. Content contract: what each mode contains¶

6. Change policy: when updates are allowed¶

7. User control: how choices persist¶

8. Fallback: how it is displayed on failure¶

9. Interfacing with DTCG¶

10. Dependencies and handling of missing configuration¶

10.1 Minimum content of a reference contract¶

10.2 Legal minimal configuration per capability tier¶

11. Validation and maintenance¶

11.1 Configuration consumption example¶

Configuration delivery and validation¶

1. Verification status and material types¶

2. Content adaptation and information architecture¶

R01 — W3C WAI-Adapt Overview¶

R02 — WAI-Adapt Explainer¶

R03 — W3C Cognitive Accessibility: making important content easy to find¶

R04 — Jakob Nielsen: Progressive Disclosure¶

3. Adaptive behavior and user control¶

R05 — Microsoft HAX Guideline 14: Update and adapt cautiously¶

R06 — Microsoft HAX Guideline 17: Provide global controls¶

R07 — Gajos et al.: Predictability and accuracy in adaptive user interfaces¶

R08 — Jones et al.: "Customization is Key": Reconfigurable Content Tokens for Accessible Data Visualizations¶

R09 — SAP Fiori: Overview Page – Resizable Card Layout¶

4. Accessibility and token specifications¶

R10 — W3C Understanding SC 2.4.3: Focus Order¶

R11 — W3C Understanding SC 4.1.3: Status Messages¶

R12 — DTCG Design Tokens Format Module¶