From c1592ae2decd9ed87d7d3c993be1f0c3bcb41fa5 Mon Sep 17 00:00:00 2001 From: virtualmase Date: Thu, 15 Oct 2026 16:44:20 -0700 Subject: [PATCH 1/4] Strengthen reference topic navigation and enforce internal-link quality --- about/index.html | 2 +- changelog/index.html | 2 +- content/news/finops-framework-2026.md | 4 + .../kubernetes-136-resource-allocation.md | 3 + content/news/kueue-admission-headlamp.md | 4 + content/wiki/agent-orchestration.md | 2 +- content/wiki/audit-trails.md | 2 +- .../wiki/autonomous-resource-management.md | 2 +- content/wiki/autoscaling.md | 4 +- content/wiki/observability.md | 2 +- content/wiki/resource-scheduling.md | 2 +- contribute/index.html | 2 +- docs/search-topic-strategy.md | 69 ++++++++++++ editorial-policy/index.html | 2 +- editorial/README.md | 4 +- editorial/topics.json | 42 ++++++++ framework/index.html | 2 +- index.html | 1 + news/finops-framework-2026/index.html | 4 +- .../index.html | 4 +- news/kueue-admission-headlamp/index.html | 4 +- package.json | 17 ++- public/site.css | 2 + release.json | 44 ++++---- scripts/audit-links.py | 101 ++++++++++++++++++ scripts/build.mjs | 19 +++- scripts/topics.mjs | 29 +++++ search-index.json | 2 +- site.css | 2 + sources/index.html | 2 +- tests/browser/site.spec.mjs | 14 +++ tests/test_links.py | 44 ++++++++ wiki/agent-orchestration/index.html | 6 +- wiki/audit-trails/index.html | 6 +- .../autonomous-resource-management/index.html | 8 +- wiki/autoscaling/index.html | 10 +- wiki/finops-and-cost-controls/index.html | 6 +- wiki/human-oversight/index.html | 6 +- wiki/index.html | 2 +- wiki/observability/index.html | 8 +- wiki/resource-scheduling/index.html | 8 +- 41 files changed, 417 insertions(+), 82 deletions(-) create mode 100644 docs/search-topic-strategy.md create mode 100644 editorial/topics.json create mode 100644 scripts/audit-links.py create mode 100644 scripts/topics.mjs create mode 100644 tests/test_links.py diff --git a/about/index.html b/about/index.html index e99ceec..ffc365c 100644 --- a/about/index.html +++ b/about/index.html @@ -1,7 +1,7 @@ About this reference | Autonomous Resource Management
Autonomous Resource
ManagementKnowledge · Context · Evidence
-
Home / Reference
About this resource

About this reference

Purpose, authorship, editorial boundaries, and how this resource is maintained.

ARM Editorial · Updated

A reference for resource decisions

This site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.

+
About this resource

About this reference

Purpose, authorship, editorial boundaries, and how this resource is maintained.

ARM Editorial · Updated

A reference for resource decisions

This site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.

The project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.

Maintainer and authorship

Mason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.

The proposed ARM working framework is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.

diff --git a/changelog/index.html b/changelog/index.html index 16afcbc..14e43bc 100644 --- a/changelog/index.html +++ b/changelog/index.html @@ -1,7 +1,7 @@ Revision log | Autonomous Resource Management
Autonomous Resource
ManagementKnowledge · Context · Evidence
-
Home / Reference
About this resource

Revision log

Material changes to the reference, its scope, and editorial practices.

ARM Editorial · Updated

15 October 2026 — standalone reference revision

    +
    About this resource

    Revision log

    Material changes to the reference, its scope, and editorial practices.

    ARM Editorial · Updated

    15 October 2026 — standalone reference revision

    • Reframed the homepage around a source-backed knowledge library.
    • Removed commercial implementation referrals from the reference site's publishing model.
    • Moved the attributed ARM proposal to a dedicated framework page.
      • diff --git a/content/news/finops-framework-2026.md b/content/news/finops-framework-2026.md index 101c3ad..8b17316 100644 --- a/content/news/finops-framework-2026.md +++ b/content/news/finops-framework-2026.md @@ -19,6 +19,10 @@ "url": "https://www.finops.org/insights/2026-finops-framework/", "scope": "Official publisher announcement; supports attributed changes, not independent outcome claims." } + ], + "concepts": [ + "/wiki/finops-and-cost-controls/", + "/wiki/human-oversight/" ] } --- diff --git a/content/news/kubernetes-136-resource-allocation.md b/content/news/kubernetes-136-resource-allocation.md index 435adc0..12163e1 100644 --- a/content/news/kubernetes-136-resource-allocation.md +++ b/content/news/kubernetes-136-resource-allocation.md @@ -19,6 +19,9 @@ "url": "https://kubernetes.io/blog/2026/05/07/kubernetes-v1-36-dra-136-updates/", "scope": "Official publisher announcement; supports attributed changes, not independent outcome claims." } + ], + "concepts": [ + "/wiki/resource-scheduling/" ] } --- diff --git a/content/news/kueue-admission-headlamp.md b/content/news/kueue-admission-headlamp.md index b4403e9..d83e6ca 100644 --- a/content/news/kueue-admission-headlamp.md +++ b/content/news/kueue-admission-headlamp.md @@ -19,6 +19,10 @@ "url": "https://kubernetes.io/blog/2026/10/14/tracing-kueue-admission-with-headlamp/", "scope": "Project-authored guide; supports the described troubleshooting distinction and plugin limitations." } + ], + "concepts": [ + "/wiki/resource-scheduling/", + "/wiki/observability/" ] } --- diff --git a/content/wiki/agent-orchestration.md b/content/wiki/agent-orchestration.md index 0107eea..29793ff 100644 --- a/content/wiki/agent-orchestration.md +++ b/content/wiki/agent-orchestration.md @@ -18,7 +18,7 @@ } --- ## Coordination and authority -Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget. +Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or [budget](/wiki/finops-and-cost-controls/). An orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it. diff --git a/content/wiki/audit-trails.md b/content/wiki/audit-trails.md index 1eb0e9e..fce3299 100644 --- a/content/wiki/audit-trails.md +++ b/content/wiki/audit-trails.md @@ -18,7 +18,7 @@ } --- ## What an audit trail can establish -An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result. +An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its [authorization context](/wiki/human-oversight/), the attempted action, and the result. [Kubernetes auditing](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration. diff --git a/content/wiki/autonomous-resource-management.md b/content/wiki/autonomous-resource-management.md index f7dbddf..f020b15 100644 --- a/content/wiki/autonomous-resource-management.md +++ b/content/wiki/autonomous-resource-management.md @@ -28,7 +28,7 @@ Autonomous resource management describes systems that observe resource condition A useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision. ## How the pieces fit together -A resource-management design needs a target, measurements, a decision mechanism, and a way to act. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](https://kubernetes.io/docs/concepts/architecture/controller/). The broader connection to ARM is our editorial synthesis. +A resource-management design needs a target, [measurements](/wiki/observability/), a decision mechanism, and a way to act. Use [audit trails](/wiki/audit-trails/) to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](https://kubernetes.io/docs/concepts/architecture/controller/). The broader connection to ARM is our editorial synthesis. Consider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation. diff --git a/content/wiki/autoscaling.md b/content/wiki/autoscaling.md index 310fbf9..b919547 100644 --- a/content/wiki/autoscaling.md +++ b/content/wiki/autoscaling.md @@ -25,10 +25,10 @@ ## What autoscaling changes Autoscaling adjusts capacity in response to observed or anticipated demand. The [Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/). Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system. -Choosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. +Choosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare [resource scheduling and allocation](/wiki/resource-scheduling/) when the problem is where work can run. ## Signals and decisions -A controller compares measurements with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve. +A controller compares [measurements](/wiki/observability/) with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve. For a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration. diff --git a/content/wiki/observability.md b/content/wiki/observability.md index 629490a..14b1a18 100644 --- a/content/wiki/observability.md +++ b/content/wiki/observability.md @@ -28,7 +28,7 @@ As editorial guidance, consider recording the resource identifier, observation t Separate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective. ## Evidence quality -A signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric to control resources, define how old it may be and how the system should behave when the data is unavailable. +A signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric for [autoscaling](/wiki/autoscaling/), define how old it may be and how the system should behave when the data is unavailable. For example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default. diff --git a/content/wiki/resource-scheduling.md b/content/wiki/resource-scheduling.md index 23e303c..2e4a015 100644 --- a/content/wiki/resource-scheduling.md +++ b/content/wiki/resource-scheduling.md @@ -25,7 +25,7 @@ ## What a scheduler decides A scheduler matches work to eligible resources. It has to respect constraints before considering preferences. [Kubernetes describes filtering candidate nodes and scoring the feasible ones](https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/). -Scheduling is distinct from scaling. A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective. +Scheduling is distinct from [autoscaling](/wiki/autoscaling/). A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective. ## Constraints before preferences In a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice. diff --git a/contribute/index.html b/contribute/index.html index 1febd2b..d120724 100644 --- a/contribute/index.html +++ b/contribute/index.html @@ -1,7 +1,7 @@ Contribute or request a correction | Autonomous Resource Management
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / Reference
      About this resource

      Contribute or request a correction

      A practical route for improving definitions, citations, examples, and industry coverage.

      ARM Editorial · Updated

      Suggest a factual correction

      Open a correction request with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.

      +
      About this resource

      Contribute or request a correction

      A practical route for improving definitions, citations, examples, and industry coverage.

      ARM Editorial · Updated

      Suggest a factual correction

      Open a correction request with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.

      GitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.

      Contribute an article

      Use the public repository to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.

      Disclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.

      diff --git a/docs/search-topic-strategy.md b/docs/search-topic-strategy.md new file mode 100644 index 0000000..1cf8a60 --- /dev/null +++ b/docs/search-topic-strategy.md @@ -0,0 +1,69 @@ +# Reference search and internal-link strategy + +Property: autonomousresourcemanagement.com. Prepared 15 October 2026. + +## Evidence and scope + +This is an editorial topic plan, not a measured keyword-volume or ranking report. Ubersuggest authentication failed; the owner requested free tools instead. The public Ahrefs Keyword Generator and Semrush Keyword Search Volume Checker pages were accessible, but no keyword result dataset was obtained. Moz Explorer did not return usable content. No paid API credits were used. No traffic, difficulty, ranking, or dominance claim is made. + +A public search for the full term surfaced infrastructure vendors, serverless research, reinforcement-learning papers, and networking research. This establishes a range of uses, not their relative demand or quality. Focus the reference on compute/workload allocation and accountable control first. Do not stretch the definition into staffing, capital allocation, construction, or telecom coverage without domain-specific sources and editorial capability. The search result for this domain still showed the old homepage: public search snippets are not evidence of current indexing or production parity. + +## Architecture implemented + +Homepage → four question-based sections in `/wiki/` → existing concept articles → relevant dated news → the concept cited in the brief. Each section has a stable fragment and original orientation text. These are sections of the existing library, not thin new category pages. Existing article URLs remain unchanged. + +`editorial/topics.json` assigns every published wiki article one primary section. News `concepts` metadata requires a real contextual link in the brief; it powers up to three dated return links from each concept. The source directory links to the articles that cite each source. Breadcrumbs show the actual topic path and current page. The framework remains a clearly attributed proposal. + +`npm run check` now audits rendered HTML for self-canonicals, same-origin absolute and relative links, fragments, indexable orphans, canonical URL variants, contextual article inlinks, and distance from the homepage. The three-click limit is our maintainability target, not a Google ranking rule. Current maximum is two links. The JSON report at `test-results/internal-links.json` lists each indexable route, incoming pages, contextual incoming pages, and depth. No report is published as website content. + +## One primary destination per reader question + +| Intent family / candidate phrasing | Current primary destination | Coverage / next work | +|---|---|---| +| autonomous resource management; what is ARM; automated resource allocation | `/wiki/autonomous-resource-management/` | Working scope and related disciplines; deepen with research distinctions. Avoid targeting the ambiguous acronym alone. | +| autoscaling; resource feedback loops; horizontal vs vertical scaling | `/wiki/autoscaling/` | Conceptual overview; comparison needs a worked example before a separate page. | +| resource scheduling; workload placement; scheduling vs scaling | `/wiki/resource-scheduling/` | Placement and constraints; suitable parent for queueing and accelerator topics. | +| FinOps; resource cost controls; budget alerts vs enforced limits | `/wiki/finops-and-cost-controls/` | Conceptual distinctions; do not imply product savings. | +| resource observability; metrics for allocation decisions; stale signals | `/wiki/observability/` | Signal quality and limitations; parent for control-loop diagnostics. | +| audit trails; resource decision provenance; allocation logs | `/wiki/audit-trails/` | Record questions and limits; parent for a reproducible example record. | +| agent orchestration; tool access; resource limits for agents | `/wiki/agent-orchestration/` | Conceptual workflow; distinguish protocol support from authorization. | +| human oversight; delegated decision rights; escalation in automation | `/wiki/human-oversight/` | Operational authority and intervention; maintain a technical reference scope. | + +Synonyms belong on the same useful page when intent matches. New pages require a distinct question, substantial answer, primary sources, and at least one contextual link from an existing parent article. Do not create separate pages for every keyword variant or year. + +## Prioritized expansion backlog + +These are unvalidated demand hypotheses, ordered by usefulness and fit with the existing library. Proposed paths are not public links, sitemap entries, or publication promises. + +| Wave | Reader question / candidate searches | Proposed destination | Required evidence and parent | +|---|---|---|---| +| 1 | HPA vs VPA vs node autoscaling; which layer changes capacity? | `/wiki/autoscaling-comparison/` | Versioned Kubernetes docs; original comparison and interaction example. Parent: autoscaling. | +| 1 | Why is a workload pending: admission, quota, or placement? | `/wiki/workload-admission/` | Kueue and scheduler docs; bounded diagnostic decision tree. Parent: scheduling. | +| 1 | CPU requests vs limits; resource quotas vs budgets | `/wiki/resource-requests-and-limits/` | Kubernetes docs; distinguish accounting, enforcement, and scheduling. Parents: scheduling and cost controls. | +| 1 | Metrics stale during autoscaling; oscillation and cooldowns | `/wiki/autoscaling-failure-modes/` | Controller docs and reproducible bounded examples. Parents: autoscaling and observability. | +| 2 | GPU scheduling; DRA vs device plugins; accelerator allocation | `/wiki/gpu-resource-allocation/` | Versioned project docs; hardware/driver constraints, no universal performance claim. Parent: scheduling. | +| 2 | AI inference budgets; token costs; agent execution limits | `/wiki/inference-resource-budgets/` | Provider accounting docs and transparent hypothetical calculation; date pricing assumptions. Parents: cost and orchestration. | +| 2 | Idempotency vs retries; uncertain execution; duplicate resource actions | `/wiki/retries-and-idempotency/` | API specifications and a reproducible example with failures. Parents: orchestration and audit trails. | +| 2 | Rightsizing vs autoscaling; capacity planning vs scaling | `/wiki/rightsizing-and-capacity-planning/` | Original workload example and documented measurement limits. Parents: autoscaling and cost. | +| 3 | Rule-based vs predictive vs reinforcement-learning allocation | `/wiki/resource-control-approaches/` | Primary papers, baseline conditions, external validity and failure cases. Parent: ARM overview. | +| 3 | Fair-share scheduling; quotas; preemption | `/wiki/scheduling-fairness/` | Scheduler documentation and explicit fairness definitions. Parent: scheduling. | +| 3 | Energy-aware allocation; carbon-aware scheduling tradeoffs | `/wiki/energy-aware-allocation/` | Primary research; measurement boundary and workload/SLO assumptions. Parent: scheduling. | +| 3 | How to evaluate autonomous resource-management software | `/wiki/evaluating-resource-management-systems/` | Neutral evaluation criteria and reproducible tests; no paid rankings or untested recommendations. Parents: overview and audit trails. | + +Each wave means dependency order, not an article quota. Update existing pages when the answer fits; split only when the reader task becomes independently useful. News can surface changes but must not substitute for evergreen explanation. + +## Free measurement and operating cadence + +1. Establish an authorized Google Search Console baseline for the exact `.com` property: query/page, impressions, clicks, CTR, position, country, device, and indexing. Read-only reporting first; sitemap submission and other account mutations remain separate owner-authorized actions. Do not infer zero impressions when access is unavailable. +2. Use free Ahrefs/Semrush/Moz interfaces only within available access limits. Record provider, date, country, exact query, and returned result; unavailable is not zero. Public search results provide intent examples, not unbiased rankings or volume estimates. No paid API calls are needed for the link audit. +3. Every week, review query-to-page mismatches, pages receiving impressions without clicks, missing reader answers, and news candidates. Check whether queries land on the intended article before rewriting titles. Diagnose multiple pages per query by intent before calling it cannibalization. +4. Every month, inspect topic-level performance and the link report. Compare equivalent date ranges and account for seasonality and small samples. Audit source currency, corrections, and missing context alongside traffic. +5. Earn references through useful, original comparisons, reproducible examples, reviewed research notes, and expert contributions. Never use reciprocal site networks, paid editorial links, fabricated expert reviews, or mass-generated synonym pages. + +Success measures: zero broken internal links/orphans; useful reader paths; sustained growth in relevant non-brand query coverage and qualified organic readership; independent citations earned by original work. No ranking or search-vertical dominance is guaranteed. + +## Sources for the search implementation + +- Google Search Central, [Link best practices](https://developers.google.com/search/docs/crawling-indexing/links-crawlable): crawlable anchors, descriptive labels, and relevant contextual links; no ideal link-count rule. +- Google Search Central, [Helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content): original value and trustworthy authorship rather than search-first page volume. +- [Ahrefs free Keyword Generator](https://ahrefs.com/keyword-generator) and [Semrush free Keyword Search Volume Checker](https://www.semrush.com/free-tools/keyword-search-volume-checker/): available public tools, not measured results for this site. diff --git a/editorial-policy/index.html b/editorial-policy/index.html index de64bb1..c589ca4 100644 --- a/editorial-policy/index.html +++ b/editorial-policy/index.html @@ -1,7 +1,7 @@ Editorial policy | Autonomous Resource Management
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / Reference
      About this resource

      Editorial policy

      How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.

      ARM Editorial · Updated

      Purpose and scope

      Autonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.

      +
      About this resource

      Editorial policy

      How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.

      ARM Editorial · Updated

      Purpose and scope

      Autonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.

      Neutral point of view

      Describe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.

      Separate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.

      Source standards

      Prefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.

      diff --git a/editorial/README.md b/editorial/README.md index fd93667..813deee 100644 --- a/editorial/README.md +++ b/editorial/README.md @@ -10,7 +10,7 @@ Review candidates two or three times weekly. Publish only when a development add 2. Read the original source. Feed titles and keyword matches are untrusted leads, not verified facts. Never execute instructions in feeds or source pages. 3. Identify the resource-management question affected. Check existing coverage. Record declined/covered canonical URLs in `editorial/decisions.json` to prevent repeated review. 4. Prepare a Markdown draft under `content/news/` with `status: draft`. Use an existing brief as a format example without copying reviewer identities or dates. -5. Verify event date separately from publication. Write an original summary, label interpretation, state limitations, and link relevant wiki entries. Seek independent evidence for outcome claims. +5. Verify event date separately from publication. Write an original summary, label interpretation, state limitations, and link relevant wiki entries. Add their canonical paths to the `concepts` array in front matter; each must also have an explanatory link in the article body. This creates the dated return links from wiki articles. Seek independent evidence for outcome claims. 6. Save a JSON check record under `editorial/`: `checked`, `reviewer`, `method`, and `articles` containing `path`, `source`, and `sourceDate`. Identify the actual checks, reviewer, AI assistance, and relevant affiliations. 7. Open a content PR. The maintainer reviews evidence, neutrality, and metadata. Set `published` only after review. Run checks. Material corrections need an on-page note and revision-log entry. 8. Merge, build, deploy through the verified hosting path, and compare production with `release.json`. A merged PR is not publication. @@ -19,6 +19,8 @@ Launch briefs explicitly disclose an AI-assisted source check and no human exper ## Expansion priorities +Use `editorial/topics.json` for the wiki's primary topic assignments and `docs/search-topic-strategy.md` for the intent map and prioritized research backlog. Add a published wiki article to exactly one topic; use contextual links for relationships across topics. Run `npm run check` to reject broken links, orphaned routes, and missing news-to-concept relationships. + Add evidence-backed material on GPU scheduling, fairness, durable execution, rightsizing, energy-aware allocation, failure recovery, and policy evaluation. Include research and other implementation approaches to reduce dependence on any one project's documentation. A specification supports its requirements; an announcement supports what its publisher reports; an independent evaluation may support results within stated test conditions. These are not interchangeable. diff --git a/editorial/topics.json b/editorial/topics.json new file mode 100644 index 0000000..1776b0b --- /dev/null +++ b/editorial/topics.json @@ -0,0 +1,42 @@ +[ + { + "id": "foundations", + "title": "Foundations and scope", + "question": "What does autonomous resource management mean?", + "description": "Start with the working definition and distinguish resource decisions from general automation.", + "articles": [ + "autonomous-resource-management" + ] + }, + { + "id": "capacity-and-placement", + "title": "Capacity and workload placement", + "question": "Do I need more capacity, or a different allocation?", + "description": "Compare scaling with scheduling before investigating workload constraints and capacity limits.", + "articles": [ + "autoscaling", + "resource-scheduling" + ] + }, + { + "id": "cost-and-evidence", + "title": "Cost and operational evidence", + "question": "What did the system consume, and what evidence explains it?", + "description": "Connect budgets and cost controls to measurements, observed outcomes, and decision records.", + "articles": [ + "finops-and-cost-controls", + "observability", + "audit-trails" + ] + }, + { + "id": "orchestration-and-oversight", + "title": "Orchestration and human oversight", + "question": "Which actions can a workflow take, and who can intervene?", + "description": "Follow task coordination into delegated permissions, escalation, and accountable review.", + "articles": [ + "agent-orchestration", + "human-oversight" + ] + } +] diff --git a/framework/index.html b/framework/index.html index 34b7cd5..07afb0a 100644 --- a/framework/index.html +++ b/framework/index.html @@ -1,7 +1,7 @@ The ARM working framework | Autonomous Resource Management
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / Reference
      Editorial proposal

      The ARM working framework

      An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

      Mason Nguyen; revision assisted by AI · Updated

      AI-assisted source synthesis; no independent expert review claimed.

      Status and authorship

      This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

      +
      Editorial proposal

      The ARM working framework

      An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

      Mason Nguyen; revision assisted by AI · Updated

      AI-assisted source synthesis; no independent expert review claimed.

      Status and authorship

      This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

      Earlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.

      Five design concerns

      Decision rights

      Identify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.

      Observable signals

      Record the measurements and assumptions used in a decision. OpenTelemetry's signal vocabulary is relevant background for instrumentation, not an endorsement of this framework.

      diff --git a/index.html b/index.html index 6ec76d4..5894240 100644 --- a/index.html +++ b/index.html @@ -3,6 +3,7 @@
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      The autonomous resource management reference

      Autonomous resource
      management, explained.

      A knowledge resource for how automated systems allocate resources—and how people keep those decisions accountable.

      Start with the fundamentals →Explore the wiki
      +

      Explore by question

      The reference library

      All 8 reference articles →
      03 / Wiki reference

      Autoscaling and feedback loops

      How capacity follows demand, and why signals, limits, and recovery matter.

      Definition, context & limitations
      04 / Wiki reference

      FinOps and cost controls

      Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

      Definition, context & limitations

      Industry context

      Browse source briefs →

      Dated developments, their implications, and what the evidence does not establish.

      From concepts to questions

      What can this system decide?

      Start with the action, its limits, the evidence behind it, and who can intervene. The ARM working framework offers one attributed proposal for organizing those questions.

      Read the working framework →
      An inspectable reference

      Follow the source.

      Articles identify their evidence, distinguish examples from findings, and link to revision history. Corrections and additional perspectives are welcome.

      Improve this resource →
      diff --git a/news/finops-framework-2026/index.html b/news/finops-framework-2026/index.html index bace463..da06d1a 100644 --- a/news/finops-framework-2026/index.html +++ b/news/finops-framework-2026/index.html @@ -1,7 +1,7 @@ FinOps Framework 2026 adds strategy alignment and broader technology guidance | Autonomous Resource Management -
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / News
      Source brief

      FinOps Framework 2026 adds strategy alignment and broader technology guidance

      A background brief on the March framework revision and its relevance to resource-management objectives.

      ARM Editorial · Updated
      Source event: 2026-03-19 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      The FinOps Foundation’s 19 March 2026 framework update introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.

      +
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      +
      Source brief

      FinOps Framework 2026 adds strategy alignment and broader technology guidance

      A background brief on the March framework revision and its relevance to resource-management objectives.

      ARM Editorial · Updated
      Source event: 2026-03-19 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      The FinOps Foundation’s 19 March 2026 framework update introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.

      This brief covers that published revision as background, rather than presenting the March announcement as new today.

      Why it matters

      Editorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.

      Read FinOps and cost controls for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. Human oversight explains why a budget boundary also needs an accountable owner.

      diff --git a/news/kubernetes-136-resource-allocation/index.html b/news/kubernetes-136-resource-allocation/index.html index d1b6ef2..e2f80cc 100644 --- a/news/kubernetes-136-resource-allocation/index.html +++ b/news/kubernetes-136-resource-allocation/index.html @@ -1,7 +1,7 @@ Kubernetes 1.36 expands Dynamic Resource Allocation | Autonomous Resource Management -
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / News
      Source brief

      Kubernetes 1.36 expands Dynamic Resource Allocation

      A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.

      ARM Editorial · Updated
      Source event: 2026-05-07 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      In its 7 May 2026 update, the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.

      +
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      +
      Source brief

      Kubernetes 1.36 expands Dynamic Resource Allocation

      A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.

      ARM Editorial · Updated
      Source event: 2026-05-07 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      In its 7 May 2026 update, the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.

      This is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.

      Why it matters

      Editorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.

      A useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See resource scheduling for the distinction between eligible capacity and preferred capacity.

      diff --git a/news/kueue-admission-headlamp/index.html b/news/kueue-admission-headlamp/index.html index 2f11b52..75d16f4 100644 --- a/news/kueue-admission-headlamp/index.html +++ b/news/kueue-admission-headlamp/index.html @@ -1,7 +1,7 @@ Headlamp guide separates Kueue admission from Pod scheduling | Autonomous Resource Management -
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      -
      Home / News
      Source brief

      Headlamp guide separates Kueue admission from Pod scheduling

      An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.

      ARM Editorial · Updated
      Source event: 2026-10-14 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      A 14 October 2026 Kubernetes project guide describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.

      +
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      +
      Source brief

      Headlamp guide separates Kueue admission from Pod scheduling

      An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.

      ARM Editorial · Updated
      Source event: 2026-10-14 · Brief published: 2026-10-15 · Source checked: 2026-10-15

      AI-assisted source check; no independent testing or human expert review claimed.

      What changed

      A 14 October 2026 Kubernetes project guide describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.

      The guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.

      Why it matters

      Editorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.

      This distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See resource scheduling and observability for related concepts.

      diff --git a/package.json b/package.json index e5f7793..dcb55ab 100644 --- a/package.json +++ b/package.json @@ -2,17 +2,24 @@ "name": "autonomous-resource-management-reference", "private": true, "type": "module", - "engines": { "node": ">=22" }, + "engines": { + "node": ">=22" + }, "scripts": { "build": "node scripts/build.mjs", "export": "npm run build && node scripts/export-static.mjs", "check:export": "node scripts/export-static.mjs --check", "test": "node --test tests/*.test.mjs && python3 -m unittest discover -s tests -p 'test_*.py'", - "check": "npm run build && node scripts/check.mjs", + "check": "npm run build && node scripts/check.mjs && python3 scripts/audit-links.py", "preview": "python3 -m http.server 4173 --bind 127.0.0.1 --directory dist", "news:collect": "python3 scripts/collect-news.py", - "test:browser": "playwright test" + "test:browser": "playwright test", + "check:links": "python3 scripts/audit-links.py" + }, + "dependencies": { + "marked": "18.1.1" }, - "dependencies": { "marked": "18.1.1" }, - "devDependencies": { "@playwright/test": "1.64.1" } + "devDependencies": { + "@playwright/test": "1.64.1" + } } diff --git a/public/site.css b/public/site.css index d2c3524..0e18f8f 100644 --- a/public/site.css +++ b/public/site.css @@ -6,3 +6,5 @@ @media(prefers-reduced-motion:reduce){html{scroll-behavior:auto}} .resource-loop{display:block;width:100%;height:auto;margin:20px 0 5px} + +.topic-paths{display:grid;grid-template-columns:repeat(2,minmax(0,1fr));gap:24px;list-style:none;padding:0;margin:20px 0}.topic-paths li{border-top:1px solid var(--line);padding-top:16px}.topic-paths a{font-family:var(--serif);font-size:23px}.topic-paths p{font-size:14px;color:var(--muted);margin-top:8px}.breadcrumb{display:flex;flex-wrap:wrap;gap:8px;line-height:1.7}.breadcrumb span[aria-current]{overflow-wrap:anywhere}.source-list p{font-size:13px;margin-top:8px}@media(max-width:500px){.topic-paths{grid-template-columns:1fr}} diff --git a/release.json b/release.json index 1e7e3e7..6c689da 100644 --- a/release.json +++ b/release.json @@ -1,26 +1,26 @@ { "schemaVersion": 1, - "contentDigest": "a804c59ce1a157a4efe395ef37d8a4a4a4d0e346a9884f57d0f6e47f490a1ca6", + "contentDigest": "487fb00327c940982e9c3ef4475dc825de569101c76c26d7a4c17efb094a7712", "contentRevision": "2026-10-15", "pages": 22, "files": { ".htaccess": "98ffdb0e30a0a6e638a18e154181e33bfb133ff38d4d977485cd988915a2d816", "404.html": "4eefc29e83eb4e2814b5ea64743e115a467d9a9edbb3322f1dabeff8b5bd70bc", "404/index.html": "4eefc29e83eb4e2814b5ea64743e115a467d9a9edbb3322f1dabeff8b5bd70bc", - "about/index.html": "6b3d1cd021edea6222e8893d933481a0b5cd8a5fe5f6ddbb42375557a04bfb9e", - "changelog/index.html": "448b8549e301d3bfaeae97fd83b1a466b069a3cad10495330d653a63d2c64127", - "contribute/index.html": "abe3195524a7722d34214b17499b28bf3fb559e0693b253e5639f7e07c617dcb", - "editorial-policy/index.html": "a7c5c8f429ee6daa6022535a3f4f9768bc3bac43c87f660e3c16dec0a655d469", + "about/index.html": "3e1f32510fc3eb7ce3011e36d69a452d921732a61dd90764689c1b6556f2a9d5", + "changelog/index.html": "d619f065e573360ad281ba10d3508bedddcb528a30b26bf4c2189b8672e0a813", + "contribute/index.html": "d5085a0847cc772500dc968b493c66eb61a713ba7eda6adc367d8ba0736f7f0b", + "editorial-policy/index.html": "83d5733ada4919692db438774c2d2526609bc4b2b5d29ea3206bbcc4a99e5d6e", "favicon.svg": "3766c9e6c1326cb25b003f88369e29907a8660883228c13ab470e306ed4df91e", "feed.xml": "979325d4616849c8c5bd7d386e98414fdf7d07bfc8aca49e566d945503d14419", - "framework/index.html": "68235c7d074b0fff27c611ab4269a9ab1e212e86bfcc19aa90b9eea5b6bad04d", + "framework/index.html": "46bd393b51985bef8b32dfd83390a80dcdac70b6aff5eb339a31f2ec4dd1e59e", "googlef40b1c9053cf9205.html": "a2afae8978371b939c5ac9e680468c14f119e38a6478ee92d867d510e39f54d4", - "index.html": "1b75d81138a6735a8d939a40b3bc447bc7f37df3f0673efebbacc42d3cec54f4", + "index.html": "3296bf6df1796c3d04f2a8c3d7a251f32e9fef7bbbf65fff3e13b83ccbaec5cc", "llms.txt": "3954c4e791dff83fbce9e7d596a7513f886547477605f3b28c66022e53975309", - "news/finops-framework-2026/index.html": "41e449b4f367c6513e8f32612b64d8966e9305b61f40311812ac80fb86ad873e", + "news/finops-framework-2026/index.html": "59fa6c3078878dda77cd0a07a84fb79f6b828ca16d1855c1e85593597329506d", "news/index.html": "8fe3c9ac842cb6240f1984a42be140a2108f722418ee57974ce289ab1f5aa1da", - "news/kubernetes-136-resource-allocation/index.html": "fcdb88bee9f79ec3b99a2a10d19b2c79e3ee30e171acc7dfb0dab99a31073824", - "news/kueue-admission-headlamp/index.html": "34fb3705afcfd8954985d8269203864bc4d997dd8ee1839ad3164eceb5b25765", + "news/kubernetes-136-resource-allocation/index.html": "f20529fd09ed37d29c6bc2690b19ff2807a8aed9cbef3421d47a2cdcddc480b7", + "news/kueue-admission-headlamp/index.html": "a5c2c70afe4603d344b30f79e8af5686f0f8d013e4f61379f61f1360f4287936", "practice/index.html": "1c6bf5eb8c2b01f88616c5eab5dff566ed791a5f30f624a43832e65791379ff5", "practice/records/BLD-001-flagship-package.yml": "e4e032c1951df0542acfd69a0a0f20d39e6a7c8b04cfa5279bd5e1d01b6b8f66", "practice/records/CON-001-learning-pathway.yml": "527cbe273a0656d153e9587f13692375318f6bf7ec7ef405acae5014cd817e48", @@ -33,20 +33,20 @@ "resource-loop.svg": "24516aee93835dda1a98fe0a3d1d44c7366ddbfa87f67141ceba71eb4a674d4f", "robots.txt": "93e1d051721cccb2203533406be637394f7dcbdadcafd3b9a09d5e4a23db9605", "schema.json": "d16586e533eebfcb8c9bf76e88ea0924836055d6c616882c72df0a26d31fa107", - "search-index.json": "0421027ae613f3d99ae5721490895ee22b0fd4a64f9c0a09507ded91a0b3c031", + "search-index.json": "3774714abcc1cf9877fbbebc5ef9eeb394a2adddb2a4e938e0bc19c8f2c5aa72", "search.js": "78ae43ce810bd4b6c1b5dc0d052e61f2f6b8e003114c47770e2d4e4302d48d83", "search/index.html": "29760aaaf3eb6d8ae311550de5b4d6496aeb200c9352feffaaf270476b669bf4", - "site.css": "b9c5e2c1cb2461709ecd63c3ecbaee657df4ea5677b66c4a7d243b0449140b7a", + "site.css": "8cf93ced94e9ff4f3c6b4396437b33ccb79b6cc46de643f358b38610c012a02f", "sitemap.xml": "7f07faaee013bae886666a3c4bf29b984829ca22a7d75a23c15ed846173b3a1a", - "sources/index.html": "ae9ec640a618bacf9eaa9f4dd07dd029c2715f9c78d0cdc82cf0c9731101ee9b", - "wiki/agent-orchestration/index.html": "d3d923950a41b45d6b8cc7888cc64b19f10150ce2fc2e3d0375ffab14d0eb167", - "wiki/audit-trails/index.html": "16d16d09e2d55bab18beb724505ac841970d9098d4c88c43bef5b37bff66c77c", - "wiki/autonomous-resource-management/index.html": "49ec6c5db1221c7018dee6381ea553b4e49cb5966bb3c85240b274feffc8d7d6", - "wiki/autoscaling/index.html": "e02ca37aee1239ad883a514acdd09bb40d4540a21cfbe2e51f0f1f1910c32c28", - "wiki/finops-and-cost-controls/index.html": "ab5168590b68e3ec32dc5c0a4eaa7ddb615431426a127e0818c7db0f83c8e148", - "wiki/human-oversight/index.html": "f23ea20fd4d1cfe1313090410225b65e6bbf0b2cd2e55aa1224e333782beed54", - "wiki/index.html": "0032460eb57a856338e9d232adf03314da488aa1aaa4873de7ec8c85559629c8", - "wiki/observability/index.html": "7ed8a2c1da5f8155b482b778d1e958448e7eae49846001f63a56f6093184ded4", - "wiki/resource-scheduling/index.html": "eab2e96dfe0b761a2aa326dd221b61bfa9845363e79ae27b605c663487acd56b" + "sources/index.html": "d496faf341e6ec0864420b066e9657b57388f13ea62d00eeb7b0fa0a9e40c892", + "wiki/agent-orchestration/index.html": "67aafb5d3c48aa67063662f3c1cdf9e04137c20bcd3dcc1519bb7003519142b1", + "wiki/audit-trails/index.html": "148d7bc983ba16d7bf055f8549a5b3606df8718d657db1f06e935c90a55b7515", + "wiki/autonomous-resource-management/index.html": "be7d1499726f848639e015fb1da74a56ba9f3c83a2fa28c61bb4b4fefb92634b", + "wiki/autoscaling/index.html": "49e87f4a4778ebe245edbcc8da9ff1aae86cf6b9a77c2cf3ba478781c0c11bc7", + "wiki/finops-and-cost-controls/index.html": "8ce73ceb2ebe5ecce7b63fa682eb356cf0cc8d0cc911bd4fb748f8cff2e404fd", + "wiki/human-oversight/index.html": "ad4b538ddd2ea2afe718725a4925f0a97f1c49f2f6174189e892908c43ff5416", + "wiki/index.html": "795e79014eeee71c6910e4929afb671bfb70b4b146dcd8af44a7c44033c05e29", + "wiki/observability/index.html": "e1f43e8ed68a8f7d7b36f066ebd227b62db65c85ce549798f1b9d34e0c37e402", + "wiki/resource-scheduling/index.html": "b1075a6e0fa65d2f1d128a6471746419f6179433729756586f03b79b580a9318" } } diff --git a/scripts/audit-links.py b/scripts/audit-links.py new file mode 100644 index 0000000..37ab089 --- /dev/null +++ b/scripts/audit-links.py @@ -0,0 +1,101 @@ +"""Audit the generated reference with Python's standard library; no external service.""" +from collections import deque +from html.parser import HTMLParser +from pathlib import Path +from urllib.parse import urljoin, urlsplit, unquote +import json + +ORIGIN = 'https://autonomousresourcemanagement.com' + +class Page(HTMLParser): + def __init__(self, html): + super().__init__(convert_charrefs=True) + self.links, self.ids, self.canonical = [], set(), None + self.indexable, self.in_main, self.in_article = True, False, False + self.anchor = None + self.feed(html) + + def handle_starttag(self, tag, attrs): + a = dict(attrs) + if 'id' in a: + self.ids.add(a['id']) + if tag == 'main': self.in_main = True + if tag == 'article': self.in_article = True + if tag == 'link' and a.get('rel') == 'canonical': self.canonical = a.get('href') + if tag == 'meta' and a.get('name') == 'robots': + self.indexable = 'noindex' not in a.get('content', '') + if tag == 'a' and 'href' in a: + self.anchor = {'href': a['href'], 'text': '', 'main': self.in_main, 'article': self.in_article} + if tag == 'img' and self.anchor: + self.anchor['text'] += a.get('alt', '') + + def handle_data(self, data): + if self.anchor is not None: self.anchor['text'] += data + + def handle_endtag(self, tag): + if tag == 'a' and self.anchor is not None: + self.links.append(self.anchor) + self.anchor = None + if tag == 'main': self.in_main = False + if tag == 'article': self.in_article = False + +def audit(root): + pages = {} + for file in sorted(root.rglob('index.html')): + route = '/' + file.relative_to(root).as_posix().removesuffix('index.html') + pages[route] = Page(file.read_text()) + errors, edges, contextual = [], {}, {} + for route, page in pages.items(): + edges[route] = set() + if page.canonical != ORIGIN + route: + errors.append(f'{route}: non-self canonical {page.canonical}') + for link in page.links: + url = urlsplit(urljoin(ORIGIN + route, link['href'])) + if url.netloc != urlsplit(ORIGIN).netloc: continue + target = unquote(url.path) + file = root / target.lstrip('/') + if target.endswith('/'): file /= 'index.html' + if not file.is_file(): + errors.append(f'{route}: broken internal link {link["href"]}') + continue + if target.endswith('.html') and target != '/404.html' and not target.startswith('/google'): + errors.append(f'{route}: link to HTML alias instead of canonical route: {target}') + if url.fragment: + ids = pages[target].ids if target in pages else Page(file.read_text()).ids + if unquote(url.fragment) not in ids: + errors.append(f'{route}: missing fragment {link["href"]}') + if target not in pages or target == route: continue + if not link['text'].strip(): errors.append(f'{route}: empty anchor to {target}') + if url.scheme != 'https' or url.query: + errors.append(f'{route}: noncanonical internal URL {link["href"]}') + edges[route].add(target) + if link['article']: + contextual.setdefault(target, set()).add(route) + distance = {'/': 0} + queue = deque(['/']) + while queue: + source = queue.popleft() + for target in edges.get(source, set()): + if target not in distance: + distance[target] = distance[source] + 1 + queue.append(target) + rows = [] + for route, page in pages.items(): + if not page.indexable: continue + incoming = sorted(source for source, targets in edges.items() if route in targets and pages[source].indexable) + depth = distance.get(route) + if route != '/' and not incoming: errors.append(f'{route}: orphaned indexable page') + if depth is None or depth > 3: errors.append(f'{route}: exceeds three-click navigation budget ({depth})') + body_sources = sorted(contextual.get(route, set())) + if route.startswith('/wiki/') and route != '/wiki/' and not body_sources: + errors.append(f'{route}: no contextual article inlink') + rows.append({'path': route, 'depth': depth, 'inlinks': incoming, 'contextualInlinks': body_sources}) + return {'pages': rows, 'errors': errors} + +if __name__ == '__main__': + report = audit(Path('dist')) + Path('test-results').mkdir(exist_ok=True) + Path('test-results/internal-links.json').write_text(json.dumps(report, indent=2) + '\n') + if report['errors']: + raise SystemExit('\n'.join(report['errors'])) + print(f"Internal-link audit: {len(report['pages'])} indexable pages; no orphans, canonical-link defects, or broken fragments; maximum depth {max(p['depth'] for p in report['pages'])}.") diff --git a/scripts/build.mjs b/scripts/build.mjs index 1bf2cef..732db1b 100644 --- a/scripts/build.mjs +++ b/scripts/build.mjs @@ -3,9 +3,14 @@ import path from 'node:path'; import crypto from 'node:crypto'; import { readContent, renderMarkdown, origin, repo, escape as e } from './content.mjs'; +import { loadTopics } from './topics.mjs'; + const all=readContent(), articles=all.filter(a=>a.status==='published'); const wiki=articles.filter(a=>a.kind==='wiki'); const news=articles.filter(a=>a.kind==='news').sort((a,b)=>b.published.localeCompare(a.published)||b.eventDate.localeCompare(a.eventDate)); +const topics=loadTopics(articles); +const topicFor=a=>topics.find(t=>t.entries.some(entry=>entry.path===a.path)); +const topicLinks=()=>topics.map(t=>`
    • ${e(t.title)}

      ${e(t.question)}

      • `).join(''); const revision=articles.map(a=>a.updated).sort().at(-1); const routes=new Map(); const schemaBase=[ @@ -18,7 +23,7 @@ function shell(title,description,route,body,{schema=[],noindex=false,search=fals const graph={'@context':'https://schema.org','@graph':[...schemaBase,...schema]}; return ` ${e(title)} | Autonomous Resource Management${search?'':''} -
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      +
      Autonomous Resource
      ManagementKnowledge · Context · Evidence
      ${body}
      \n`; } @@ -30,6 +35,7 @@ const label=a=>a.kind==='news'?'Source brief':a.kind==='framework'?'Editorial pr function card(a,i) {return `
      ${String(i+1).padStart(2,'0')} / ${e(label(a))}

      ${e(a.title)}

      ${e(a.description)}

      ${a.kind==='news'?`Source event: ${a.eventDate} · Brief: ${a.published}`:'Definition, context & limitations'}
      `;} add('/','Autonomous resource management: wiki and industry context','Explore source-backed explanations of autonomous resource management, resource allocation, orchestration, cost controls, and oversight.',`
      The autonomous resource management reference

      Autonomous resource
      management, explained.

      A knowledge resource for how automated systems allocate resources—and how people keep those decisions accountable.

      Start with the fundamentals →Explore the wiki
      +

      Explore by question

        ${topicLinks()}

      The reference library

      All ${wiki.length} reference articles →
      ${wiki.filter(a=>a.path!='/wiki/autonomous-resource-management/').slice(0,6).map(card).join('')}

      Industry context

      Browse source briefs →

      Dated developments, their implications, and what the evidence does not establish.

      ${news.map(card).join('')}
      From concepts to questions

      What can this system decide?

      Start with the action, its limits, the evidence behind it, and who can intervene. The ARM working framework offers one attributed proposal for organizing those questions.

      Read the working framework →
      An inspectable reference

      Follow the source.

      Articles identify their evidence, distinguish examples from findings, and link to revision history. Corrections and additional perspectives are welcome.

      Improve this resource →
      @@ -37,13 +43,18 @@ add('/','Autonomous resource management: wiki and industry context','Explore sou for(const a of articles){ const {html,headings}=renderMarkdown(a.body); const schema=[{'@type':a.kind==='news'?'NewsArticle':a.kind==='page'?'WebPage':'TechArticle','@id':origin+a.path+'#article',url:origin+a.path,headline:a.title,description:a.description,dateModified:a.updated,...(a.published?{datePublished:a.published}:{}),author:a.author.startsWith('Mason')?{'@id':origin+'/about/#maintainer'}:{'@id':origin+'/#publisher'},publisher:{'@id':origin+'/#publisher'},isPartOf:{'@id':origin+'/#website'},citation:(a.sources||[]).map(s=>({'@type':'CreativeWork',name:s.title,url:s.url}))}]; + const topic=topicFor(a); + const parent=a.kind==='wiki'?['/wiki/','Wiki']:a.kind==='news'?['/news/','News']:null; + const breadcrumb=``; + const relatedNews=news.filter(n=>n.concepts.includes(a.path)).slice(0,3); + const continuation=a.kind==='wiki'?`

      Continue reading

      Explore ${e(topic.title.toLowerCase())}: ${e(topic.question)}

      ${a.path!='/wiki/autonomous-resource-management/'?'

      For the wider context, read what autonomous resource management means.

      ':''}${relatedNews.length?`

      Related source briefs

      Dated project developments; these do not independently validate the concepts above.

        ${relatedNews.map(n=>`
      • ${e(n.title)}
        Source event: ${n.eventDate}
        • `).join('')}
      `:''}
      `:''; const sources=(a.sources||[]).length?`

      Sources and scope

        ${a.sources.map(s=>`
      1. ${e(s.title)}${e(s.scope)}
        2. `).join('')}
      `:''; - add(a.path,a.title,a.description,`
      Home / ${a.kind==='wiki'?'Wiki':a.kind==='news'?'News':'Reference'}
      ${label(a)}

      ${e(a.title)}

      ${e(a.description)}

      ${e(a.author)} · Updated ${a.kind==='news'?`
      Source event: ${a.eventDate} · Brief published: ${a.published} · Source checked: ${a.checked}`:''}

      ${a.kind!=='page'?`

      ${e(a.review)}

      `:''}
      `,{schema,updated:a.updated}); + add(a.path,a.title,a.description,`
      ${breadcrumb}${label(a)}

      ${e(a.title)}

      ${e(a.description)}

      ${e(a.author)} · Updated ${a.kind==='news'?`
      Source event: ${a.eventDate} · Brief published: ${a.published} · Source checked: ${a.checked}`:''}

      ${a.kind!=='page'?`

      ${e(a.review)}

      `:''}
      `,{schema,updated:a.updated}); } -add('/wiki/','Reference library','Browse foundational concepts in autonomous resource management.',`
      Wiki / ${wiki.length} articles

      The reference library

      Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

      What is autonomous resource management? →
      ${wiki.map(card).join('')}
      `); +add('/wiki/','Reference library','Browse foundational concepts in autonomous resource management.',`
      Wiki / ${wiki.length} articles

      The reference library

      Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

      What is autonomous resource management? →
      ${topics.map(t=>`
      ${e(t.question)}

      ${e(t.title)}

      ${e(t.description)}

      ${t.entries.map(card).join('')}
      `).join('')}`); add('/news/','Industry news and source briefs','Dated developments in resource management, with source attribution and evidence limits.',`
      Industry context

      Developments, in context.

      Source briefs connect industry changes to the reference library. Event dates and publication dates are shown separately; background coverage is not breaking news.

      Subscribe via RSS · Our news policy

      ${news.length?news.map(a=>`
      Source brief · source event ${a.eventDate}

      ${e(a.title)}

      ${e(a.description)}

      Published ${a.published} · ${e(a.review)}

      `).join(''):'

      The first source briefs are in preparation. Browse the wiki for established concepts.

      '}`); const sources=[...new Map(articles.flatMap(a=>a.sources||[]).map(s=>[s.url,s])).values()]; -add('/sources/','Sources and evidence','The primary documentation and announcements cited by this reference.',`
      Evidence directory

      Start with the source.

      Documentation supports descriptions of a system. Announcements establish what a publisher reports. Neither alone proves performance in your environment.

      Source selection

      These are cited sources, not endorsements or an exhaustive industry list. The initial library emphasizes infrastructure documentation. Broader research and independently evaluated case studies are an editorial priority.

        ${sources.map(s=>`
      1. ${e(s.title)}${e(s.scope)}
        2. `).join('')}

      Suggest additional evidence

      We welcome relevant research, alternative approaches, and reproducible failure reports. Propose a source with the claim it supports or challenges.

      `); +add('/sources/','Sources and evidence','The primary documentation and announcements cited by this reference.',`
      Evidence directory

      Start with the source.

      Documentation supports descriptions of a system. Announcements establish what a publisher reports. Neither alone proves performance in your environment.

      Source selection

      These are cited sources, not endorsements or an exhaustive industry list. The initial library emphasizes infrastructure documentation. Broader research and independently evaluated case studies are an editorial priority.

        ${sources.map(s=>`
      1. ${e(s.title)}${e(s.scope)}

        Used in: ${articles.filter(a=>(a.sources||[]).some(source=>source.url===s.url)).map(a=>`${e(a.title)}`).join('; ')}.

        2. `).join('')}

      Suggest additional evidence

      We welcome relevant research, alternative approaches, and reproducible failure reports. Propose a source with the claim it supports or challenges.

      `); add('/search/','Search the reference','Find concepts and source briefs in the ARM reference.',`
      Find a concept

      Search the reference

      Loading the reference index…

        `,{search:true,noindex:true}); add('/404/','Page not found','Find the reference page you need.',`
        404 / Page not found

        Let’s find the right page.

        This address is not part of the current reference.

        Browse the wikiSearch the reference
        `,{noindex:true}); // Output is an explicit publishing boundary; archives and subdomain content never enter it. diff --git a/scripts/topics.mjs b/scripts/topics.mjs new file mode 100644 index 0000000..a4397f4 --- /dev/null +++ b/scripts/topics.mjs @@ -0,0 +1,29 @@ +import fs from 'node:fs'; +import assert from 'node:assert/strict'; + +export function loadTopics(articles) { + const topics=JSON.parse(fs.readFileSync('editorial/topics.json','utf8')); + const wiki=articles.filter(a=>a.kind==='wiki'); + const seen=new Set(), ids=new Set(); + for(const topic of topics) { + assert(/^[a-z0-9-]+$/.test(topic.id) && !ids.has(topic.id),'Invalid or duplicate topic ID'); + ids.add(topic.id); + assert(topic.title && topic.question && topic.description && topic.articles.length,'Incomplete topic'); + topic.entries=topic.articles.map(slug=>{ + const entry=wiki.find(a=>a.path===`/wiki/${slug}/`); + assert(entry && !seen.has(entry.path),`Missing or duplicate topic article: ${slug}`); + seen.add(entry.path); + return entry; + }); + } + assert.equal(seen.size,wiki.length,'Every published wiki article needs a primary topic'); + for(const item of articles.filter(a=>a.kind==='news')) { + assert(Array.isArray(item.concepts) && item.concepts.length,'News needs related concepts'); + assert.equal(new Set(item.concepts).size,item.concepts.length,'Duplicate news concepts'); + for(const target of item.concepts) { + assert(seen.has(target),`News concept must be a published wiki article: ${target}`); + assert(item.body.includes(`](${target})`),`News concept needs an explanatory body link: ${target}`); + } + } + return topics; +} diff --git a/search-index.json b/search-index.json index 610b032..f2bb012 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"title":"FinOps Framework 2026 adds strategy alignment and broader technology guidance","description":"A background brief on the March framework revision and its relevance to resource-management objectives.","path":"/news/finops-framework-2026/","text":" What changed\nThe FinOps Foundation’s [19 March 2026 framework update]() introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.\n\nThis brief covers that published revision as background, rather than presenting the March announcement as new today.\n\n Why it matters\nEditorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.\n\nRead [FinOps and cost controls](/wiki/finops-and-cost-controls/) for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. [Human oversight](/wiki/human-oversight/) explains why a budget boundary also needs an accountable owner.\n\n Limits of the evidence\nThis is the framework publisher’s description of its own update. It does not establish adoption rates, measured savings, or the effectiveness of any automated product. The implications for resource-control design above are editorial interpretation, not a benchmark result or a requirement imposed by the Foundation.\n"},{"title":"Kubernetes 1.36 expands Dynamic Resource Allocation","description":"A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.","path":"/news/kubernetes-136-resource-allocation/","text":" What changed\nIn its [7 May 2026 update](), the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.\n\nThis is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.\n\n Why it matters\nEditorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.\n\nA useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See [resource scheduling](/wiki/resource-scheduling/) for the distinction between eligible capacity and preferred capacity.\n\n Limits of the evidence\nThe source is a project announcement. This brief does not independently test the features, establish compatibility with a specific cluster, or substantiate performance gains. Check the documentation and feature state for the exact version and driver being evaluated.\n\nThe announcement is evidence of reported project changes, not evidence that every resource-management deployment should adopt them.\n"},{"title":"Headlamp guide separates Kueue admission from Pod scheduling","description":"An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.","path":"/news/kueue-admission-headlamp/","text":" What changed\nA [14 October 2026 Kubernetes project guide]() describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.\n\nThe guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.\n\n Why it matters\nEditorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.\n\nThis distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See [resource scheduling](/wiki/resource-scheduling/) and [observability](/wiki/observability/) for related concepts.\n\n Limits of the evidence\nThis is a summary of a project-authored guide, not an independent evaluation. The plugin is identified as alpha in the source. This brief does not test compatibility, measure troubleshooting speed, or establish that a particular cluster has an admission problem.\n\nRead the original guide for prerequisites and version-specific details before applying its procedure.\n"},{"title":"About this reference","description":"Purpose, authorship, editorial boundaries, and how this resource is maintained.","path":"/about/","text":" A reference for resource decisions\nThis site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.\n\nThe project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.\n\n Maintainer and authorship\nMason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.\n\nThe proposed [ARM working framework](/framework/) is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.\n\n Commercial boundaries\nThis reference has no service checkout or commercial referral directory. Earlier versions directed readers to implementation businesses. The standalone revision removes those pathways while retaining accountable authorship. Removing referrals should not be read as a claim that the maintainer has no outside commercial interests.\n\nRelevant affiliations must be disclosed when they affect a covered subject. See the [editorial policy](/editorial-policy/) for the conflict-of-interest rule.\n\n Maintenance and accountability\nReaders can propose source additions and corrections through [GitHub](). Changes are versioned, and material editorial changes are summarized in the [revision log](/changelog/).\n\nThe wiki is curated rather than open to immediate anonymous publication. Contributions are welcome; publication depends on evidence, relevance, and editorial review.\n\n Historical work records\nThe earlier [public-practice records](/practice/) remain available as historical, first-party work records. They are not independent validation of this reference, product recommendations, or evidence of industry consensus.\n"},{"title":"Revision log","description":"Material changes to the reference, its scope, and editorial practices.","path":"/changelog/","text":" 15 October 2026 — standalone reference revision\n- Reframed the homepage around a source-backed knowledge library.\n- Removed commercial implementation referrals from the reference site's publishing model.\n- Moved the attributed ARM proposal to a dedicated framework page.\n- Added eight introductory wiki articles, source descriptions, and explicit AI-assistance disclosures.\n- Added an editorial policy, correction route, search, and news discovery workflow.\n- Replaced absolute recovery and audit guarantees with implementation-dependent qualifications.\n\nThese entries describe the content revision. Repository history records the exact changes; the deployment record identifies when the revision reaches the public site.\n\n Earlier material\nThe previous homepage and its edits remain available in [repository history](). Its framework has been revised rather than presented as an established industry standard.\n"},{"title":"Contribute or request a correction","description":"A practical route for improving definitions, citations, examples, and industry coverage.","path":"/contribute/","text":" Suggest a factual correction\n[Open a correction request]() with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.\n\nGitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.\n\n Contribute an article\nUse the [public repository]() to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.\n\nDisclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.\n\n Suggest industry coverage\n[Suggest a source or story](). Include the original announcement or research, its date, and the resource-management question it affects. A suggestion does not guarantee coverage.\n\n How changes are reviewed\nSubmissions are checked for factual support, neutral wording, relevant scope, and clear limitations. Technical checks validate internal links and required article metadata. Passing those checks is not a substitute for editorial judgment.\n\nThe maintainer decides whether to publish. Material corrections are recorded in the [revision log](/changelog/), and each article links to its source history.\n"},{"title":"Editorial policy","description":"How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.","path":"/editorial-policy/","text":" Purpose and scope\nAutonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.\n\n Neutral point of view\nDescribe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.\n\nSeparate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.\n\n Source standards\nPrefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.\n\nFor claims of effectiveness, seek reproducible evidence and independent evaluation where available. Identify preprints, vendor benchmarks, and conflicts of interest. Cite evidence near the claim and explain each source's scope in the references.\n\n News and review\nNews briefs distinguish the date of the source event from this site's publication date. Each brief explains what changed, why it may matter, and the limits of the evidence. Older developments may be covered as background; they must not be presented as breaking news.\n\nAutomated discovery places candidates in an editorial queue. It does not publish articles. Before publication, an editor checks the original source, dates, attribution, scope, related wiki entries, and correction needs. The publication record identifies whether the source check was human or AI-assisted. Do not imply independent testing or expert review when neither occurred.\n\n AI assistance\nAI may assist with discovery, drafting, source comparison, and maintenance. Launch articles disclose AI-assisted source synthesis. No invented human reviewer, interview, test result, or credential may be added. A maintainer remains responsible for accepting and correcting published content.\n\n Ownership and conflicts\nThe site is maintained by Mason Nguyen. The previous homepage linked to commercial implementation properties; those referral paths have been removed from the reference site's navigation and content model. This change does not establish independent ownership or erase relevant affiliations.\n\nContributors must disclose a relevant commercial relationship when covering an affiliated product or organization. The site does not sell favorable coverage, rankings, or placement in its reference articles. Author attribution is retained.\n\n Corrections and revision dates\nReport a correction through the [contribution page](/contribute/). Include the URL, disputed passage, and evidence. Material factual corrections receive a visible note and a revision-history entry. Update dates change for substantive edits, not to create an appearance of freshness.\n\n Reuse and attribution\nSummarize sources in original language and link to the original. Do not reproduce full third-party articles or images without permission. Source code visibility does not grant rights to third-party material. This site makes no blanket open-content licensing claim.\n"},{"title":"The ARM working framework","description":"An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.","path":"/framework/","text":" Status and authorship\nThis working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.\n\nEarlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.\n\n Five design concerns\n Decision rights\nIdentify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.\n\n Observable signals\nRecord the measurements and assumptions used in a decision. [OpenTelemetry's signal vocabulary]() is relevant background for instrumentation, not an endorsement of this framework.\n\n Recoverable state\nDefine how interrupted work is identified and recovered. Checkpoints and durable records can help, but their guarantees depend on implementation. This framework does not promise recovery from every failure mode or zero data loss.\n\n Human escalation\nDefine the conditions that require review and the action taken while review is pending. [NIST's AI risk-management work]() supplies broader context; these five concerns are not NIST's categories.\n\n Auditable decisions\nConnect requests, permission, execution, and observed results. Use precise descriptions of retention and tamper resistance instead of assuming a log is immutable.\n\n Applying the proposal\nFor a hypothetical resource controller, write down one permitted action, one limit, its input signal, its recovery behavior, and its escalation owner. Then test a missing signal, a rejected allocation, and an uncertain result.\n\nThis exercise is an editorial method for revealing assumptions. It does not establish that a system is safe, optimal, or compliant.\n\n What would strengthen the framework\nIndependent critique, reproducible examples, failure reports, and comparisons with alternative designs would make the proposal more useful. Contributions should identify which claim they support or challenge. Use the [contribution guide](/contribute/) to propose a change.\n\n Related reference material\nStart with [autonomous resource management](/wiki/autonomous-resource-management/), [human oversight](/wiki/human-oversight/), and [audit trails](/wiki/audit-trails/). Search visibility and structured publishing are separate concerns; they are not prerequisites for a working resource controller.\n"},{"title":"Agent orchestration and tool access","description":"Coordinating work while keeping authority, retries, and external actions explicit.","path":"/wiki/agent-orchestration/","text":" Coordination and authority\nAgent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget.\n\nAn orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.\n\n Protocols have a specific scope\nThe [Model Context Protocol architecture, revision 2025-06-18](), describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.\n\nProtocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.\n\n A bounded workflow example\nImagine an agent that proposes resizing a service. A useful separation is:\n\n1. Collect current workload and cost evidence.\n2. Produce a proposal with assumptions and an expiry time.\n3. Check permitted resources, spending limits, and required approval.\n4. Execute the approved action with an operation identifier.\n5. Inspect the actual outcome and record failures or partial completion.\n\nThis is an editorial design example, not a required protocol workflow.\n\n Retries and uncertainty\nA timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.\n\nRelated reading: [human oversight](/wiki/human-oversight/), [audit trails](/wiki/audit-trails/), and the proposed [ARM working framework](/framework/).\n"},{"title":"Audit trails and decision provenance","description":"Recording what was requested, authorized, executed, and observed.","path":"/wiki/audit-trails/","text":" What an audit trail can establish\nAn audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result.\n\n[Kubernetes auditing]() provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.\n\n Design around questions\nAn editorial starting point is to ask whether a reviewer can determine:\n\n1. Who or what requested the change?\n2. Which policy or approval permitted it?\n3. Which measurements were available at the time?\n4. Was the action attempted, completed, rejected, or left uncertain?\n5. What subsequent evidence confirms the outcome?\n\nUse identifiers to connect related events. Keep the original event time distinct from the time a record was received or reviewed.\n\n Integrity and privacy\n“Immutable” is a strong claim. Retention rules, access restrictions, integrity checks, and independent copies provide different protections. State the protections actually implemented rather than assuming that a logging product makes records tamper-proof.\n\nLogs can also contain sensitive information. Decide what is necessary to retain, who can access it, and how long it remains useful. An exhaustive transcript is not automatically the best audit record.\n\n Limits\nA record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.\n\nCombine audit evidence with [observability](/wiki/observability/) and [human review](/wiki/human-oversight/). Claims about system reliability need tests and operational evidence beyond the existence of logs.\n"},{"title":"What is autonomous resource management?","description":"A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.","path":"/wiki/autonomous-resource-management/","text":" Definition and scope\nAutonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.\n\nA useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.\n\n How the pieces fit together\nA resource-management design needs a target, measurements, a decision mechanism, and a way to act. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](). The broader connection to ARM is our editorial synthesis.\n\nConsider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.\n\n Related disciplines\n- [Autoscaling](/wiki/autoscaling/) changes capacity in response to signals.\n- [Resource scheduling](/wiki/resource-scheduling/) decides where work can run.\n- [Orchestration](/wiki/agent-orchestration/) coordinates dependent work and tool interactions.\n- [FinOps and cost controls](/wiki/finops-and-cost-controls/) connect resource use to financial accountability. The [FinOps Framework]() describes an operating practice that involves engineering, finance, and business participants.\n- [Human oversight](/wiki/human-oversight/) addresses authority, review, and intervention.\n\n Boundaries and open questions\nThe appropriate degree of autonomy depends on the reversibility of an action, the reliability of its evidence, and the people affected. A low-risk scaling decision and an irreversible spending commitment should not be treated as equivalent.\n\nThe [ARM working framework](/framework/) offers one proposed way to organize these questions. Its five design concerns are an attributed synthesis rather than an industry standard or a prerequisite for every automated resource system.\n"},{"title":"Autoscaling and feedback loops","description":"How capacity follows demand, and why signals, limits, and recovery matter.","path":"/wiki/autoscaling/","text":" What autoscaling changes\nAutoscaling adjusts capacity in response to observed or anticipated demand. The [Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling](). Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.\n\nChoosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it.\n\n Signals and decisions\nA controller compares measurements with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.\n\nFor a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.\n\n Tradeoffs to evaluate\n- Responsiveness: a fast reaction can reduce waiting but may chase short-lived noise.\n- Stability: frequent opposing adjustments can interrupt work or waste capacity.\n- Cost: spare capacity can improve response time while increasing spend.\n- Availability: a request to scale does not prove that capacity was obtained.\n\nReview these tradeoffs together. [Cost controls](/wiki/finops-and-cost-controls/) and [observability](/wiki/observability/) make the operating consequences easier to inspect.\n\n Failure and recovery\nSpecify the response to stale metrics, failed allocations, quota exhaustion, and interrupted scale-down. Test those responses against the actual workload. A controller should not interpret missing demand data as proof that demand is zero.\n\nThe underlying loop is described in [Kubernetes controller concepts](). Applying that pattern to a particular service still requires workload-specific measurement and testing.\n"},{"title":"FinOps and cost controls","description":"Relating resource consumption, budgets, and business outcomes without assuming automatic savings.","path":"/wiki/finops-and-cost-controls/","text":" Financial accountability\nThe [FinOps Framework]() brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.\n\nA useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.\n\n Design the budget boundary\nFor a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.\n\nA cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.\n\n Resource limits are not currency limits\n[Kubernetes resource quotas]() can constrain resource requests or object counts. Their units and scope differ from a bill denominated in currency. Translating a resource allowance into a cost expectation requires pricing assumptions and usage context.\n\n Evaluate claims carefully\nWhen someone reports savings, ask which baseline, workload, period, prices, and service-quality targets were used. Distinguish a projected saving from an observed reduction in paid costs. A lower cost per operation can coexist with higher total spend if demand grows.\n\nThese evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.\n\nRelated: [autoscaling](/wiki/autoscaling/), [resource scheduling](/wiki/resource-scheduling/), and [observability](/wiki/observability/).\n"},{"title":"Human oversight and decision rights","description":"Defining who can authorize, interrupt, and review automated resource decisions.","path":"/wiki/human-oversight/","text":" Oversight needs an operational meaning\nHuman oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.\n\nThe [NIST AI Risk Management Framework]() provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.\n\n Define the delegated scope\nAs an editorial design checklist, document:\n\n- Which resources and actions the system may control.\n- The limits on amount, duration, and frequency.\n- Which actions need approval before execution.\n- Who can pause the system and revoke access.\n- How an operator learns about a failed or incomplete action.\n\nSeparate permission from confidence. A system can be highly confident about an action it is not authorized to take.\n\n Escalation example\nA hypothetical workflow may automatically add a small amount of reversible capacity, require approval for a larger change, and refuse to make an irreversible commitment without explicit authorization. If the approver is unavailable, the policy must specify whether to wait, retain the existing state, or follow another documented fallback.\n\nSilence should not be interpreted as newly granted authority. This is the site's design recommendation, not a quoted NIST requirement.\n\n Review and learning\nAfter a consequential event, compare the authorized action, the recorded action, and the observed outcome. Update the policy when evidence shows that an assumption was wrong. Document unresolved questions as well as successes.\n\nRelated: [agent orchestration](/wiki/agent-orchestration/), [audit trails](/wiki/audit-trails/), and [the proposed ARM framework](/framework/).\n"},{"title":"Observability for resource decisions","description":"Connecting measurements to actions without mistaking telemetry for proof of correctness.","path":"/wiki/observability/","text":" Observe the system and its decisions\nObservability helps operators investigate system behavior from available evidence. [OpenTelemetry describes signals such as traces, metrics, and logs](), which offer different views of system activity.\n\nFor resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.\n\n A useful decision record\nAs editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.\n\nSeparate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.\n\n Evidence quality\nA signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric to control resources, define how old it may be and how the system should behave when the data is unavailable.\n\nFor example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default.\n\n Limits\nTelemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.\n\nUse [audit trails](/wiki/audit-trails/) to preserve decision context and [human oversight](/wiki/human-oversight/) to define who responds when evidence is insufficient.\n"},{"title":"Resource scheduling and allocation","description":"Placement decisions, competing objectives, and the difference between capacity and usable capacity.","path":"/wiki/resource-scheduling/","text":" What a scheduler decides\nA scheduler matches work to eligible resources. It has to respect constraints before considering preferences. [Kubernetes describes filtering candidate nodes and scoring the feasible ones]().\n\nScheduling is distinct from scaling. A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.\n\n Constraints before preferences\nIn a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.\n\nRecord which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.\n\n Questions for an allocation policy\n1. Which workloads can wait, and for how long?\n2. Can lower-priority work be interrupted without losing progress?\n3. How is scarce capacity shared between teams?\n4. What happens when no eligible resource exists?\n5. What evidence explains a rejected or delayed allocation?\n\nThese questions are editorial design guidance. Answers need to be validated against the workload and the resource provider.\n\n Limits and related concepts\n[Resource quotas]() constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.\n\nRead [autoscaling](/wiki/autoscaling/) for capacity adjustments and [audit trails](/wiki/audit-trails/) for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.\n"}] \ No newline at end of file +[{"title":"FinOps Framework 2026 adds strategy alignment and broader technology guidance","description":"A background brief on the March framework revision and its relevance to resource-management objectives.","path":"/news/finops-framework-2026/","text":" What changed\nThe FinOps Foundation’s [19 March 2026 framework update]() introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.\n\nThis brief covers that published revision as background, rather than presenting the March announcement as new today.\n\n Why it matters\nEditorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.\n\nRead [FinOps and cost controls](/wiki/finops-and-cost-controls/) for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. [Human oversight](/wiki/human-oversight/) explains why a budget boundary also needs an accountable owner.\n\n Limits of the evidence\nThis is the framework publisher’s description of its own update. It does not establish adoption rates, measured savings, or the effectiveness of any automated product. The implications for resource-control design above are editorial interpretation, not a benchmark result or a requirement imposed by the Foundation.\n"},{"title":"Kubernetes 1.36 expands Dynamic Resource Allocation","description":"A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.","path":"/news/kubernetes-136-resource-allocation/","text":" What changed\nIn its [7 May 2026 update](), the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.\n\nThis is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.\n\n Why it matters\nEditorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.\n\nA useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See [resource scheduling](/wiki/resource-scheduling/) for the distinction between eligible capacity and preferred capacity.\n\n Limits of the evidence\nThe source is a project announcement. This brief does not independently test the features, establish compatibility with a specific cluster, or substantiate performance gains. Check the documentation and feature state for the exact version and driver being evaluated.\n\nThe announcement is evidence of reported project changes, not evidence that every resource-management deployment should adopt them.\n"},{"title":"Headlamp guide separates Kueue admission from Pod scheduling","description":"An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.","path":"/news/kueue-admission-headlamp/","text":" What changed\nA [14 October 2026 Kubernetes project guide]() describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.\n\nThe guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.\n\n Why it matters\nEditorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.\n\nThis distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See [resource scheduling](/wiki/resource-scheduling/) and [observability](/wiki/observability/) for related concepts.\n\n Limits of the evidence\nThis is a summary of a project-authored guide, not an independent evaluation. The plugin is identified as alpha in the source. This brief does not test compatibility, measure troubleshooting speed, or establish that a particular cluster has an admission problem.\n\nRead the original guide for prerequisites and version-specific details before applying its procedure.\n"},{"title":"About this reference","description":"Purpose, authorship, editorial boundaries, and how this resource is maintained.","path":"/about/","text":" A reference for resource decisions\nThis site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.\n\nThe project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.\n\n Maintainer and authorship\nMason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.\n\nThe proposed [ARM working framework](/framework/) is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.\n\n Commercial boundaries\nThis reference has no service checkout or commercial referral directory. Earlier versions directed readers to implementation businesses. The standalone revision removes those pathways while retaining accountable authorship. Removing referrals should not be read as a claim that the maintainer has no outside commercial interests.\n\nRelevant affiliations must be disclosed when they affect a covered subject. See the [editorial policy](/editorial-policy/) for the conflict-of-interest rule.\n\n Maintenance and accountability\nReaders can propose source additions and corrections through [GitHub](). Changes are versioned, and material editorial changes are summarized in the [revision log](/changelog/).\n\nThe wiki is curated rather than open to immediate anonymous publication. Contributions are welcome; publication depends on evidence, relevance, and editorial review.\n\n Historical work records\nThe earlier [public-practice records](/practice/) remain available as historical, first-party work records. They are not independent validation of this reference, product recommendations, or evidence of industry consensus.\n"},{"title":"Revision log","description":"Material changes to the reference, its scope, and editorial practices.","path":"/changelog/","text":" 15 October 2026 — standalone reference revision\n- Reframed the homepage around a source-backed knowledge library.\n- Removed commercial implementation referrals from the reference site's publishing model.\n- Moved the attributed ARM proposal to a dedicated framework page.\n- Added eight introductory wiki articles, source descriptions, and explicit AI-assistance disclosures.\n- Added an editorial policy, correction route, search, and news discovery workflow.\n- Replaced absolute recovery and audit guarantees with implementation-dependent qualifications.\n\nThese entries describe the content revision. Repository history records the exact changes; the deployment record identifies when the revision reaches the public site.\n\n Earlier material\nThe previous homepage and its edits remain available in [repository history](). Its framework has been revised rather than presented as an established industry standard.\n"},{"title":"Contribute or request a correction","description":"A practical route for improving definitions, citations, examples, and industry coverage.","path":"/contribute/","text":" Suggest a factual correction\n[Open a correction request]() with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.\n\nGitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.\n\n Contribute an article\nUse the [public repository]() to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.\n\nDisclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.\n\n Suggest industry coverage\n[Suggest a source or story](). Include the original announcement or research, its date, and the resource-management question it affects. A suggestion does not guarantee coverage.\n\n How changes are reviewed\nSubmissions are checked for factual support, neutral wording, relevant scope, and clear limitations. Technical checks validate internal links and required article metadata. Passing those checks is not a substitute for editorial judgment.\n\nThe maintainer decides whether to publish. Material corrections are recorded in the [revision log](/changelog/), and each article links to its source history.\n"},{"title":"Editorial policy","description":"How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.","path":"/editorial-policy/","text":" Purpose and scope\nAutonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.\n\n Neutral point of view\nDescribe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.\n\nSeparate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.\n\n Source standards\nPrefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.\n\nFor claims of effectiveness, seek reproducible evidence and independent evaluation where available. Identify preprints, vendor benchmarks, and conflicts of interest. Cite evidence near the claim and explain each source's scope in the references.\n\n News and review\nNews briefs distinguish the date of the source event from this site's publication date. Each brief explains what changed, why it may matter, and the limits of the evidence. Older developments may be covered as background; they must not be presented as breaking news.\n\nAutomated discovery places candidates in an editorial queue. It does not publish articles. Before publication, an editor checks the original source, dates, attribution, scope, related wiki entries, and correction needs. The publication record identifies whether the source check was human or AI-assisted. Do not imply independent testing or expert review when neither occurred.\n\n AI assistance\nAI may assist with discovery, drafting, source comparison, and maintenance. Launch articles disclose AI-assisted source synthesis. No invented human reviewer, interview, test result, or credential may be added. A maintainer remains responsible for accepting and correcting published content.\n\n Ownership and conflicts\nThe site is maintained by Mason Nguyen. The previous homepage linked to commercial implementation properties; those referral paths have been removed from the reference site's navigation and content model. This change does not establish independent ownership or erase relevant affiliations.\n\nContributors must disclose a relevant commercial relationship when covering an affiliated product or organization. The site does not sell favorable coverage, rankings, or placement in its reference articles. Author attribution is retained.\n\n Corrections and revision dates\nReport a correction through the [contribution page](/contribute/). Include the URL, disputed passage, and evidence. Material factual corrections receive a visible note and a revision-history entry. Update dates change for substantive edits, not to create an appearance of freshness.\n\n Reuse and attribution\nSummarize sources in original language and link to the original. Do not reproduce full third-party articles or images without permission. Source code visibility does not grant rights to third-party material. This site makes no blanket open-content licensing claim.\n"},{"title":"The ARM working framework","description":"An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.","path":"/framework/","text":" Status and authorship\nThis working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.\n\nEarlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.\n\n Five design concerns\n Decision rights\nIdentify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.\n\n Observable signals\nRecord the measurements and assumptions used in a decision. [OpenTelemetry's signal vocabulary]() is relevant background for instrumentation, not an endorsement of this framework.\n\n Recoverable state\nDefine how interrupted work is identified and recovered. Checkpoints and durable records can help, but their guarantees depend on implementation. This framework does not promise recovery from every failure mode or zero data loss.\n\n Human escalation\nDefine the conditions that require review and the action taken while review is pending. [NIST's AI risk-management work]() supplies broader context; these five concerns are not NIST's categories.\n\n Auditable decisions\nConnect requests, permission, execution, and observed results. Use precise descriptions of retention and tamper resistance instead of assuming a log is immutable.\n\n Applying the proposal\nFor a hypothetical resource controller, write down one permitted action, one limit, its input signal, its recovery behavior, and its escalation owner. Then test a missing signal, a rejected allocation, and an uncertain result.\n\nThis exercise is an editorial method for revealing assumptions. It does not establish that a system is safe, optimal, or compliant.\n\n What would strengthen the framework\nIndependent critique, reproducible examples, failure reports, and comparisons with alternative designs would make the proposal more useful. Contributions should identify which claim they support or challenge. Use the [contribution guide](/contribute/) to propose a change.\n\n Related reference material\nStart with [autonomous resource management](/wiki/autonomous-resource-management/), [human oversight](/wiki/human-oversight/), and [audit trails](/wiki/audit-trails/). Search visibility and structured publishing are separate concerns; they are not prerequisites for a working resource controller.\n"},{"title":"Agent orchestration and tool access","description":"Coordinating work while keeping authority, retries, and external actions explicit.","path":"/wiki/agent-orchestration/","text":" Coordination and authority\nAgent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or [budget](/wiki/finops-and-cost-controls/).\n\nAn orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.\n\n Protocols have a specific scope\nThe [Model Context Protocol architecture, revision 2025-06-18](), describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.\n\nProtocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.\n\n A bounded workflow example\nImagine an agent that proposes resizing a service. A useful separation is:\n\n1. Collect current workload and cost evidence.\n2. Produce a proposal with assumptions and an expiry time.\n3. Check permitted resources, spending limits, and required approval.\n4. Execute the approved action with an operation identifier.\n5. Inspect the actual outcome and record failures or partial completion.\n\nThis is an editorial design example, not a required protocol workflow.\n\n Retries and uncertainty\nA timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.\n\nRelated reading: [human oversight](/wiki/human-oversight/), [audit trails](/wiki/audit-trails/), and the proposed [ARM working framework](/framework/).\n"},{"title":"Audit trails and decision provenance","description":"Recording what was requested, authorized, executed, and observed.","path":"/wiki/audit-trails/","text":" What an audit trail can establish\nAn audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its [authorization context](/wiki/human-oversight/), the attempted action, and the result.\n\n[Kubernetes auditing]() provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.\n\n Design around questions\nAn editorial starting point is to ask whether a reviewer can determine:\n\n1. Who or what requested the change?\n2. Which policy or approval permitted it?\n3. Which measurements were available at the time?\n4. Was the action attempted, completed, rejected, or left uncertain?\n5. What subsequent evidence confirms the outcome?\n\nUse identifiers to connect related events. Keep the original event time distinct from the time a record was received or reviewed.\n\n Integrity and privacy\n“Immutable” is a strong claim. Retention rules, access restrictions, integrity checks, and independent copies provide different protections. State the protections actually implemented rather than assuming that a logging product makes records tamper-proof.\n\nLogs can also contain sensitive information. Decide what is necessary to retain, who can access it, and how long it remains useful. An exhaustive transcript is not automatically the best audit record.\n\n Limits\nA record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.\n\nCombine audit evidence with [observability](/wiki/observability/) and [human review](/wiki/human-oversight/). Claims about system reliability need tests and operational evidence beyond the existence of logs.\n"},{"title":"What is autonomous resource management?","description":"A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.","path":"/wiki/autonomous-resource-management/","text":" Definition and scope\nAutonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.\n\nA useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.\n\n How the pieces fit together\nA resource-management design needs a target, [measurements](/wiki/observability/), a decision mechanism, and a way to act. Use [audit trails](/wiki/audit-trails/) to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](). The broader connection to ARM is our editorial synthesis.\n\nConsider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.\n\n Related disciplines\n- [Autoscaling](/wiki/autoscaling/) changes capacity in response to signals.\n- [Resource scheduling](/wiki/resource-scheduling/) decides where work can run.\n- [Orchestration](/wiki/agent-orchestration/) coordinates dependent work and tool interactions.\n- [FinOps and cost controls](/wiki/finops-and-cost-controls/) connect resource use to financial accountability. The [FinOps Framework]() describes an operating practice that involves engineering, finance, and business participants.\n- [Human oversight](/wiki/human-oversight/) addresses authority, review, and intervention.\n\n Boundaries and open questions\nThe appropriate degree of autonomy depends on the reversibility of an action, the reliability of its evidence, and the people affected. A low-risk scaling decision and an irreversible spending commitment should not be treated as equivalent.\n\nThe [ARM working framework](/framework/) offers one proposed way to organize these questions. Its five design concerns are an attributed synthesis rather than an industry standard or a prerequisite for every automated resource system.\n"},{"title":"Autoscaling and feedback loops","description":"How capacity follows demand, and why signals, limits, and recovery matter.","path":"/wiki/autoscaling/","text":" What autoscaling changes\nAutoscaling adjusts capacity in response to observed or anticipated demand. The [Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling](). Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.\n\nChoosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare [resource scheduling and allocation](/wiki/resource-scheduling/) when the problem is where work can run.\n\n Signals and decisions\nA controller compares [measurements](/wiki/observability/) with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.\n\nFor a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.\n\n Tradeoffs to evaluate\n- Responsiveness: a fast reaction can reduce waiting but may chase short-lived noise.\n- Stability: frequent opposing adjustments can interrupt work or waste capacity.\n- Cost: spare capacity can improve response time while increasing spend.\n- Availability: a request to scale does not prove that capacity was obtained.\n\nReview these tradeoffs together. [Cost controls](/wiki/finops-and-cost-controls/) and [observability](/wiki/observability/) make the operating consequences easier to inspect.\n\n Failure and recovery\nSpecify the response to stale metrics, failed allocations, quota exhaustion, and interrupted scale-down. Test those responses against the actual workload. A controller should not interpret missing demand data as proof that demand is zero.\n\nThe underlying loop is described in [Kubernetes controller concepts](). Applying that pattern to a particular service still requires workload-specific measurement and testing.\n"},{"title":"FinOps and cost controls","description":"Relating resource consumption, budgets, and business outcomes without assuming automatic savings.","path":"/wiki/finops-and-cost-controls/","text":" Financial accountability\nThe [FinOps Framework]() brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.\n\nA useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.\n\n Design the budget boundary\nFor a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.\n\nA cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.\n\n Resource limits are not currency limits\n[Kubernetes resource quotas]() can constrain resource requests or object counts. Their units and scope differ from a bill denominated in currency. Translating a resource allowance into a cost expectation requires pricing assumptions and usage context.\n\n Evaluate claims carefully\nWhen someone reports savings, ask which baseline, workload, period, prices, and service-quality targets were used. Distinguish a projected saving from an observed reduction in paid costs. A lower cost per operation can coexist with higher total spend if demand grows.\n\nThese evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.\n\nRelated: [autoscaling](/wiki/autoscaling/), [resource scheduling](/wiki/resource-scheduling/), and [observability](/wiki/observability/).\n"},{"title":"Human oversight and decision rights","description":"Defining who can authorize, interrupt, and review automated resource decisions.","path":"/wiki/human-oversight/","text":" Oversight needs an operational meaning\nHuman oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.\n\nThe [NIST AI Risk Management Framework]() provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.\n\n Define the delegated scope\nAs an editorial design checklist, document:\n\n- Which resources and actions the system may control.\n- The limits on amount, duration, and frequency.\n- Which actions need approval before execution.\n- Who can pause the system and revoke access.\n- How an operator learns about a failed or incomplete action.\n\nSeparate permission from confidence. A system can be highly confident about an action it is not authorized to take.\n\n Escalation example\nA hypothetical workflow may automatically add a small amount of reversible capacity, require approval for a larger change, and refuse to make an irreversible commitment without explicit authorization. If the approver is unavailable, the policy must specify whether to wait, retain the existing state, or follow another documented fallback.\n\nSilence should not be interpreted as newly granted authority. This is the site's design recommendation, not a quoted NIST requirement.\n\n Review and learning\nAfter a consequential event, compare the authorized action, the recorded action, and the observed outcome. Update the policy when evidence shows that an assumption was wrong. Document unresolved questions as well as successes.\n\nRelated: [agent orchestration](/wiki/agent-orchestration/), [audit trails](/wiki/audit-trails/), and [the proposed ARM framework](/framework/).\n"},{"title":"Observability for resource decisions","description":"Connecting measurements to actions without mistaking telemetry for proof of correctness.","path":"/wiki/observability/","text":" Observe the system and its decisions\nObservability helps operators investigate system behavior from available evidence. [OpenTelemetry describes signals such as traces, metrics, and logs](), which offer different views of system activity.\n\nFor resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.\n\n A useful decision record\nAs editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.\n\nSeparate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.\n\n Evidence quality\nA signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric for [autoscaling](/wiki/autoscaling/), define how old it may be and how the system should behave when the data is unavailable.\n\nFor example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default.\n\n Limits\nTelemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.\n\nUse [audit trails](/wiki/audit-trails/) to preserve decision context and [human oversight](/wiki/human-oversight/) to define who responds when evidence is insufficient.\n"},{"title":"Resource scheduling and allocation","description":"Placement decisions, competing objectives, and the difference between capacity and usable capacity.","path":"/wiki/resource-scheduling/","text":" What a scheduler decides\nA scheduler matches work to eligible resources. It has to respect constraints before considering preferences. [Kubernetes describes filtering candidate nodes and scoring the feasible ones]().\n\nScheduling is distinct from [autoscaling](/wiki/autoscaling/). A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.\n\n Constraints before preferences\nIn a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.\n\nRecord which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.\n\n Questions for an allocation policy\n1. Which workloads can wait, and for how long?\n2. Can lower-priority work be interrupted without losing progress?\n3. How is scarce capacity shared between teams?\n4. What happens when no eligible resource exists?\n5. What evidence explains a rejected or delayed allocation?\n\nThese questions are editorial design guidance. Answers need to be validated against the workload and the resource provider.\n\n Limits and related concepts\n[Resource quotas]() constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.\n\nRead [autoscaling](/wiki/autoscaling/) for capacity adjustments and [audit trails](/wiki/audit-trails/) for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.\n"}] \ No newline at end of file diff --git a/site.css b/site.css index d2c3524..0e18f8f 100644 --- a/site.css +++ b/site.css @@ -6,3 +6,5 @@ @media(prefers-reduced-motion:reduce){html{scroll-behavior:auto}} .resource-loop{display:block;width:100%;height:auto;margin:20px 0 5px} + +.topic-paths{display:grid;grid-template-columns:repeat(2,minmax(0,1fr));gap:24px;list-style:none;padding:0;margin:20px 0}.topic-paths li{border-top:1px solid var(--line);padding-top:16px}.topic-paths a{font-family:var(--serif);font-size:23px}.topic-paths p{font-size:14px;color:var(--muted);margin-top:8px}.breadcrumb{display:flex;flex-wrap:wrap;gap:8px;line-height:1.7}.breadcrumb span[aria-current]{overflow-wrap:anywhere}.source-list p{font-size:13px;margin-top:8px}@media(max-width:500px){.topic-paths{grid-template-columns:1fr}} diff --git a/sources/index.html b/sources/index.html index 79360c6..05921fe 100644 --- a/sources/index.html +++ b/sources/index.html @@ -1,5 +1,5 @@ Sources and evidence | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Evidence directory

        Start with the source.

        Documentation supports descriptions of a system. Announcements establish what a publisher reports. Neither alone proves performance in your environment.

        Source selection

        These are cited sources, not endorsements or an exhaustive industry list. The initial library emphasizes infrastructure documentation. Broader research and independently evaluated case studies are an editorial priority.

        1. FinOps Foundation: FinOps Framework 2026Official publisher announcement; supports attributed changes, not independent outcome claims.
        2. Kubernetes DRA team: Kubernetes v1.36 DRA updatesOfficial publisher announcement; supports attributed changes, not independent outcome claims.
        3. Kubernetes project blog: Tracing Kueue admission with HeadlampProject-authored guide; supports the described troubleshooting distinction and plugin limitations.
        4. OpenTelemetry: SignalsTelemetry signals used to describe system activity.
        5. NIST: AI Risk Management FrameworkVoluntary AI risk management guidance.
        6. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.
        7. Kubernetes: AuditingAPI audit events, policy, and storage backends.
        8. Kubernetes: ControllersControl loops and desired state.
        9. FinOps Foundation: FrameworkCollaborative technology value and cost management.
        10. Kubernetes: Autoscaling workloadsHorizontal, vertical, and infrastructure scaling.
        11. Kubernetes: Resource quotasNamespace resource constraints and their scope.
        12. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.

        Suggest additional evidence

        We welcome relevant research, alternative approaches, and reproducible failure reports. Propose a source with the claim it supports or challenges.

        +
        Evidence directory

        Start with the source.

        Documentation supports descriptions of a system. Announcements establish what a publisher reports. Neither alone proves performance in your environment.

        Source selection

        These are cited sources, not endorsements or an exhaustive industry list. The initial library emphasizes infrastructure documentation. Broader research and independently evaluated case studies are an editorial priority.

        1. FinOps Foundation: FinOps Framework 2026Official publisher announcement; supports attributed changes, not independent outcome claims.

          Used in: FinOps Framework 2026 adds strategy alignment and broader technology guidance.

        2. Kubernetes DRA team: Kubernetes v1.36 DRA updatesOfficial publisher announcement; supports attributed changes, not independent outcome claims.

          Used in: Kubernetes 1.36 expands Dynamic Resource Allocation.

        3. Kubernetes project blog: Tracing Kueue admission with HeadlampProject-authored guide; supports the described troubleshooting distinction and plugin limitations.

          Used in: Headlamp guide separates Kueue admission from Pod scheduling.

        4. OpenTelemetry: SignalsTelemetry signals used to describe system activity.

          Used in: The ARM working framework; Observability for resource decisions.

        5. NIST: AI Risk Management FrameworkVoluntary AI risk management guidance.

          Used in: The ARM working framework; Human oversight and decision rights.

        6. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.

          Used in: Agent orchestration and tool access.

        7. Kubernetes: AuditingAPI audit events, policy, and storage backends.

          Used in: Audit trails and decision provenance.

        8. Kubernetes: ControllersControl loops and desired state.

          Used in: What is autonomous resource management?; Autoscaling and feedback loops.

        9. FinOps Foundation: FrameworkCollaborative technology value and cost management.

          Used in: What is autonomous resource management?; FinOps and cost controls.

        10. Kubernetes: Autoscaling workloadsHorizontal, vertical, and infrastructure scaling.

          Used in: Autoscaling and feedback loops.

        11. Kubernetes: Resource quotasNamespace resource constraints and their scope.

          Used in: FinOps and cost controls; Resource scheduling and allocation.

        12. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.

          Used in: Resource scheduling and allocation.

        Suggest additional evidence

        We welcome relevant research, alternative approaches, and reproducible failure reports. Propose a source with the claim it supports or challenges.

        diff --git a/tests/browser/site.spec.mjs b/tests/browser/site.spec.mjs index 1230119..8101ad7 100644 --- a/tests/browser/site.spec.mjs +++ b/tests/browser/site.spec.mjs @@ -38,3 +38,17 @@ test('keyboard users can skip navigation',async({page})=>{ await expect(page.getByRole('link',{name:'Skip to content'})).toBeFocused(); await page.keyboard.press('Enter');expect(page.url()).toContain('#main'); }); + +test('topic navigation connects concepts with dated news and their sources',async({page})=>{ + await page.goto('/wiki/'); + await page.getByRole('navigation',{name:'Wiki topics'}).getByRole('link',{name:'Capacity and workload placement'}).click(); + await expect(page).toHaveURL(/#capacity-and-placement$/); + await page.locator('#capacity-and-placement').getByRole('link',{name:'Resource scheduling and allocation'}).click(); + await expect(page.getByRole('navigation',{name:'Breadcrumb'})).toContainText('Capacity and workload placement'); + await page.getByRole('link',{name:'Headlamp guide separates Kueue admission from Pod scheduling'}).click(); + await page.locator('.prose').getByRole('link',{name:'resource scheduling',exact:true}).click(); + await expect(page.locator('h1')).toHaveText('Resource scheduling and allocation'); + await page.goto('/sources/'); + await page.locator('.source-list').getByRole('link',{name:'Audit trails and decision provenance'}).click(); + await expect(page.locator('h1')).toHaveText('Audit trails and decision provenance'); +}); diff --git a/tests/test_links.py b/tests/test_links.py new file mode 100644 index 0000000..f6b87e0 --- /dev/null +++ b/tests/test_links.py @@ -0,0 +1,44 @@ +import importlib.util +from pathlib import Path +import tempfile +import unittest + +spec = importlib.util.spec_from_file_location('audit_links', Path('scripts/audit-links.py')) +module = importlib.util.module_from_spec(spec) +spec.loader.exec_module(module) + +class LinkAuditTests(unittest.TestCase): + def fixture(self, root, route, body, canonical=None): + file = root / route.lstrip('/') / 'index.html' + file.parent.mkdir(parents=True, exist_ok=True) + file.write_text(f'
        {body}
        ') + + def test_absolute_internal_links_and_fragments_are_checked(self): + with tempfile.TemporaryDirectory() as tmp: + root = Path(tmp) + self.fixture(root, '/', 'Topic') + self.fixture(root, '/topic/', 'Home') + self.assertTrue(any('missing fragment' in e for e in module.audit(root)['errors'])) + + def test_navigation_does_not_satisfy_contextual_link_requirement(self): + with tempfile.TemporaryDirectory() as tmp: + root = Path(tmp) + self.fixture(root, '/', '') + self.fixture(root, '/wiki/example/', 'Home') + self.assertIn('/wiki/example/: no contextual article inlink', module.audit(root)['errors']) + + def test_orphan_and_wrong_canonical_fail(self): + with tempfile.TemporaryDirectory() as tmp: + root = Path(tmp) + self.fixture(root, '/', '') + self.fixture(root, '/lost/', '', 'https://other.example/lost/') + errors = module.audit(root)['errors'] + self.assertTrue(any('orphaned' in e for e in errors)) + self.assertTrue(any('non-self canonical' in e for e in errors)) + + def test_valid_contextual_route_passes(self): + with tempfile.TemporaryDirectory() as tmp: + root = Path(tmp) + self.fixture(root, '/', '') + self.fixture(root, '/wiki/example/', '

        Definition

        Home') + self.assertEqual(module.audit(root)['errors'], []) diff --git a/wiki/agent-orchestration/index.html b/wiki/agent-orchestration/index.html index fb299c0..eeaa9f0 100644 --- a/wiki/agent-orchestration/index.html +++ b/wiki/agent-orchestration/index.html @@ -1,7 +1,7 @@ Agent orchestration and tool access | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Agent orchestration and tool access

        Coordinating work while keeping authority, retries, and external actions explicit.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Coordination and authority

        Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Agent orchestration and tool access

        Coordinating work while keeping authority, retries, and external actions explicit.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Coordination and authority

        Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget.

        An orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.

        Protocols have a specific scope

        The Model Context Protocol architecture, revision 2025-06-18, describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.

        Protocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.

        @@ -16,5 +16,5 @@

        A bounded workflow example

        Imagine an

        This is an editorial design example, not a required protocol workflow.

        Retries and uncertainty

        A timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.

        Related reading: human oversight, audit trails, and the proposed ARM working framework.

        -

        Sources and scope

        1. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.

        View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.

        Continue reading

        Explore orchestration and human oversight: Which actions can a workflow take, and who can intervene?

        For the wider context, read what autonomous resource management means.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/audit-trails/index.html b/wiki/audit-trails/index.html index 38ff227..23ca464 100644 --- a/wiki/audit-trails/index.html +++ b/wiki/audit-trails/index.html @@ -1,7 +1,7 @@ Audit trails and decision provenance | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Audit trails and decision provenance

        Recording what was requested, authorized, executed, and observed.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What an audit trail can establish

        An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Audit trails and decision provenance

        Recording what was requested, authorized, executed, and observed.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What an audit trail can establish

        An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result.

        Kubernetes auditing provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.

        Design around questions

        An editorial starting point is to ask whether a reviewer can determine:

          @@ -16,5 +16,5 @@

          Integrity and privacy

          “Immutable” is a

          Logs can also contain sensitive information. Decide what is necessary to retain, who can access it, and how long it remains useful. An exhaustive transcript is not automatically the best audit record.

          Limits

          A record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.

          Combine audit evidence with observability and human review. Claims about system reliability need tests and operational evidence beyond the existence of logs.

          -

          Sources and scope

          1. Kubernetes: AuditingAPI audit events, policy, and storage backends.

          View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. Kubernetes: AuditingAPI audit events, policy, and storage backends.

        Continue reading

        Explore cost and operational evidence: What did the system consume, and what evidence explains it?

        For the wider context, read what autonomous resource management means.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/autonomous-resource-management/index.html b/wiki/autonomous-resource-management/index.html index 004aeaf..9782369 100644 --- a/wiki/autonomous-resource-management/index.html +++ b/wiki/autonomous-resource-management/index.html @@ -1,9 +1,9 @@ What is autonomous resource management? | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        What is autonomous resource management?

        A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Definition and scope

        Autonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        What is autonomous resource management?

        A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Definition and scope

        Autonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.

        A useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.

        -

        How the pieces fit together

        A resource-management design needs a target, measurements, a decision mechanism, and a way to act. Kubernetes documents a concrete form of this pattern: controllers reconcile observed state with desired state. The broader connection to ARM is our editorial synthesis.

        +

        How the pieces fit together

        A resource-management design needs a target, measurements, a decision mechanism, and a way to act. Use audit trails to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: controllers reconcile observed state with desired state. The broader connection to ARM is our editorial synthesis.

        Consider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.

        • Autoscaling changes capacity in response to signals.
          • @@ -14,5 +14,5 @@

          Boundaries and open questions

          The appropriate degree of autonomy depends on the reversibility of an action, the reliability of its evidence, and the people affected. A low-risk scaling decision and an irreversible spending commitment should not be treated as equivalent.

          The ARM working framework offers one proposed way to organize these questions. Its five design concerns are an attributed synthesis rather than an industry standard or a prerequisite for every automated resource system.

          -

          Sources and scope

          1. Kubernetes: ControllersControl loops and desired state.
          2. FinOps Foundation: FrameworkCollaborative technology value and cost management.

          View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. Kubernetes: ControllersControl loops and desired state.
        2. FinOps Foundation: FrameworkCollaborative technology value and cost management.

        Continue reading

        Explore foundations and scope: What does autonomous resource management mean?

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/autoscaling/index.html b/wiki/autoscaling/index.html index 0a50d07..00fcc47 100644 --- a/wiki/autoscaling/index.html +++ b/wiki/autoscaling/index.html @@ -1,9 +1,9 @@ Autoscaling and feedback loops | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Autoscaling and feedback loops

        How capacity follows demand, and why signals, limits, and recovery matter.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What autoscaling changes

        Autoscaling adjusts capacity in response to observed or anticipated demand. The Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling. Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.

        -

        Choosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it.

        -

        Signals and decisions

        A controller compares measurements with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Autoscaling and feedback loops

        How capacity follows demand, and why signals, limits, and recovery matter.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What autoscaling changes

        Autoscaling adjusts capacity in response to observed or anticipated demand. The Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling. Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.

        +

        Choosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare resource scheduling and allocation when the problem is where work can run.

        +

        Signals and decisions

        A controller compares measurements with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.

        For a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.

        Tradeoffs to evaluate

        • Responsiveness: a fast reaction can reduce waiting but may chase short-lived noise.
          • @@ -14,5 +14,5 @@

          Tradeoffs to evaluate

        +

        Sources and scope

        1. Kubernetes: Autoscaling workloadsHorizontal, vertical, and infrastructure scaling.
        2. Kubernetes: ControllersControl loops and desired state.

        Continue reading

        Explore capacity and workload placement: Do I need more capacity, or a different allocation?

        For the wider context, read what autonomous resource management means.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/finops-and-cost-controls/index.html b/wiki/finops-and-cost-controls/index.html index 584a153..65db6ba 100644 --- a/wiki/finops-and-cost-controls/index.html +++ b/wiki/finops-and-cost-controls/index.html @@ -1,7 +1,7 @@ FinOps and cost controls | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        FinOps and cost controls

        Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Financial accountability

        The FinOps Framework brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        FinOps and cost controls

        Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Financial accountability

        The FinOps Framework brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.

        A useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.

        Design the budget boundary

        For a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.

        A cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.

        @@ -9,5 +9,5 @@

        Resource limits are not currenc

        Evaluate claims carefully

        When someone reports savings, ask which baseline, workload, period, prices, and service-quality targets were used. Distinguish a projected saving from an observed reduction in paid costs. A lower cost per operation can coexist with higher total spend if demand grows.

        These evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.

        Related: autoscaling, resource scheduling, and observability.

        -

        Sources and scope

        1. FinOps Foundation: FrameworkCollaborative technology value and cost management.
        2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

        View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. FinOps Foundation: FrameworkCollaborative technology value and cost management.
        2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

        Continue reading

        Explore cost and operational evidence: What did the system consume, and what evidence explains it?

        For the wider context, read what autonomous resource management means.

        Related source briefs

        Dated project developments; these do not independently validate the concepts above.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/human-oversight/index.html b/wiki/human-oversight/index.html index 57d269e..1b52f76 100644 --- a/wiki/human-oversight/index.html +++ b/wiki/human-oversight/index.html @@ -1,7 +1,7 @@ Human oversight and decision rights | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Human oversight and decision rights

        Defining who can authorize, interrupt, and review automated resource decisions.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Oversight needs an operational meaning

        Human oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Human oversight and decision rights

        Defining who can authorize, interrupt, and review automated resource decisions.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Oversight needs an operational meaning

        Human oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.

        The NIST AI Risk Management Framework provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.

        Define the delegated scope

        As an editorial design checklist, document:

        +

        Sources and scope

        1. NIST: AI Risk Management FrameworkVoluntary AI risk management guidance.

        Continue reading

        Explore orchestration and human oversight: Which actions can a workflow take, and who can intervene?

        For the wider context, read what autonomous resource management means.

        Related source briefs

        Dated project developments; these do not independently validate the concepts above.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/index.html b/wiki/index.html index af6595a..36de7c4 100644 --- a/wiki/index.html +++ b/wiki/index.html @@ -1,5 +1,5 @@ Reference library | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Wiki / 8 articles

        The reference library

        Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

        What is autonomous resource management? →
        03 / Wiki reference

        What is autonomous resource management?

        A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

        Definition, context & limitations
        04 / Wiki reference

        Autoscaling and feedback loops

        How capacity follows demand, and why signals, limits, and recovery matter.

        Definition, context & limitations
        05 / Wiki reference

        FinOps and cost controls

        Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

        Definition, context & limitations
        08 / Wiki reference

        Resource scheduling and allocation

        Placement decisions, competing objectives, and the difference between capacity and usable capacity.

        Definition, context & limitations
        +
        Wiki / 8 articles

        The reference library

        Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

        What is autonomous resource management? →
        What does autonomous resource management mean?

        Foundations and scope

        Start with the working definition and distinguish resource decisions from general automation.

        01 / Wiki reference

        What is autonomous resource management?

        A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

        Definition, context & limitations
        Do I need more capacity, or a different allocation?

        Capacity and workload placement

        Compare scaling with scheduling before investigating workload constraints and capacity limits.

        01 / Wiki reference

        Autoscaling and feedback loops

        How capacity follows demand, and why signals, limits, and recovery matter.

        Definition, context & limitations
        02 / Wiki reference

        Resource scheduling and allocation

        Placement decisions, competing objectives, and the difference between capacity and usable capacity.

        Definition, context & limitations
        What did the system consume, and what evidence explains it?

        Cost and operational evidence

        Connect budgets and cost controls to measurements, observed outcomes, and decision records.

        01 / Wiki reference

        FinOps and cost controls

        Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

        Definition, context & limitations
        Which actions can a workflow take, and who can intervene?

        Orchestration and human oversight

        Follow task coordination into delegated permissions, escalation, and accountable review.

        diff --git a/wiki/observability/index.html b/wiki/observability/index.html index 8b95e1e..c3b7c8f 100644 --- a/wiki/observability/index.html +++ b/wiki/observability/index.html @@ -1,13 +1,13 @@ Observability for resource decisions | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Observability for resource decisions

        Connecting measurements to actions without mistaking telemetry for proof of correctness.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Observe the system and its decisions

        Observability helps operators investigate system behavior from available evidence. OpenTelemetry describes signals such as traces, metrics, and logs, which offer different views of system activity.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Observability for resource decisions

        Connecting measurements to actions without mistaking telemetry for proof of correctness.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        Observe the system and its decisions

        Observability helps operators investigate system behavior from available evidence. OpenTelemetry describes signals such as traces, metrics, and logs, which offer different views of system activity.

        For resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.

        A useful decision record

        As editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.

        Separate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.

        -

        Evidence quality

        A signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric to control resources, define how old it may be and how the system should behave when the data is unavailable.

        +

        Evidence quality

        A signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric for autoscaling, define how old it may be and how the system should behave when the data is unavailable.

        For example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default.

        Limits

        Telemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.

        Use audit trails to preserve decision context and human oversight to define who responds when evidence is insufficient.

        -

        Sources and scope

        1. OpenTelemetry: SignalsTelemetry signals used to describe system activity.

        View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. OpenTelemetry: SignalsTelemetry signals used to describe system activity.

        Continue reading

        Explore cost and operational evidence: What did the system consume, and what evidence explains it?

        For the wider context, read what autonomous resource management means.

        Related source briefs

        Dated project developments; these do not independently validate the concepts above.

        View revision history · View article source · Suggest a correction

        diff --git a/wiki/resource-scheduling/index.html b/wiki/resource-scheduling/index.html index eb85ba9..8bebee7 100644 --- a/wiki/resource-scheduling/index.html +++ b/wiki/resource-scheduling/index.html @@ -1,8 +1,8 @@ Resource scheduling and allocation | Autonomous Resource Management -
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        Home / Wiki
        Wiki reference

        Resource scheduling and allocation

        Placement decisions, competing objectives, and the difference between capacity and usable capacity.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What a scheduler decides

        A scheduler matches work to eligible resources. It has to respect constraints before considering preferences. Kubernetes describes filtering candidate nodes and scoring the feasible ones.

        -

        Scheduling is distinct from scaling. A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.

        +
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        +
        Wiki reference

        Resource scheduling and allocation

        Placement decisions, competing objectives, and the difference between capacity and usable capacity.

        ARM Editorial · Updated

        AI-assisted source synthesis; no independent expert review claimed.

        What a scheduler decides

        A scheduler matches work to eligible resources. It has to respect constraints before considering preferences. Kubernetes describes filtering candidate nodes and scoring the feasible ones.

        +

        Scheduling is distinct from autoscaling. A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.

        Constraints before preferences

        In a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.

        Record which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.

        Questions for an allocation policy

          @@ -15,5 +15,5 @@

          Questions for an allocation policyThese questions are editorial design guidance. Answers need to be validated against the workload and the resource provider.

          Resource quotas constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.

          Read autoscaling for capacity adjustments and audit trails for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.

          -

          Sources and scope

          1. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.
          2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

          View revision history · View article source · Suggest a correction

        +

        Sources and scope

        1. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.
        2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

        Continue reading

        Explore capacity and workload placement: Do I need more capacity, or a different allocation?

        For the wider context, read what autonomous resource management means.

        Related source briefs

        Dated project developments; these do not independently validate the concepts above.

        View revision history · View article source · Suggest a correction

        From dfc4aaa7579009ea4744f6753680fd838d811a57 Mon Sep 17 00:00:00 2001 From: virtualmase Date: Thu, 15 Oct 2026 16:45:13 -0700 Subject: [PATCH 2/4] Exclude listing cards from contextual article inlink checks --- scripts/audit-links.py | 2 +- tests/test_links.py | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/audit-links.py b/scripts/audit-links.py index 37ab089..3c3a2f9 100644 --- a/scripts/audit-links.py +++ b/scripts/audit-links.py @@ -20,7 +20,7 @@ def handle_starttag(self, tag, attrs): if 'id' in a: self.ids.add(a['id']) if tag == 'main': self.in_main = True - if tag == 'article': self.in_article = True + if tag == 'article': self.in_article = 'prose' in a.get('class', '').split() if tag == 'link' and a.get('rel') == 'canonical': self.canonical = a.get('href') if tag == 'meta' and a.get('name') == 'robots': self.indexable = 'noindex' not in a.get('content', '') diff --git a/tests/test_links.py b/tests/test_links.py index f6b87e0..ad0f3e4 100644 --- a/tests/test_links.py +++ b/tests/test_links.py @@ -23,7 +23,7 @@ def test_absolute_internal_links_and_fragments_are_checked(self): def test_navigation_does_not_satisfy_contextual_link_requirement(self): with tempfile.TemporaryDirectory() as tmp: root = Path(tmp) - self.fixture(root, '/', '') + self.fixture(root, '/', '') self.fixture(root, '/wiki/example/', 'Home') self.assertIn('/wiki/example/: no contextual article inlink', module.audit(root)['errors']) @@ -39,6 +39,6 @@ def test_orphan_and_wrong_canonical_fail(self): def test_valid_contextual_route_passes(self): with tempfile.TemporaryDirectory() as tmp: root = Path(tmp) - self.fixture(root, '/', '') + self.fixture(root, '/', '') self.fixture(root, '/wiki/example/', '

        Definition

        Home') self.assertEqual(module.audit(root)['errors'], []) From 310c700556b4061b1b6f6d4937395d8517477c45 Mon Sep 17 00:00:00 2001 From: virtualmase Date: Thu, 15 Oct 2026 16:46:34 -0700 Subject: [PATCH 3/4] Link the owner-provided LinkedIn profile in authorship and maintainer credits --- 404.html | 2 +- 404/index.html | 2 +- about/index.html | 6 +-- changelog/index.html | 4 +- content/pages/about.md | 2 +- contribute/index.html | 4 +- editorial-policy/index.html | 4 +- framework/index.html | 4 +- index.html | 2 +- news/finops-framework-2026/index.html | 4 +- news/index.html | 2 +- .../index.html | 4 +- news/kueue-admission-headlamp/index.html | 4 +- release.json | 50 +++++++++---------- scripts/build.mjs | 6 ++- search-index.json | 2 +- search/index.html | 2 +- sources/index.html | 2 +- wiki/agent-orchestration/index.html | 4 +- wiki/audit-trails/index.html | 4 +- .../autonomous-resource-management/index.html | 4 +- wiki/autoscaling/index.html | 4 +- wiki/finops-and-cost-controls/index.html | 4 +- wiki/human-oversight/index.html | 4 +- wiki/index.html | 2 +- wiki/observability/index.html | 4 +- wiki/resource-scheduling/index.html | 4 +- 27 files changed, 71 insertions(+), 69 deletions(-) diff --git a/404.html b/404.html index a8d9d72..a4b16d2 100644 --- a/404.html +++ b/404.html @@ -2,4 +2,4 @@ Page not found | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        404 / Page not found

        Let’s find the right page.

        This address is not part of the current reference.

        Browse the wikiSearch the reference
        - + diff --git a/404/index.html b/404/index.html index a8d9d72..a4b16d2 100644 --- a/404/index.html +++ b/404/index.html @@ -2,4 +2,4 @@ Page not found | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        404 / Page not found

        Let’s find the right page.

        This address is not part of the current reference.

        Browse the wikiSearch the reference
        - + diff --git a/about/index.html b/about/index.html index ffc365c..9d1e54a 100644 --- a/about/index.html +++ b/about/index.html @@ -1,9 +1,9 @@ About this reference | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        About this resource

        About this reference

        Purpose, authorship, editorial boundaries, and how this resource is maintained.

        ARM Editorial · Updated

        A reference for resource decisions

        This site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.

        +
        About this resource

        About this reference

        Purpose, authorship, editorial boundaries, and how this resource is maintained.

        By ARM Editorial · Maintained by Mason Nguyen · Updated

        A reference for resource decisions

        This site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.

        The project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.

        -

        Maintainer and authorship

        Mason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.

        +

        Maintainer and authorship

        Mason Nguyen on LinkedIn maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.

        The proposed ARM working framework is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.

        Commercial boundaries

        This reference has no service checkout or commercial referral directory. Earlier versions directed readers to implementation businesses. The standalone revision removes those pathways while retaining accountable authorship. Removing referrals should not be read as a claim that the maintainer has no outside commercial interests.

        Relevant affiliations must be disclosed when they affect a covered subject. See the editorial policy for the conflict-of-interest rule.

        @@ -11,4 +11,4 @@

        Maintenance and accountability

        Re

        The wiki is curated rather than open to immediate anonymous publication. Contributions are welcome; publication depends on evidence, relevance, and editorial review.

        Historical work records

        The earlier public-practice records remain available as historical, first-party work records. They are not independent validation of this reference, product recommendations, or evidence of industry consensus.

        View revision history · View article source · Suggest a correction

        - + diff --git a/changelog/index.html b/changelog/index.html index 14e43bc..a017263 100644 --- a/changelog/index.html +++ b/changelog/index.html @@ -1,7 +1,7 @@ Revision log | Autonomous Resource Management
        Autonomous Resource
        ManagementKnowledge · Context · Evidence
        -
        About this resource

        Revision log

        Material changes to the reference, its scope, and editorial practices.

        ARM Editorial · Updated

        15 October 2026 — standalone reference revision

          +
          About this resource

          Revision log

          Material changes to the reference, its scope, and editorial practices.

          By ARM Editorial · Maintained by Mason Nguyen · Updated

          15 October 2026 — standalone reference revision

          • Reframed the homepage around a source-backed knowledge library.
          • Removed commercial implementation referrals from the reference site's publishing model.
          • Moved the attributed ARM proposal to a dedicated framework page.
            • @@ -12,4 +12,4 @@

            These entries describe the content revision. Repository history records the exact changes; the deployment record identifies when the revision reaches the public site.

            Earlier material

            The previous homepage and its edits remain available in repository history. Its framework has been revised rather than presented as an established industry standard.

            View revision history · View article source · Suggest a correction

          - + diff --git a/content/pages/about.md b/content/pages/about.md index 703cba8..765d675 100644 --- a/content/pages/about.md +++ b/content/pages/about.md @@ -17,7 +17,7 @@ This site helps readers understand how automated systems allocate resources and The project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body. ## Maintainer and authorship -Mason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article. +[Mason Nguyen on LinkedIn](https://www.linkedin.com/in/mason-nguyen) maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article. The proposed [ARM working framework](/framework/) is attributed separately. Its existence does not establish consensus around that framework or the site's terminology. diff --git a/contribute/index.html b/contribute/index.html index d120724..edf91dc 100644 --- a/contribute/index.html +++ b/contribute/index.html @@ -1,7 +1,7 @@ Contribute or request a correction | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          About this resource

          Contribute or request a correction

          A practical route for improving definitions, citations, examples, and industry coverage.

          ARM Editorial · Updated

          Suggest a factual correction

          Open a correction request with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.

          +
          About this resource

          Contribute or request a correction

          A practical route for improving definitions, citations, examples, and industry coverage.

          By ARM Editorial · Maintained by Mason Nguyen · Updated

          Suggest a factual correction

          Open a correction request with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.

          GitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.

          Contribute an article

          Use the public repository to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.

          Disclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.

          @@ -9,4 +9,4 @@

          Suggest industry coverage

          How changes are reviewed

          Submissions are checked for factual support, neutral wording, relevant scope, and clear limitations. Technical checks validate internal links and required article metadata. Passing those checks is not a substitute for editorial judgment.

          The maintainer decides whether to publish. Material corrections are recorded in the revision log, and each article links to its source history.

          View revision history · View article source · Suggest a correction

          - + diff --git a/editorial-policy/index.html b/editorial-policy/index.html index c589ca4..54d7a62 100644 --- a/editorial-policy/index.html +++ b/editorial-policy/index.html @@ -1,7 +1,7 @@ Editorial policy | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          About this resource

          Editorial policy

          How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.

          ARM Editorial · Updated

          Purpose and scope

          Autonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.

          +
          About this resource

          Editorial policy

          How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.

          By ARM Editorial · Maintained by Mason Nguyen · Updated

          Purpose and scope

          Autonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.

          Neutral point of view

          Describe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.

          Separate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.

          Source standards

          Prefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.

          @@ -14,4 +14,4 @@

          Ownership and conflicts

          The site is main

          Corrections and revision dates

          Report a correction through the contribution page. Include the URL, disputed passage, and evidence. Material factual corrections receive a visible note and a revision-history entry. Update dates change for substantive edits, not to create an appearance of freshness.

          Reuse and attribution

          Summarize sources in original language and link to the original. Do not reproduce full third-party articles or images without permission. Source code visibility does not grant rights to third-party material. This site makes no blanket open-content licensing claim.

          View revision history · View article source · Suggest a correction

          - + diff --git a/framework/index.html b/framework/index.html index 07afb0a..309c575 100644 --- a/framework/index.html +++ b/framework/index.html @@ -1,7 +1,7 @@ The ARM working framework | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          Editorial proposal

          The ARM working framework

          An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

          Mason Nguyen; revision assisted by AI · Updated

          AI-assisted source synthesis; no independent expert review claimed.

          Status and authorship

          This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

          +
          Editorial proposal

          The ARM working framework

          An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

          By Mason Nguyen; revision assisted by AI · Updated

          AI-assisted source synthesis; no independent expert review claimed.

          Status and authorship

          This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

          Earlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.

          Five design concerns

          Decision rights

          Identify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.

          Observable signals

          Record the measurements and assumptions used in a decision. OpenTelemetry's signal vocabulary is relevant background for instrumentation, not an endorsement of this framework.

          @@ -13,4 +13,4 @@

          Applying the proposal

          For a hypothetical r

          What would strengthen the framework

          Independent critique, reproducible examples, failure reports, and comparisons with alternative designs would make the proposal more useful. Contributions should identify which claim they support or challenge. Use the contribution guide to propose a change.

          Start with autonomous resource management, human oversight, and audit trails. Search visibility and structured publishing are separate concerns; they are not prerequisites for a working resource controller.

          Sources and scope

          1. OpenTelemetry: SignalsTelemetry signals used to describe system activity.
          2. NIST: AI Risk Management FrameworkVoluntary AI risk management guidance.

          View revision history · View article source · Suggest a correction

          - + diff --git a/index.html b/index.html index 5894240..8d03132 100644 --- a/index.html +++ b/index.html @@ -8,4 +8,4 @@

          Industry context

          Browse source briefs →

          Dated developments, their implications, and what the evidence does not establish.

          From concepts to questions

          What can this system decide?

          Start with the action, its limits, the evidence behind it, and who can intervene. The ARM working framework offers one attributed proposal for organizing those questions.

          Read the working framework →
          An inspectable reference

          Follow the source.

          Articles identify their evidence, distinguish examples from findings, and link to revision history. Corrections and additional perspectives are welcome.

          Improve this resource →

          Looking for a section from the earlier reference?

          Definition · Five design concerns · Related disciplines · Signal architecture · Framework scope · Practical concepts · References

          - + diff --git a/news/finops-framework-2026/index.html b/news/finops-framework-2026/index.html index da06d1a..884b37a 100644 --- a/news/finops-framework-2026/index.html +++ b/news/finops-framework-2026/index.html @@ -1,10 +1,10 @@ FinOps Framework 2026 adds strategy alignment and broader technology guidance | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          Source brief

          FinOps Framework 2026 adds strategy alignment and broader technology guidance

          A background brief on the March framework revision and its relevance to resource-management objectives.

          ARM Editorial · Updated
          Source event: 2026-03-19 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          The FinOps Foundation’s 19 March 2026 framework update introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.

          +
          Source brief

          FinOps Framework 2026 adds strategy alignment and broader technology guidance

          A background brief on the March framework revision and its relevance to resource-management objectives.

          By ARM Editorial · Maintained by Mason Nguyen · Updated
          Source event: 2026-03-19 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          The FinOps Foundation’s 19 March 2026 framework update introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.

          This brief covers that published revision as background, rather than presenting the March announcement as new today.

          Why it matters

          Editorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.

          Read FinOps and cost controls for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. Human oversight explains why a budget boundary also needs an accountable owner.

          Limits of the evidence

          This is the framework publisher’s description of its own update. It does not establish adoption rates, measured savings, or the effectiveness of any automated product. The implications for resource-control design above are editorial interpretation, not a benchmark result or a requirement imposed by the Foundation.

          Sources and scope

          1. FinOps Foundation: FinOps Framework 2026Official publisher announcement; supports attributed changes, not independent outcome claims.

          View revision history · View article source · Suggest a correction

          - + diff --git a/news/index.html b/news/index.html index e07d7c9..b424062 100644 --- a/news/index.html +++ b/news/index.html @@ -2,4 +2,4 @@ Industry news and source briefs | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          Industry context

          Developments, in context.

          Source briefs connect industry changes to the reference library. Event dates and publication dates are shown separately; background coverage is not breaking news.

          Subscribe via RSS · Our news policy

          Source brief · source event 2026-10-14

          Headlamp guide separates Kueue admission from Pod scheduling

          An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.

          Published 2026-10-15 · AI-assisted source check; no independent testing or human expert review claimed.

          Source brief · source event 2026-05-07

          Kubernetes 1.36 expands Dynamic Resource Allocation

          A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.

          Published 2026-10-15 · AI-assisted source check; no independent testing or human expert review claimed.

          - + diff --git a/news/kubernetes-136-resource-allocation/index.html b/news/kubernetes-136-resource-allocation/index.html index e2f80cc..369cdf1 100644 --- a/news/kubernetes-136-resource-allocation/index.html +++ b/news/kubernetes-136-resource-allocation/index.html @@ -1,11 +1,11 @@ Kubernetes 1.36 expands Dynamic Resource Allocation | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          Source brief

          Kubernetes 1.36 expands Dynamic Resource Allocation

          A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.

          ARM Editorial · Updated
          Source event: 2026-05-07 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          In its 7 May 2026 update, the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.

          +
          Source brief

          Kubernetes 1.36 expands Dynamic Resource Allocation

          A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.

          By ARM Editorial · Maintained by Mason Nguyen · Updated
          Source event: 2026-05-07 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          In its 7 May 2026 update, the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.

          This is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.

          Why it matters

          Editorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.

          A useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See resource scheduling for the distinction between eligible capacity and preferred capacity.

          Limits of the evidence

          The source is a project announcement. This brief does not independently test the features, establish compatibility with a specific cluster, or substantiate performance gains. Check the documentation and feature state for the exact version and driver being evaluated.

          The announcement is evidence of reported project changes, not evidence that every resource-management deployment should adopt them.

          Sources and scope

          1. Kubernetes DRA team: Kubernetes v1.36 DRA updatesOfficial publisher announcement; supports attributed changes, not independent outcome claims.

          View revision history · View article source · Suggest a correction

          - + diff --git a/news/kueue-admission-headlamp/index.html b/news/kueue-admission-headlamp/index.html index 75d16f4..f9abe59 100644 --- a/news/kueue-admission-headlamp/index.html +++ b/news/kueue-admission-headlamp/index.html @@ -1,11 +1,11 @@ Headlamp guide separates Kueue admission from Pod scheduling | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          -
          Source brief

          Headlamp guide separates Kueue admission from Pod scheduling

          An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.

          ARM Editorial · Updated
          Source event: 2026-10-14 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          A 14 October 2026 Kubernetes project guide describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.

          +
          Source brief

          Headlamp guide separates Kueue admission from Pod scheduling

          An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.

          By ARM Editorial · Maintained by Mason Nguyen · Updated
          Source event: 2026-10-14 · Brief published: 2026-10-15 · Source checked: 2026-10-15

          AI-assisted source check; no independent testing or human expert review claimed.

          What changed

          A 14 October 2026 Kubernetes project guide describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.

          The guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.

          Why it matters

          Editorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.

          This distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See resource scheduling and observability for related concepts.

          Limits of the evidence

          This is a summary of a project-authored guide, not an independent evaluation. The plugin is identified as alpha in the source. This brief does not test compatibility, measure troubleshooting speed, or establish that a particular cluster has an admission problem.

          Read the original guide for prerequisites and version-specific details before applying its procedure.

          Sources and scope

          1. Kubernetes project blog: Tracing Kueue admission with HeadlampProject-authored guide; supports the described troubleshooting distinction and plugin limitations.

          View revision history · View article source · Suggest a correction

          - + diff --git a/release.json b/release.json index 6c689da..0fff3b2 100644 --- a/release.json +++ b/release.json @@ -1,26 +1,26 @@ { "schemaVersion": 1, - "contentDigest": "487fb00327c940982e9c3ef4475dc825de569101c76c26d7a4c17efb094a7712", + "contentDigest": "180d0070424aa1355149c67a1c6030b7de616ed5ecbd6841309b545eb9800ce1", "contentRevision": "2026-10-15", "pages": 22, "files": { ".htaccess": "98ffdb0e30a0a6e638a18e154181e33bfb133ff38d4d977485cd988915a2d816", - "404.html": "4eefc29e83eb4e2814b5ea64743e115a467d9a9edbb3322f1dabeff8b5bd70bc", - "404/index.html": "4eefc29e83eb4e2814b5ea64743e115a467d9a9edbb3322f1dabeff8b5bd70bc", - "about/index.html": "3e1f32510fc3eb7ce3011e36d69a452d921732a61dd90764689c1b6556f2a9d5", - "changelog/index.html": "d619f065e573360ad281ba10d3508bedddcb528a30b26bf4c2189b8672e0a813", - "contribute/index.html": "d5085a0847cc772500dc968b493c66eb61a713ba7eda6adc367d8ba0736f7f0b", - "editorial-policy/index.html": "83d5733ada4919692db438774c2d2526609bc4b2b5d29ea3206bbcc4a99e5d6e", + "404.html": "46d18fa246e1d7a8ad6904579022ca6de41465d920d4f72c75a7903dd9d6fdd5", + "404/index.html": "46d18fa246e1d7a8ad6904579022ca6de41465d920d4f72c75a7903dd9d6fdd5", + "about/index.html": "be9d5ccdd7e89d692b93b9c9a4e422e1faf4024ec190fb68e95a13245ab54ab4", + "changelog/index.html": "8d234691a2ede3b3af6c9c9395867f6d71ea0d135471f4891242d7ff86438aa7", + "contribute/index.html": "975424d1d07b282f4de5c42e086ac7485026ce80037a362c16f6093b1d39e052", + "editorial-policy/index.html": "6fcb95e0d00a30730bfef32d0fa80ba82401852bf3522697f3c9f4faa6d04000", "favicon.svg": "3766c9e6c1326cb25b003f88369e29907a8660883228c13ab470e306ed4df91e", "feed.xml": "979325d4616849c8c5bd7d386e98414fdf7d07bfc8aca49e566d945503d14419", - "framework/index.html": "46bd393b51985bef8b32dfd83390a80dcdac70b6aff5eb339a31f2ec4dd1e59e", + "framework/index.html": "c546ca99d7f55895deeec76c7d9e952be8824ec963ae189f7b2c02a769228004", "googlef40b1c9053cf9205.html": "a2afae8978371b939c5ac9e680468c14f119e38a6478ee92d867d510e39f54d4", - "index.html": "3296bf6df1796c3d04f2a8c3d7a251f32e9fef7bbbf65fff3e13b83ccbaec5cc", + "index.html": "7576d19dd333d3bd3206cb22574ab28150bab90f29cf7879fbc21165351f3fb3", "llms.txt": "3954c4e791dff83fbce9e7d596a7513f886547477605f3b28c66022e53975309", - "news/finops-framework-2026/index.html": "59fa6c3078878dda77cd0a07a84fb79f6b828ca16d1855c1e85593597329506d", - "news/index.html": "8fe3c9ac842cb6240f1984a42be140a2108f722418ee57974ce289ab1f5aa1da", - "news/kubernetes-136-resource-allocation/index.html": "f20529fd09ed37d29c6bc2690b19ff2807a8aed9cbef3421d47a2cdcddc480b7", - "news/kueue-admission-headlamp/index.html": "a5c2c70afe4603d344b30f79e8af5686f0f8d013e4f61379f61f1360f4287936", + "news/finops-framework-2026/index.html": "6fbf9bc148dac00f4a65ddfd181e04b42257fb9601ebe9f04a7b9531f0314327", + "news/index.html": "760f50ea74d9f0de575d6b73653447ee92d6731ccccbbb0b0762393da8d1d93d", + "news/kubernetes-136-resource-allocation/index.html": "22664b0d76847d236b4ed501ab057938e8701c83e4185c438312ba968a8a155b", + "news/kueue-admission-headlamp/index.html": "a098c6df5a8520c0219e568613580e0665c00638f11c25e8e447938fa4cbd627", "practice/index.html": "1c6bf5eb8c2b01f88616c5eab5dff566ed791a5f30f624a43832e65791379ff5", "practice/records/BLD-001-flagship-package.yml": "e4e032c1951df0542acfd69a0a0f20d39e6a7c8b04cfa5279bd5e1d01b6b8f66", "practice/records/CON-001-learning-pathway.yml": "527cbe273a0656d153e9587f13692375318f6bf7ec7ef405acae5014cd817e48", @@ -33,20 +33,20 @@ "resource-loop.svg": "24516aee93835dda1a98fe0a3d1d44c7366ddbfa87f67141ceba71eb4a674d4f", "robots.txt": "93e1d051721cccb2203533406be637394f7dcbdadcafd3b9a09d5e4a23db9605", "schema.json": "d16586e533eebfcb8c9bf76e88ea0924836055d6c616882c72df0a26d31fa107", - "search-index.json": "3774714abcc1cf9877fbbebc5ef9eeb394a2adddb2a4e938e0bc19c8f2c5aa72", + "search-index.json": "7fa65bd63bf2d2fa58527edd1942586745b8361fdd218d349a28c1cfd7c12d4a", "search.js": "78ae43ce810bd4b6c1b5dc0d052e61f2f6b8e003114c47770e2d4e4302d48d83", - "search/index.html": "29760aaaf3eb6d8ae311550de5b4d6496aeb200c9352feffaaf270476b669bf4", + "search/index.html": "3d712d698856c43566709de144fa68435b6fb91936b1207f13f29e16d20cee0d", "site.css": "8cf93ced94e9ff4f3c6b4396437b33ccb79b6cc46de643f358b38610c012a02f", "sitemap.xml": "7f07faaee013bae886666a3c4bf29b984829ca22a7d75a23c15ed846173b3a1a", - "sources/index.html": "d496faf341e6ec0864420b066e9657b57388f13ea62d00eeb7b0fa0a9e40c892", - "wiki/agent-orchestration/index.html": "67aafb5d3c48aa67063662f3c1cdf9e04137c20bcd3dcc1519bb7003519142b1", - "wiki/audit-trails/index.html": "148d7bc983ba16d7bf055f8549a5b3606df8718d657db1f06e935c90a55b7515", - "wiki/autonomous-resource-management/index.html": "be7d1499726f848639e015fb1da74a56ba9f3c83a2fa28c61bb4b4fefb92634b", - "wiki/autoscaling/index.html": "49e87f4a4778ebe245edbcc8da9ff1aae86cf6b9a77c2cf3ba478781c0c11bc7", - "wiki/finops-and-cost-controls/index.html": "8ce73ceb2ebe5ecce7b63fa682eb356cf0cc8d0cc911bd4fb748f8cff2e404fd", - "wiki/human-oversight/index.html": "ad4b538ddd2ea2afe718725a4925f0a97f1c49f2f6174189e892908c43ff5416", - "wiki/index.html": "795e79014eeee71c6910e4929afb671bfb70b4b146dcd8af44a7c44033c05e29", - "wiki/observability/index.html": "e1f43e8ed68a8f7d7b36f066ebd227b62db65c85ce549798f1b9d34e0c37e402", - "wiki/resource-scheduling/index.html": "b1075a6e0fa65d2f1d128a6471746419f6179433729756586f03b79b580a9318" + "sources/index.html": "08752343b2578d1fde8a1cfbc14aa35024dd8bad9b7c6be3e075e738ceb827eb", + "wiki/agent-orchestration/index.html": "c14b2d51f396369fb423c72f2d374a22e2d432b28a6a094c640c22f56331795f", + "wiki/audit-trails/index.html": "829bbf6dfc029e9e153e7f6cd0d72abbd51fcfc26d0f5928a5133d017c106127", + "wiki/autonomous-resource-management/index.html": "52caf91c6adfdefdf18bbc329c34b1cab297266deedb09ce51ec913be421eb9b", + "wiki/autoscaling/index.html": "11efcd1d5adbbcf7f71ac4944588dee2c50814b72b45fd54993d4a140c52b3b1", + "wiki/finops-and-cost-controls/index.html": "1484b0921bb4d99a4fdb92059de9d963a6d4ee623f3fb9feb6054c83eecadb61", + "wiki/human-oversight/index.html": "4d6470f3e5ff9f5b3d927fb1f1971104b26063c2c40bd6ecf6517b91bed0af37", + "wiki/index.html": "8c4658caa7446df39a29377cb4968e7d2bc8f50eeb60b1e2cf641ff118d02dd4", + "wiki/observability/index.html": "edbd209161650a5478326f99fb4feb656f2cb1fa33a5dbbfb28ae3f96019d900", + "wiki/resource-scheduling/index.html": "88930495d90fb07da60944bff2157799e986ce00f0321fcc6c34590706807e03" } } diff --git a/scripts/build.mjs b/scripts/build.mjs index 732db1b..694184a 100644 --- a/scripts/build.mjs +++ b/scripts/build.mjs @@ -8,6 +8,7 @@ import { loadTopics } from './topics.mjs'; const all=readContent(), articles=all.filter(a=>a.status==='published'); const wiki=articles.filter(a=>a.kind==='wiki'); const news=articles.filter(a=>a.kind==='news').sort((a,b)=>b.published.localeCompare(a.published)||b.eventDate.localeCompare(a.eventDate)); +const maintainerProfile='https://www.linkedin.com/in/mason-nguyen'; const topics=loadTopics(articles); const topicFor=a=>topics.find(t=>t.entries.some(entry=>entry.path===a.path)); const topicLinks=()=>topics.map(t=>`
        • ${e(t.title)}

          ${e(t.question)}

          • `).join(''); @@ -25,7 +26,7 @@ function shell(title,description,route,body,{schema=[],noindex=false,search=fals ${e(title)} | Autonomous Resource Management${search?'':''}
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          ${body}
          -\n`; +\n`; } function add(route,title,description,body,options={}) { if(routes.has(route))throw Error(`Duplicate route ${route}`); @@ -43,13 +44,14 @@ add('/','Autonomous resource management: wiki and industry context','Explore sou for(const a of articles){ const {html,headings}=renderMarkdown(a.body); const schema=[{'@type':a.kind==='news'?'NewsArticle':a.kind==='page'?'WebPage':'TechArticle','@id':origin+a.path+'#article',url:origin+a.path,headline:a.title,description:a.description,dateModified:a.updated,...(a.published?{datePublished:a.published}:{}),author:a.author.startsWith('Mason')?{'@id':origin+'/about/#maintainer'}:{'@id':origin+'/#publisher'},publisher:{'@id':origin+'/#publisher'},isPartOf:{'@id':origin+'/#website'},citation:(a.sources||[]).map(s=>({'@type':'CreativeWork',name:s.title,url:s.url}))}]; + const byline=a.author.startsWith('Mason')?`By ${e(a.author)}`:`By ${e(a.author)} · Maintained by Mason Nguyen`; const topic=topicFor(a); const parent=a.kind==='wiki'?['/wiki/','Wiki']:a.kind==='news'?['/news/','News']:null; const breadcrumb=``; const relatedNews=news.filter(n=>n.concepts.includes(a.path)).slice(0,3); const continuation=a.kind==='wiki'?`

          Continue reading

          Explore ${e(topic.title.toLowerCase())}: ${e(topic.question)}

          ${a.path!='/wiki/autonomous-resource-management/'?'

          For the wider context, read what autonomous resource management means.

          ':''}${relatedNews.length?`

          Related source briefs

          Dated project developments; these do not independently validate the concepts above.

            ${relatedNews.map(n=>`
          • ${e(n.title)}
            Source event: ${n.eventDate}
            • `).join('')}
          `:''}
          `:''; const sources=(a.sources||[]).length?`

          Sources and scope

            ${a.sources.map(s=>`
          1. ${e(s.title)}${e(s.scope)}
            2. `).join('')}
          `:''; - add(a.path,a.title,a.description,`
          ${breadcrumb}${label(a)}

          ${e(a.title)}

          ${e(a.description)}

          ${e(a.author)} · Updated ${a.kind==='news'?`
          Source event: ${a.eventDate} · Brief published: ${a.published} · Source checked: ${a.checked}`:''}

          ${a.kind!=='page'?`

          ${e(a.review)}

          `:''}
          `,{schema,updated:a.updated}); + add(a.path,a.title,a.description,`
          ${breadcrumb}${label(a)}

          ${e(a.title)}

          ${e(a.description)}

          ${byline} · Updated ${a.kind==='news'?`
          Source event: ${a.eventDate} · Brief published: ${a.published} · Source checked: ${a.checked}`:''}

          ${a.kind!=='page'?`

          ${e(a.review)}

          `:''}
          `,{schema,updated:a.updated}); } add('/wiki/','Reference library','Browse foundational concepts in autonomous resource management.',`
          Wiki / ${wiki.length} articles

          The reference library

          Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

          What is autonomous resource management? →
          ${topics.map(t=>`
          ${e(t.question)}

          ${e(t.title)}

          ${e(t.description)}

          ${t.entries.map(card).join('')}
          `).join('')}`); add('/news/','Industry news and source briefs','Dated developments in resource management, with source attribution and evidence limits.',`
          Industry context

          Developments, in context.

          Source briefs connect industry changes to the reference library. Event dates and publication dates are shown separately; background coverage is not breaking news.

          Subscribe via RSS · Our news policy

          ${news.length?news.map(a=>`
          Source brief · source event ${a.eventDate}

          ${e(a.title)}

          ${e(a.description)}

          Published ${a.published} · ${e(a.review)}

          `).join(''):'

          The first source briefs are in preparation. Browse the wiki for established concepts.

          '}`); diff --git a/search-index.json b/search-index.json index f2bb012..a24d32c 100644 --- a/search-index.json +++ b/search-index.json @@ -1 +1 @@ -[{"title":"FinOps Framework 2026 adds strategy alignment and broader technology guidance","description":"A background brief on the March framework revision and its relevance to resource-management objectives.","path":"/news/finops-framework-2026/","text":" What changed\nThe FinOps Foundation’s [19 March 2026 framework update]() introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.\n\nThis brief covers that published revision as background, rather than presenting the March announcement as new today.\n\n Why it matters\nEditorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.\n\nRead [FinOps and cost controls](/wiki/finops-and-cost-controls/) for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. [Human oversight](/wiki/human-oversight/) explains why a budget boundary also needs an accountable owner.\n\n Limits of the evidence\nThis is the framework publisher’s description of its own update. It does not establish adoption rates, measured savings, or the effectiveness of any automated product. The implications for resource-control design above are editorial interpretation, not a benchmark result or a requirement imposed by the Foundation.\n"},{"title":"Kubernetes 1.36 expands Dynamic Resource Allocation","description":"A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.","path":"/news/kubernetes-136-resource-allocation/","text":" What changed\nIn its [7 May 2026 update](), the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.\n\nThis is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.\n\n Why it matters\nEditorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.\n\nA useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See [resource scheduling](/wiki/resource-scheduling/) for the distinction between eligible capacity and preferred capacity.\n\n Limits of the evidence\nThe source is a project announcement. This brief does not independently test the features, establish compatibility with a specific cluster, or substantiate performance gains. Check the documentation and feature state for the exact version and driver being evaluated.\n\nThe announcement is evidence of reported project changes, not evidence that every resource-management deployment should adopt them.\n"},{"title":"Headlamp guide separates Kueue admission from Pod scheduling","description":"An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.","path":"/news/kueue-admission-headlamp/","text":" What changed\nA [14 October 2026 Kubernetes project guide]() describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.\n\nThe guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.\n\n Why it matters\nEditorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.\n\nThis distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See [resource scheduling](/wiki/resource-scheduling/) and [observability](/wiki/observability/) for related concepts.\n\n Limits of the evidence\nThis is a summary of a project-authored guide, not an independent evaluation. The plugin is identified as alpha in the source. This brief does not test compatibility, measure troubleshooting speed, or establish that a particular cluster has an admission problem.\n\nRead the original guide for prerequisites and version-specific details before applying its procedure.\n"},{"title":"About this reference","description":"Purpose, authorship, editorial boundaries, and how this resource is maintained.","path":"/about/","text":" A reference for resource decisions\nThis site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.\n\nThe project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.\n\n Maintainer and authorship\nMason Nguyen maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.\n\nThe proposed [ARM working framework](/framework/) is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.\n\n Commercial boundaries\nThis reference has no service checkout or commercial referral directory. Earlier versions directed readers to implementation businesses. The standalone revision removes those pathways while retaining accountable authorship. Removing referrals should not be read as a claim that the maintainer has no outside commercial interests.\n\nRelevant affiliations must be disclosed when they affect a covered subject. See the [editorial policy](/editorial-policy/) for the conflict-of-interest rule.\n\n Maintenance and accountability\nReaders can propose source additions and corrections through [GitHub](). Changes are versioned, and material editorial changes are summarized in the [revision log](/changelog/).\n\nThe wiki is curated rather than open to immediate anonymous publication. Contributions are welcome; publication depends on evidence, relevance, and editorial review.\n\n Historical work records\nThe earlier [public-practice records](/practice/) remain available as historical, first-party work records. They are not independent validation of this reference, product recommendations, or evidence of industry consensus.\n"},{"title":"Revision log","description":"Material changes to the reference, its scope, and editorial practices.","path":"/changelog/","text":" 15 October 2026 — standalone reference revision\n- Reframed the homepage around a source-backed knowledge library.\n- Removed commercial implementation referrals from the reference site's publishing model.\n- Moved the attributed ARM proposal to a dedicated framework page.\n- Added eight introductory wiki articles, source descriptions, and explicit AI-assistance disclosures.\n- Added an editorial policy, correction route, search, and news discovery workflow.\n- Replaced absolute recovery and audit guarantees with implementation-dependent qualifications.\n\nThese entries describe the content revision. Repository history records the exact changes; the deployment record identifies when the revision reaches the public site.\n\n Earlier material\nThe previous homepage and its edits remain available in [repository history](). Its framework has been revised rather than presented as an established industry standard.\n"},{"title":"Contribute or request a correction","description":"A practical route for improving definitions, citations, examples, and industry coverage.","path":"/contribute/","text":" Suggest a factual correction\n[Open a correction request]() with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.\n\nGitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.\n\n Contribute an article\nUse the [public repository]() to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.\n\nDisclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.\n\n Suggest industry coverage\n[Suggest a source or story](). Include the original announcement or research, its date, and the resource-management question it affects. A suggestion does not guarantee coverage.\n\n How changes are reviewed\nSubmissions are checked for factual support, neutral wording, relevant scope, and clear limitations. Technical checks validate internal links and required article metadata. Passing those checks is not a substitute for editorial judgment.\n\nThe maintainer decides whether to publish. Material corrections are recorded in the [revision log](/changelog/), and each article links to its source history.\n"},{"title":"Editorial policy","description":"How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.","path":"/editorial-policy/","text":" Purpose and scope\nAutonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.\n\n Neutral point of view\nDescribe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.\n\nSeparate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.\n\n Source standards\nPrefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.\n\nFor claims of effectiveness, seek reproducible evidence and independent evaluation where available. Identify preprints, vendor benchmarks, and conflicts of interest. Cite evidence near the claim and explain each source's scope in the references.\n\n News and review\nNews briefs distinguish the date of the source event from this site's publication date. Each brief explains what changed, why it may matter, and the limits of the evidence. Older developments may be covered as background; they must not be presented as breaking news.\n\nAutomated discovery places candidates in an editorial queue. It does not publish articles. Before publication, an editor checks the original source, dates, attribution, scope, related wiki entries, and correction needs. The publication record identifies whether the source check was human or AI-assisted. Do not imply independent testing or expert review when neither occurred.\n\n AI assistance\nAI may assist with discovery, drafting, source comparison, and maintenance. Launch articles disclose AI-assisted source synthesis. No invented human reviewer, interview, test result, or credential may be added. A maintainer remains responsible for accepting and correcting published content.\n\n Ownership and conflicts\nThe site is maintained by Mason Nguyen. The previous homepage linked to commercial implementation properties; those referral paths have been removed from the reference site's navigation and content model. This change does not establish independent ownership or erase relevant affiliations.\n\nContributors must disclose a relevant commercial relationship when covering an affiliated product or organization. The site does not sell favorable coverage, rankings, or placement in its reference articles. Author attribution is retained.\n\n Corrections and revision dates\nReport a correction through the [contribution page](/contribute/). Include the URL, disputed passage, and evidence. Material factual corrections receive a visible note and a revision-history entry. Update dates change for substantive edits, not to create an appearance of freshness.\n\n Reuse and attribution\nSummarize sources in original language and link to the original. Do not reproduce full third-party articles or images without permission. Source code visibility does not grant rights to third-party material. This site makes no blanket open-content licensing claim.\n"},{"title":"The ARM working framework","description":"An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.","path":"/framework/","text":" Status and authorship\nThis working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.\n\nEarlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.\n\n Five design concerns\n Decision rights\nIdentify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.\n\n Observable signals\nRecord the measurements and assumptions used in a decision. [OpenTelemetry's signal vocabulary]() is relevant background for instrumentation, not an endorsement of this framework.\n\n Recoverable state\nDefine how interrupted work is identified and recovered. Checkpoints and durable records can help, but their guarantees depend on implementation. This framework does not promise recovery from every failure mode or zero data loss.\n\n Human escalation\nDefine the conditions that require review and the action taken while review is pending. [NIST's AI risk-management work]() supplies broader context; these five concerns are not NIST's categories.\n\n Auditable decisions\nConnect requests, permission, execution, and observed results. Use precise descriptions of retention and tamper resistance instead of assuming a log is immutable.\n\n Applying the proposal\nFor a hypothetical resource controller, write down one permitted action, one limit, its input signal, its recovery behavior, and its escalation owner. Then test a missing signal, a rejected allocation, and an uncertain result.\n\nThis exercise is an editorial method for revealing assumptions. It does not establish that a system is safe, optimal, or compliant.\n\n What would strengthen the framework\nIndependent critique, reproducible examples, failure reports, and comparisons with alternative designs would make the proposal more useful. Contributions should identify which claim they support or challenge. Use the [contribution guide](/contribute/) to propose a change.\n\n Related reference material\nStart with [autonomous resource management](/wiki/autonomous-resource-management/), [human oversight](/wiki/human-oversight/), and [audit trails](/wiki/audit-trails/). Search visibility and structured publishing are separate concerns; they are not prerequisites for a working resource controller.\n"},{"title":"Agent orchestration and tool access","description":"Coordinating work while keeping authority, retries, and external actions explicit.","path":"/wiki/agent-orchestration/","text":" Coordination and authority\nAgent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or [budget](/wiki/finops-and-cost-controls/).\n\nAn orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.\n\n Protocols have a specific scope\nThe [Model Context Protocol architecture, revision 2025-06-18](), describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.\n\nProtocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.\n\n A bounded workflow example\nImagine an agent that proposes resizing a service. A useful separation is:\n\n1. Collect current workload and cost evidence.\n2. Produce a proposal with assumptions and an expiry time.\n3. Check permitted resources, spending limits, and required approval.\n4. Execute the approved action with an operation identifier.\n5. Inspect the actual outcome and record failures or partial completion.\n\nThis is an editorial design example, not a required protocol workflow.\n\n Retries and uncertainty\nA timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.\n\nRelated reading: [human oversight](/wiki/human-oversight/), [audit trails](/wiki/audit-trails/), and the proposed [ARM working framework](/framework/).\n"},{"title":"Audit trails and decision provenance","description":"Recording what was requested, authorized, executed, and observed.","path":"/wiki/audit-trails/","text":" What an audit trail can establish\nAn audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its [authorization context](/wiki/human-oversight/), the attempted action, and the result.\n\n[Kubernetes auditing]() provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.\n\n Design around questions\nAn editorial starting point is to ask whether a reviewer can determine:\n\n1. Who or what requested the change?\n2. Which policy or approval permitted it?\n3. Which measurements were available at the time?\n4. Was the action attempted, completed, rejected, or left uncertain?\n5. What subsequent evidence confirms the outcome?\n\nUse identifiers to connect related events. Keep the original event time distinct from the time a record was received or reviewed.\n\n Integrity and privacy\n“Immutable” is a strong claim. Retention rules, access restrictions, integrity checks, and independent copies provide different protections. State the protections actually implemented rather than assuming that a logging product makes records tamper-proof.\n\nLogs can also contain sensitive information. Decide what is necessary to retain, who can access it, and how long it remains useful. An exhaustive transcript is not automatically the best audit record.\n\n Limits\nA record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.\n\nCombine audit evidence with [observability](/wiki/observability/) and [human review](/wiki/human-oversight/). Claims about system reliability need tests and operational evidence beyond the existence of logs.\n"},{"title":"What is autonomous resource management?","description":"A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.","path":"/wiki/autonomous-resource-management/","text":" Definition and scope\nAutonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.\n\nA useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.\n\n How the pieces fit together\nA resource-management design needs a target, [measurements](/wiki/observability/), a decision mechanism, and a way to act. Use [audit trails](/wiki/audit-trails/) to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](). The broader connection to ARM is our editorial synthesis.\n\nConsider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.\n\n Related disciplines\n- [Autoscaling](/wiki/autoscaling/) changes capacity in response to signals.\n- [Resource scheduling](/wiki/resource-scheduling/) decides where work can run.\n- [Orchestration](/wiki/agent-orchestration/) coordinates dependent work and tool interactions.\n- [FinOps and cost controls](/wiki/finops-and-cost-controls/) connect resource use to financial accountability. The [FinOps Framework]() describes an operating practice that involves engineering, finance, and business participants.\n- [Human oversight](/wiki/human-oversight/) addresses authority, review, and intervention.\n\n Boundaries and open questions\nThe appropriate degree of autonomy depends on the reversibility of an action, the reliability of its evidence, and the people affected. A low-risk scaling decision and an irreversible spending commitment should not be treated as equivalent.\n\nThe [ARM working framework](/framework/) offers one proposed way to organize these questions. Its five design concerns are an attributed synthesis rather than an industry standard or a prerequisite for every automated resource system.\n"},{"title":"Autoscaling and feedback loops","description":"How capacity follows demand, and why signals, limits, and recovery matter.","path":"/wiki/autoscaling/","text":" What autoscaling changes\nAutoscaling adjusts capacity in response to observed or anticipated demand. The [Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling](). Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.\n\nChoosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare [resource scheduling and allocation](/wiki/resource-scheduling/) when the problem is where work can run.\n\n Signals and decisions\nA controller compares [measurements](/wiki/observability/) with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.\n\nFor a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.\n\n Tradeoffs to evaluate\n- Responsiveness: a fast reaction can reduce waiting but may chase short-lived noise.\n- Stability: frequent opposing adjustments can interrupt work or waste capacity.\n- Cost: spare capacity can improve response time while increasing spend.\n- Availability: a request to scale does not prove that capacity was obtained.\n\nReview these tradeoffs together. [Cost controls](/wiki/finops-and-cost-controls/) and [observability](/wiki/observability/) make the operating consequences easier to inspect.\n\n Failure and recovery\nSpecify the response to stale metrics, failed allocations, quota exhaustion, and interrupted scale-down. Test those responses against the actual workload. A controller should not interpret missing demand data as proof that demand is zero.\n\nThe underlying loop is described in [Kubernetes controller concepts](). Applying that pattern to a particular service still requires workload-specific measurement and testing.\n"},{"title":"FinOps and cost controls","description":"Relating resource consumption, budgets, and business outcomes without assuming automatic savings.","path":"/wiki/finops-and-cost-controls/","text":" Financial accountability\nThe [FinOps Framework]() brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.\n\nA useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.\n\n Design the budget boundary\nFor a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.\n\nA cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.\n\n Resource limits are not currency limits\n[Kubernetes resource quotas]() can constrain resource requests or object counts. Their units and scope differ from a bill denominated in currency. Translating a resource allowance into a cost expectation requires pricing assumptions and usage context.\n\n Evaluate claims carefully\nWhen someone reports savings, ask which baseline, workload, period, prices, and service-quality targets were used. Distinguish a projected saving from an observed reduction in paid costs. A lower cost per operation can coexist with higher total spend if demand grows.\n\nThese evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.\n\nRelated: [autoscaling](/wiki/autoscaling/), [resource scheduling](/wiki/resource-scheduling/), and [observability](/wiki/observability/).\n"},{"title":"Human oversight and decision rights","description":"Defining who can authorize, interrupt, and review automated resource decisions.","path":"/wiki/human-oversight/","text":" Oversight needs an operational meaning\nHuman oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.\n\nThe [NIST AI Risk Management Framework]() provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.\n\n Define the delegated scope\nAs an editorial design checklist, document:\n\n- Which resources and actions the system may control.\n- The limits on amount, duration, and frequency.\n- Which actions need approval before execution.\n- Who can pause the system and revoke access.\n- How an operator learns about a failed or incomplete action.\n\nSeparate permission from confidence. A system can be highly confident about an action it is not authorized to take.\n\n Escalation example\nA hypothetical workflow may automatically add a small amount of reversible capacity, require approval for a larger change, and refuse to make an irreversible commitment without explicit authorization. If the approver is unavailable, the policy must specify whether to wait, retain the existing state, or follow another documented fallback.\n\nSilence should not be interpreted as newly granted authority. This is the site's design recommendation, not a quoted NIST requirement.\n\n Review and learning\nAfter a consequential event, compare the authorized action, the recorded action, and the observed outcome. Update the policy when evidence shows that an assumption was wrong. Document unresolved questions as well as successes.\n\nRelated: [agent orchestration](/wiki/agent-orchestration/), [audit trails](/wiki/audit-trails/), and [the proposed ARM framework](/framework/).\n"},{"title":"Observability for resource decisions","description":"Connecting measurements to actions without mistaking telemetry for proof of correctness.","path":"/wiki/observability/","text":" Observe the system and its decisions\nObservability helps operators investigate system behavior from available evidence. [OpenTelemetry describes signals such as traces, metrics, and logs](), which offer different views of system activity.\n\nFor resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.\n\n A useful decision record\nAs editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.\n\nSeparate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.\n\n Evidence quality\nA signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric for [autoscaling](/wiki/autoscaling/), define how old it may be and how the system should behave when the data is unavailable.\n\nFor example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default.\n\n Limits\nTelemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.\n\nUse [audit trails](/wiki/audit-trails/) to preserve decision context and [human oversight](/wiki/human-oversight/) to define who responds when evidence is insufficient.\n"},{"title":"Resource scheduling and allocation","description":"Placement decisions, competing objectives, and the difference between capacity and usable capacity.","path":"/wiki/resource-scheduling/","text":" What a scheduler decides\nA scheduler matches work to eligible resources. It has to respect constraints before considering preferences. [Kubernetes describes filtering candidate nodes and scoring the feasible ones]().\n\nScheduling is distinct from [autoscaling](/wiki/autoscaling/). A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.\n\n Constraints before preferences\nIn a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.\n\nRecord which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.\n\n Questions for an allocation policy\n1. Which workloads can wait, and for how long?\n2. Can lower-priority work be interrupted without losing progress?\n3. How is scarce capacity shared between teams?\n4. What happens when no eligible resource exists?\n5. What evidence explains a rejected or delayed allocation?\n\nThese questions are editorial design guidance. Answers need to be validated against the workload and the resource provider.\n\n Limits and related concepts\n[Resource quotas]() constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.\n\nRead [autoscaling](/wiki/autoscaling/) for capacity adjustments and [audit trails](/wiki/audit-trails/) for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.\n"}] \ No newline at end of file +[{"title":"FinOps Framework 2026 adds strategy alignment and broader technology guidance","description":"A background brief on the March framework revision and its relevance to resource-management objectives.","path":"/news/finops-framework-2026/","text":" What changed\nThe FinOps Foundation’s [19 March 2026 framework update]() introduced Executive Strategy Alignment as a capability and expanded guidance around scopes and technology categories. The announcement includes AI among the technology categories addressed.\n\nThis brief covers that published revision as background, rather than presenting the March announcement as new today.\n\n Why it matters\nEditorial interpretation: an automated allocation policy needs an explicit business objective. Minimizing immediate spending, reducing waiting, and preserving capacity for experimentation can lead to different decisions. A cost controller needs to know which tradeoff its owner has authorized.\n\nRead [FinOps and cost controls](/wiki/finops-and-cost-controls/) for the distinction between forecasts, alerts, resource quotas, and enforced spending limits. [Human oversight](/wiki/human-oversight/) explains why a budget boundary also needs an accountable owner.\n\n Limits of the evidence\nThis is the framework publisher’s description of its own update. It does not establish adoption rates, measured savings, or the effectiveness of any automated product. The implications for resource-control design above are editorial interpretation, not a benchmark result or a requirement imposed by the Foundation.\n"},{"title":"Kubernetes 1.36 expands Dynamic Resource Allocation","description":"A background brief on the DRA team’s May 2026 update, with adoption questions for resource operators.","path":"/news/kubernetes-136-resource-allocation/","text":" What changed\nIn its [7 May 2026 update](), the Kubernetes DRA team described changes to Dynamic Resource Allocation in version 1.36, including feature graduations, additional capabilities, and a broader driver ecosystem. The announcement discusses specialized hardware as well as work involving CPU and memory resources.\n\nThis is background coverage of that announcement, not a claim that version 1.36 is the latest Kubernetes release.\n\n Why it matters\nEditorial interpretation: resource operators should evaluate the exact allocation capability their workloads need, rather than treating “DRA support” as a single feature. Hardware requirements, drivers, and the maturity of individual capabilities affect what a deployment can use.\n\nA useful evaluation question is whether an allocation request expresses the actual constraints of the workload. See [resource scheduling](/wiki/resource-scheduling/) for the distinction between eligible capacity and preferred capacity.\n\n Limits of the evidence\nThe source is a project announcement. This brief does not independently test the features, establish compatibility with a specific cluster, or substantiate performance gains. Check the documentation and feature state for the exact version and driver being evaluated.\n\nThe announcement is evidence of reported project changes, not evidence that every resource-management deployment should adopt them.\n"},{"title":"Headlamp guide separates Kueue admission from Pod scheduling","description":"An October 2026 project guide illustrates why a queued workload may wait before Pod placement begins.","path":"/news/kueue-admission-headlamp/","text":" What changed\nA [14 October 2026 Kubernetes project guide]() describes investigating Kueue admission through Headlamp. It distinguishes the decision to admit a workload under queue policy and quota from the later placement of Pods on nodes.\n\nThe guide uses the Kueue plugin’s 0.1.0-alpha release. It describes read-only Kueue views, while noting that Headlamp’s standard resource actions remain subject to the user’s permissions.\n\n Why it matters\nEditorial interpretation: diagnosing a resource delay starts with locating the decision that is waiting. A workload that has not been admitted needs a different investigation from one whose Pods cannot find eligible nodes.\n\nThis distinction can prevent an operator from treating every pending job as a shortage of physical capacity. See [resource scheduling](/wiki/resource-scheduling/) and [observability](/wiki/observability/) for related concepts.\n\n Limits of the evidence\nThis is a summary of a project-authored guide, not an independent evaluation. The plugin is identified as alpha in the source. This brief does not test compatibility, measure troubleshooting speed, or establish that a particular cluster has an admission problem.\n\nRead the original guide for prerequisites and version-specific details before applying its procedure.\n"},{"title":"About this reference","description":"Purpose, authorship, editorial boundaries, and how this resource is maintained.","path":"/about/","text":" A reference for resource decisions\nThis site helps readers understand how automated systems allocate resources and how people can inspect and govern those decisions. Its initial focus is compute infrastructure, workload coordination, technology costs, and human oversight.\n\nThe project aims to earn trust through useful explanations, primary citations, clear limitations, and visible corrections. It does not claim to be the definitive authority or a standards body.\n\n Maintainer and authorship\n[Mason Nguyen on LinkedIn]() maintains the site and its public source repository. “ARM Editorial” identifies this site's editorial voice; it is not a claim that an independent editorial board exists. The initial reference articles were prepared with AI assistance, as disclosed on each article.\n\nThe proposed [ARM working framework](/framework/) is attributed separately. Its existence does not establish consensus around that framework or the site's terminology.\n\n Commercial boundaries\nThis reference has no service checkout or commercial referral directory. Earlier versions directed readers to implementation businesses. The standalone revision removes those pathways while retaining accountable authorship. Removing referrals should not be read as a claim that the maintainer has no outside commercial interests.\n\nRelevant affiliations must be disclosed when they affect a covered subject. See the [editorial policy](/editorial-policy/) for the conflict-of-interest rule.\n\n Maintenance and accountability\nReaders can propose source additions and corrections through [GitHub](). Changes are versioned, and material editorial changes are summarized in the [revision log](/changelog/).\n\nThe wiki is curated rather than open to immediate anonymous publication. Contributions are welcome; publication depends on evidence, relevance, and editorial review.\n\n Historical work records\nThe earlier [public-practice records](/practice/) remain available as historical, first-party work records. They are not independent validation of this reference, product recommendations, or evidence of industry consensus.\n"},{"title":"Revision log","description":"Material changes to the reference, its scope, and editorial practices.","path":"/changelog/","text":" 15 October 2026 — standalone reference revision\n- Reframed the homepage around a source-backed knowledge library.\n- Removed commercial implementation referrals from the reference site's publishing model.\n- Moved the attributed ARM proposal to a dedicated framework page.\n- Added eight introductory wiki articles, source descriptions, and explicit AI-assistance disclosures.\n- Added an editorial policy, correction route, search, and news discovery workflow.\n- Replaced absolute recovery and audit guarantees with implementation-dependent qualifications.\n\nThese entries describe the content revision. Repository history records the exact changes; the deployment record identifies when the revision reaches the public site.\n\n Earlier material\nThe previous homepage and its edits remain available in [repository history](). Its framework has been revised rather than presented as an established industry standard.\n"},{"title":"Contribute or request a correction","description":"A practical route for improving definitions, citations, examples, and industry coverage.","path":"/contribute/","text":" Suggest a factual correction\n[Open a correction request]() with the page URL, the exact passage, a proposed correction, and a supporting source. State whether the issue is a factual error, outdated information, unclear wording, or a missing perspective.\n\nGitHub requires an account to submit an issue. Please omit private operational data, credentials, and personal information from public reports.\n\n Contribute an article\nUse the [public repository]() to propose a Markdown article or an edit. Explain the topic's relevance, cite original sources, and distinguish sourced facts from your own examples and analysis.\n\nDisclose relevant affiliations. State whether AI assisted with drafting or verification. Do not invent review credentials or imply that a cited project endorses this site.\n\n Suggest industry coverage\n[Suggest a source or story](). Include the original announcement or research, its date, and the resource-management question it affects. A suggestion does not guarantee coverage.\n\n How changes are reviewed\nSubmissions are checked for factual support, neutral wording, relevant scope, and clear limitations. Technical checks validate internal links and required article metadata. Passing those checks is not a substitute for editorial judgment.\n\nThe maintainer decides whether to publish. Material corrections are recorded in the [revision log](/changelog/), and each article links to its source history.\n"},{"title":"Editorial policy","description":"How this reference handles neutrality, sources, uncertainty, AI assistance, and corrections.","path":"/editorial-policy/","text":" Purpose and scope\nAutonomous Resource Management is an editorially maintained knowledge resource about automated allocation, orchestration, infrastructure, and oversight. Coverage is selected for its relevance and evidence, not for its ability to refer readers to a commercial provider.\n\n Neutral point of view\nDescribe what a source demonstrates and what remains uncertain. Attribute disputed claims. Give approaches attention proportional to their relevance and supporting evidence; neutrality does not require giving unsupported claims equal weight.\n\nSeparate established technical concepts, the site's proposed framework, and dated industry developments. Examples and recommendations must be labeled as editorial guidance unless directly supported by cited evidence.\n\n Source standards\nPrefer original specifications, project documentation, public research, and official announcements for factual descriptions. An official announcement establishes what its publisher says; it does not independently validate performance or market leadership.\n\nFor claims of effectiveness, seek reproducible evidence and independent evaluation where available. Identify preprints, vendor benchmarks, and conflicts of interest. Cite evidence near the claim and explain each source's scope in the references.\n\n News and review\nNews briefs distinguish the date of the source event from this site's publication date. Each brief explains what changed, why it may matter, and the limits of the evidence. Older developments may be covered as background; they must not be presented as breaking news.\n\nAutomated discovery places candidates in an editorial queue. It does not publish articles. Before publication, an editor checks the original source, dates, attribution, scope, related wiki entries, and correction needs. The publication record identifies whether the source check was human or AI-assisted. Do not imply independent testing or expert review when neither occurred.\n\n AI assistance\nAI may assist with discovery, drafting, source comparison, and maintenance. Launch articles disclose AI-assisted source synthesis. No invented human reviewer, interview, test result, or credential may be added. A maintainer remains responsible for accepting and correcting published content.\n\n Ownership and conflicts\nThe site is maintained by Mason Nguyen. The previous homepage linked to commercial implementation properties; those referral paths have been removed from the reference site's navigation and content model. This change does not establish independent ownership or erase relevant affiliations.\n\nContributors must disclose a relevant commercial relationship when covering an affiliated product or organization. The site does not sell favorable coverage, rankings, or placement in its reference articles. Author attribution is retained.\n\n Corrections and revision dates\nReport a correction through the [contribution page](/contribute/). Include the URL, disputed passage, and evidence. Material factual corrections receive a visible note and a revision-history entry. Update dates change for substantive edits, not to create an appearance of freshness.\n\n Reuse and attribution\nSummarize sources in original language and link to the original. Do not reproduce full third-party articles or images without permission. Source code visibility does not grant rights to third-party material. This site makes no blanket open-content licensing claim.\n"},{"title":"The ARM working framework","description":"An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.","path":"/framework/","text":" Status and authorship\nThis working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.\n\nEarlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.\n\n Five design concerns\n Decision rights\nIdentify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.\n\n Observable signals\nRecord the measurements and assumptions used in a decision. [OpenTelemetry's signal vocabulary]() is relevant background for instrumentation, not an endorsement of this framework.\n\n Recoverable state\nDefine how interrupted work is identified and recovered. Checkpoints and durable records can help, but their guarantees depend on implementation. This framework does not promise recovery from every failure mode or zero data loss.\n\n Human escalation\nDefine the conditions that require review and the action taken while review is pending. [NIST's AI risk-management work]() supplies broader context; these five concerns are not NIST's categories.\n\n Auditable decisions\nConnect requests, permission, execution, and observed results. Use precise descriptions of retention and tamper resistance instead of assuming a log is immutable.\n\n Applying the proposal\nFor a hypothetical resource controller, write down one permitted action, one limit, its input signal, its recovery behavior, and its escalation owner. Then test a missing signal, a rejected allocation, and an uncertain result.\n\nThis exercise is an editorial method for revealing assumptions. It does not establish that a system is safe, optimal, or compliant.\n\n What would strengthen the framework\nIndependent critique, reproducible examples, failure reports, and comparisons with alternative designs would make the proposal more useful. Contributions should identify which claim they support or challenge. Use the [contribution guide](/contribute/) to propose a change.\n\n Related reference material\nStart with [autonomous resource management](/wiki/autonomous-resource-management/), [human oversight](/wiki/human-oversight/), and [audit trails](/wiki/audit-trails/). Search visibility and structured publishing are separate concerns; they are not prerequisites for a working resource controller.\n"},{"title":"Agent orchestration and tool access","description":"Coordinating work while keeping authority, retries, and external actions explicit.","path":"/wiki/agent-orchestration/","text":" Coordination and authority\nAgent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or [budget](/wiki/finops-and-cost-controls/).\n\nAn orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.\n\n Protocols have a specific scope\nThe [Model Context Protocol architecture, revision 2025-06-18](), describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.\n\nProtocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.\n\n A bounded workflow example\nImagine an agent that proposes resizing a service. A useful separation is:\n\n1. Collect current workload and cost evidence.\n2. Produce a proposal with assumptions and an expiry time.\n3. Check permitted resources, spending limits, and required approval.\n4. Execute the approved action with an operation identifier.\n5. Inspect the actual outcome and record failures or partial completion.\n\nThis is an editorial design example, not a required protocol workflow.\n\n Retries and uncertainty\nA timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.\n\nRelated reading: [human oversight](/wiki/human-oversight/), [audit trails](/wiki/audit-trails/), and the proposed [ARM working framework](/framework/).\n"},{"title":"Audit trails and decision provenance","description":"Recording what was requested, authorized, executed, and observed.","path":"/wiki/audit-trails/","text":" What an audit trail can establish\nAn audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its [authorization context](/wiki/human-oversight/), the attempted action, and the result.\n\n[Kubernetes auditing]() provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.\n\n Design around questions\nAn editorial starting point is to ask whether a reviewer can determine:\n\n1. Who or what requested the change?\n2. Which policy or approval permitted it?\n3. Which measurements were available at the time?\n4. Was the action attempted, completed, rejected, or left uncertain?\n5. What subsequent evidence confirms the outcome?\n\nUse identifiers to connect related events. Keep the original event time distinct from the time a record was received or reviewed.\n\n Integrity and privacy\n“Immutable” is a strong claim. Retention rules, access restrictions, integrity checks, and independent copies provide different protections. State the protections actually implemented rather than assuming that a logging product makes records tamper-proof.\n\nLogs can also contain sensitive information. Decide what is necessary to retain, who can access it, and how long it remains useful. An exhaustive transcript is not automatically the best audit record.\n\n Limits\nA record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.\n\nCombine audit evidence with [observability](/wiki/observability/) and [human review](/wiki/human-oversight/). Claims about system reliability need tests and operational evidence beyond the existence of logs.\n"},{"title":"What is autonomous resource management?","description":"A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.","path":"/wiki/autonomous-resource-management/","text":" Definition and scope\nAutonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.\n\nA useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.\n\n How the pieces fit together\nA resource-management design needs a target, [measurements](/wiki/observability/), a decision mechanism, and a way to act. Use [audit trails](/wiki/audit-trails/) to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: [controllers reconcile observed state with desired state](). The broader connection to ARM is our editorial synthesis.\n\nConsider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.\n\n Related disciplines\n- [Autoscaling](/wiki/autoscaling/) changes capacity in response to signals.\n- [Resource scheduling](/wiki/resource-scheduling/) decides where work can run.\n- [Orchestration](/wiki/agent-orchestration/) coordinates dependent work and tool interactions.\n- [FinOps and cost controls](/wiki/finops-and-cost-controls/) connect resource use to financial accountability. The [FinOps Framework]() describes an operating practice that involves engineering, finance, and business participants.\n- [Human oversight](/wiki/human-oversight/) addresses authority, review, and intervention.\n\n Boundaries and open questions\nThe appropriate degree of autonomy depends on the reversibility of an action, the reliability of its evidence, and the people affected. A low-risk scaling decision and an irreversible spending commitment should not be treated as equivalent.\n\nThe [ARM working framework](/framework/) offers one proposed way to organize these questions. Its five design concerns are an attributed synthesis rather than an industry standard or a prerequisite for every automated resource system.\n"},{"title":"Autoscaling and feedback loops","description":"How capacity follows demand, and why signals, limits, and recovery matter.","path":"/wiki/autoscaling/","text":" What autoscaling changes\nAutoscaling adjusts capacity in response to observed or anticipated demand. The [Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling](). Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.\n\nChoosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare [resource scheduling and allocation](/wiki/resource-scheduling/) when the problem is where work can run.\n\n Signals and decisions\nA controller compares [measurements](/wiki/observability/) with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.\n\nFor a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.\n\n Tradeoffs to evaluate\n- Responsiveness: a fast reaction can reduce waiting but may chase short-lived noise.\n- Stability: frequent opposing adjustments can interrupt work or waste capacity.\n- Cost: spare capacity can improve response time while increasing spend.\n- Availability: a request to scale does not prove that capacity was obtained.\n\nReview these tradeoffs together. [Cost controls](/wiki/finops-and-cost-controls/) and [observability](/wiki/observability/) make the operating consequences easier to inspect.\n\n Failure and recovery\nSpecify the response to stale metrics, failed allocations, quota exhaustion, and interrupted scale-down. Test those responses against the actual workload. A controller should not interpret missing demand data as proof that demand is zero.\n\nThe underlying loop is described in [Kubernetes controller concepts](). Applying that pattern to a particular service still requires workload-specific measurement and testing.\n"},{"title":"FinOps and cost controls","description":"Relating resource consumption, budgets, and business outcomes without assuming automatic savings.","path":"/wiki/finops-and-cost-controls/","text":" Financial accountability\nThe [FinOps Framework]() brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.\n\nA useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.\n\n Design the budget boundary\nFor a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.\n\nA cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.\n\n Resource limits are not currency limits\n[Kubernetes resource quotas]() can constrain resource requests or object counts. Their units and scope differ from a bill denominated in currency. Translating a resource allowance into a cost expectation requires pricing assumptions and usage context.\n\n Evaluate claims carefully\nWhen someone reports savings, ask which baseline, workload, period, prices, and service-quality targets were used. Distinguish a projected saving from an observed reduction in paid costs. A lower cost per operation can coexist with higher total spend if demand grows.\n\nThese evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.\n\nRelated: [autoscaling](/wiki/autoscaling/), [resource scheduling](/wiki/resource-scheduling/), and [observability](/wiki/observability/).\n"},{"title":"Human oversight and decision rights","description":"Defining who can authorize, interrupt, and review automated resource decisions.","path":"/wiki/human-oversight/","text":" Oversight needs an operational meaning\nHuman oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.\n\nThe [NIST AI Risk Management Framework]() provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.\n\n Define the delegated scope\nAs an editorial design checklist, document:\n\n- Which resources and actions the system may control.\n- The limits on amount, duration, and frequency.\n- Which actions need approval before execution.\n- Who can pause the system and revoke access.\n- How an operator learns about a failed or incomplete action.\n\nSeparate permission from confidence. A system can be highly confident about an action it is not authorized to take.\n\n Escalation example\nA hypothetical workflow may automatically add a small amount of reversible capacity, require approval for a larger change, and refuse to make an irreversible commitment without explicit authorization. If the approver is unavailable, the policy must specify whether to wait, retain the existing state, or follow another documented fallback.\n\nSilence should not be interpreted as newly granted authority. This is the site's design recommendation, not a quoted NIST requirement.\n\n Review and learning\nAfter a consequential event, compare the authorized action, the recorded action, and the observed outcome. Update the policy when evidence shows that an assumption was wrong. Document unresolved questions as well as successes.\n\nRelated: [agent orchestration](/wiki/agent-orchestration/), [audit trails](/wiki/audit-trails/), and [the proposed ARM framework](/framework/).\n"},{"title":"Observability for resource decisions","description":"Connecting measurements to actions without mistaking telemetry for proof of correctness.","path":"/wiki/observability/","text":" Observe the system and its decisions\nObservability helps operators investigate system behavior from available evidence. [OpenTelemetry describes signals such as traces, metrics, and logs](), which offer different views of system activity.\n\nFor resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.\n\n A useful decision record\nAs editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.\n\nSeparate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.\n\n Evidence quality\nA signal can be delayed, sampled, missing, or incorrectly labeled. Before using a metric for [autoscaling](/wiki/autoscaling/), define how old it may be and how the system should behave when the data is unavailable.\n\nFor example, a hypothetical capacity controller could hold its last safe allocation and notify an operator when its demand signal becomes stale. That is one possible policy, not a universal default.\n\n Limits\nTelemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.\n\nUse [audit trails](/wiki/audit-trails/) to preserve decision context and [human oversight](/wiki/human-oversight/) to define who responds when evidence is insufficient.\n"},{"title":"Resource scheduling and allocation","description":"Placement decisions, competing objectives, and the difference between capacity and usable capacity.","path":"/wiki/resource-scheduling/","text":" What a scheduler decides\nA scheduler matches work to eligible resources. It has to respect constraints before considering preferences. [Kubernetes describes filtering candidate nodes and scoring the feasible ones]().\n\nScheduling is distinct from [autoscaling](/wiki/autoscaling/). A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.\n\n Constraints before preferences\nIn a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.\n\nRecord which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.\n\n Questions for an allocation policy\n1. Which workloads can wait, and for how long?\n2. Can lower-priority work be interrupted without losing progress?\n3. How is scarce capacity shared between teams?\n4. What happens when no eligible resource exists?\n5. What evidence explains a rejected or delayed allocation?\n\nThese questions are editorial design guidance. Answers need to be validated against the workload and the resource provider.\n\n Limits and related concepts\n[Resource quotas]() constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.\n\nRead [autoscaling](/wiki/autoscaling/) for capacity adjustments and [audit trails](/wiki/audit-trails/) for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.\n"}] \ No newline at end of file diff --git a/search/index.html b/search/index.html index dda2a25..e5ed8a7 100644 --- a/search/index.html +++ b/search/index.html @@ -2,4 +2,4 @@ Search the reference | Autonomous Resource Management
          Autonomous Resource
          ManagementKnowledge · Context · Evidence
          Find a concept

          Search the reference

          Loading the reference index…

            - + diff --git a/sources/index.html b/sources/index.html index 05921fe..99f7e0a 100644 --- a/sources/index.html +++ b/sources/index.html @@ -2,4 +2,4 @@ Sources and evidence | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            Evidence directory

            Start with the source.

            Documentation supports descriptions of a system. Announcements establish what a publisher reports. Neither alone proves performance in your environment.

            Source selection

            These are cited sources, not endorsements or an exhaustive industry list. The initial library emphasizes infrastructure documentation. Broader research and independently evaluated case studies are an editorial priority.

            1. FinOps Foundation: FinOps Framework 2026Official publisher announcement; supports attributed changes, not independent outcome claims.

              Used in: FinOps Framework 2026 adds strategy alignment and broader technology guidance.

            2. Kubernetes DRA team: Kubernetes v1.36 DRA updatesOfficial publisher announcement; supports attributed changes, not independent outcome claims.

              Used in: Kubernetes 1.36 expands Dynamic Resource Allocation.

            3. Kubernetes project blog: Tracing Kueue admission with HeadlampProject-authored guide; supports the described troubleshooting distinction and plugin limitations.

              Used in: Headlamp guide separates Kueue admission from Pod scheduling.

            4. OpenTelemetry: SignalsTelemetry signals used to describe system activity.

              Used in: The ARM working framework; Observability for resource decisions.

            5. NIST: AI Risk Management FrameworkVoluntary AI risk management guidance.

              Used in: The ARM working framework; Human oversight and decision rights.

            6. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.

              Used in: Agent orchestration and tool access.

            7. Kubernetes: AuditingAPI audit events, policy, and storage backends.

              Used in: Audit trails and decision provenance.

            8. Kubernetes: ControllersControl loops and desired state.

              Used in: What is autonomous resource management?; Autoscaling and feedback loops.

            9. FinOps Foundation: FrameworkCollaborative technology value and cost management.

              Used in: What is autonomous resource management?; FinOps and cost controls.

            10. Kubernetes: Autoscaling workloadsHorizontal, vertical, and infrastructure scaling.

              Used in: Autoscaling and feedback loops.

            11. Kubernetes: Resource quotasNamespace resource constraints and their scope.

              Used in: FinOps and cost controls; Resource scheduling and allocation.

            12. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.

              Used in: Resource scheduling and allocation.

            Suggest additional evidence

            We welcome relevant research, alternative approaches, and reproducible failure reports. Propose a source with the claim it supports or challenges.

            - + diff --git a/wiki/agent-orchestration/index.html b/wiki/agent-orchestration/index.html index eeaa9f0..6342997 100644 --- a/wiki/agent-orchestration/index.html +++ b/wiki/agent-orchestration/index.html @@ -1,7 +1,7 @@ Agent orchestration and tool access | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Agent orchestration and tool access

            Coordinating work while keeping authority, retries, and external actions explicit.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Coordination and authority

            Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget.

            +
            Wiki reference

            Agent orchestration and tool access

            Coordinating work while keeping authority, retries, and external actions explicit.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Coordination and authority

            Agent orchestration coordinates tasks, state, tools, and dependencies. Resource management enters when a workflow consumes execution slots, model calls, compute time, or budget.

            An orchestration system may use deterministic rules, AI-assisted decisions, or a mixture. A language model's proposed action should be distinguishable from the component authorized to execute it.

            Protocols have a specific scope

            The Model Context Protocol architecture, revision 2025-06-18, describes hosts, clients, and servers with distinct responsibilities. A connection to a tool server is not evidence that every possible operation is appropriate for a particular user or workflow.

            Protocol support should therefore be documented separately from resource limits, permission checks, and evidence of successful execution. This article cites a specific protocol revision; consult the project's current specification when implementing.

            @@ -17,4 +17,4 @@

            A bounded workflow example

            Imagine an

            Retries and uncertainty

            A timeout can mean an action failed, succeeded, or is still running. Repeating a request without checking its status can create duplicate work or spending. Recovery design should specify how to recognize an existing operation and when to ask for human intervention.

            Related reading: human oversight, audit trails, and the proposed ARM working framework.

            Sources and scope

            1. Model Context Protocol: Architecture, 2025-06-18Host, client, and server responsibilities in this protocol revision.

            Continue reading

            Explore orchestration and human oversight: Which actions can a workflow take, and who can intervene?

            For the wider context, read what autonomous resource management means.

            View revision history · View article source · Suggest a correction

            - + diff --git a/wiki/audit-trails/index.html b/wiki/audit-trails/index.html index 23ca464..2fb6967 100644 --- a/wiki/audit-trails/index.html +++ b/wiki/audit-trails/index.html @@ -1,7 +1,7 @@ Audit trails and decision provenance | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Audit trails and decision provenance

            Recording what was requested, authorized, executed, and observed.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What an audit trail can establish

            An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result.

            +
            Wiki reference

            Audit trails and decision provenance

            Recording what was requested, authorized, executed, and observed.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What an audit trail can establish

            An audit trail records events so that a decision or action can be examined later. In a resource system, useful events include a request, its authorization context, the attempted action, and the result.

            Kubernetes auditing provides a concrete example of configurable records for API activity. What is recorded depends on the audit policy and backend configuration.

            Design around questions

            An editorial starting point is to ask whether a reviewer can determine:

              @@ -17,4 +17,4 @@

              Integrity and privacy

              “Immutable” is a

              Limits

              A record of an authorized request does not prove the action succeeded. A record of success does not by itself prove that the action was appropriate. Missing records can reflect a collection failure rather than the absence of activity.

              Combine audit evidence with observability and human review. Claims about system reliability need tests and operational evidence beyond the existence of logs.

              Sources and scope

              1. Kubernetes: AuditingAPI audit events, policy, and storage backends.

              Continue reading

              Explore cost and operational evidence: What did the system consume, and what evidence explains it?

              For the wider context, read what autonomous resource management means.

              View revision history · View article source · Suggest a correction

            - + diff --git a/wiki/autonomous-resource-management/index.html b/wiki/autonomous-resource-management/index.html index 9782369..9deea1c 100644 --- a/wiki/autonomous-resource-management/index.html +++ b/wiki/autonomous-resource-management/index.html @@ -1,7 +1,7 @@ What is autonomous resource management? | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            What is autonomous resource management?

            A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Definition and scope

            Autonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.

            +
            Wiki reference

            What is autonomous resource management?

            A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Definition and scope

            Autonomous resource management describes systems that observe resource conditions and adjust allocations within defined operating limits. In this reference, resources include compute capacity, storage, workload slots, and technology budgets. This is the site's working scope, not a claim that one definition is universally standardized.

            A useful example is a service that adds capacity when demand rises, subject to an upper limit and a response-time objective. The word “autonomous” describes the delegated decision scope; it does not establish that the system uses an AI model or can safely operate without supervision.

            How the pieces fit together

            A resource-management design needs a target, measurements, a decision mechanism, and a way to act. Use audit trails to examine the resulting decisions. Kubernetes documents a concrete form of this pattern: controllers reconcile observed state with desired state. The broader connection to ARM is our editorial synthesis.

            Consider a queue of image-processing jobs. A controller may observe queue age, request more workers, and stop increasing capacity at a configured limit. A complete operational design must also decide what happens when metrics disappear, capacity is unavailable, or the next action exceeds the approved budget. Those are design questions, not benefits automatically conferred by automation.

            @@ -15,4 +15,4 @@
            - + diff --git a/wiki/autoscaling/index.html b/wiki/autoscaling/index.html index 00fcc47..2bdb4a3 100644 --- a/wiki/autoscaling/index.html +++ b/wiki/autoscaling/index.html @@ -1,7 +1,7 @@ Autoscaling and feedback loops | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Autoscaling and feedback loops

            How capacity follows demand, and why signals, limits, and recovery matter.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What autoscaling changes

            Autoscaling adjusts capacity in response to observed or anticipated demand. The Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling. Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.

            +
            Wiki reference

            Autoscaling and feedback loops

            How capacity follows demand, and why signals, limits, and recovery matter.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What autoscaling changes

            Autoscaling adjusts capacity in response to observed or anticipated demand. The Kubernetes documentation distinguishes horizontal scaling, vertical scaling, and infrastructure scaling. Adding replicas, changing resources assigned to a workload, and adding nodes affect different parts of a system.

            Choosing a scaling mechanism starts with the bottleneck. More application replicas may not help a saturated shared database. More node capacity may not help an application that cannot use it. Compare resource scheduling and allocation when the problem is where work can run.

            Signals and decisions

            A controller compares measurements with a target and requests a change. Signals might include queue age, request latency, or resource utilization. The useful signal depends on what the service is trying to achieve.

            For a hypothetical batch queue, an editor's design example is: add one worker when the oldest job exceeds an agreed wait threshold, cap the worker count, and require a stable period before removing capacity. The example illustrates decision structure; it is not a tested production configuration.

            @@ -15,4 +15,4 @@

            Tradeoffs to evaluate

            - + diff --git a/wiki/finops-and-cost-controls/index.html b/wiki/finops-and-cost-controls/index.html index 65db6ba..e4ac8ac 100644 --- a/wiki/finops-and-cost-controls/index.html +++ b/wiki/finops-and-cost-controls/index.html @@ -1,7 +1,7 @@ FinOps and cost controls | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            FinOps and cost controls

            Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Financial accountability

            The FinOps Framework brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.

            +
            Wiki reference

            FinOps and cost controls

            Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Financial accountability

            The FinOps Framework brings technology usage and value into a collaborative operating practice. Resource automation can support that practice, but a technical controller does not replace decisions about ownership and business priorities.

            A useful distinction is between a spending forecast, an alert, and an enforced limit. A forecast estimates a future outcome. An alert informs someone. An enforced limit constrains an action. Treating them as interchangeable can leave an automated workflow with more spending authority than intended.

            Design the budget boundary

            For a hypothetical inference service, identify who owns the budget, which usage is counted, when usage data becomes available, and what happens at a limit. Decide whether the service queues work, degrades gracefully, requests approval, or stops accepting new tasks.

            A cost cap also has operational consequences. Stopping a critical service to avoid overspending may be an unacceptable policy; that tradeoff needs an accountable decision before the incident.

            @@ -10,4 +10,4 @@

            Evaluate claims carefully

            When someone

            These evaluation questions are editorial guidance. This site does not claim that any particular allocation policy guarantees a financial outcome.

            Related: autoscaling, resource scheduling, and observability.

            Sources and scope

            1. FinOps Foundation: FrameworkCollaborative technology value and cost management.
            2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

            Continue reading

            Explore cost and operational evidence: What did the system consume, and what evidence explains it?

            For the wider context, read what autonomous resource management means.

            Related source briefs

            Dated project developments; these do not independently validate the concepts above.

            View revision history · View article source · Suggest a correction

            - + diff --git a/wiki/human-oversight/index.html b/wiki/human-oversight/index.html index 1b52f76..4a0e983 100644 --- a/wiki/human-oversight/index.html +++ b/wiki/human-oversight/index.html @@ -1,7 +1,7 @@ Human oversight and decision rights | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Human oversight and decision rights

            Defining who can authorize, interrupt, and review automated resource decisions.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Oversight needs an operational meaning

            Human oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.

            +
            Wiki reference

            Human oversight and decision rights

            Defining who can authorize, interrupt, and review automated resource decisions.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Oversight needs an operational meaning

            Human oversight is useful when it identifies a person or role, a decision they can make, and a practical way to intervene. A dashboard alone does not establish that somebody can stop an action or restore an acceptable state.

            The NIST AI Risk Management Framework provides voluntary guidance for managing AI risks. Applying it to a resource-management system requires context; citing it does not demonstrate compliance or certification.

            Define the delegated scope

            As an editorial design checklist, document:

            - + diff --git a/wiki/index.html b/wiki/index.html index 36de7c4..f74d040 100644 --- a/wiki/index.html +++ b/wiki/index.html @@ -2,4 +2,4 @@ Reference library | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            Wiki / 8 articles

            The reference library

            Concepts, practical questions, and boundaries. Start with an overview, then follow the decisions that matter to your system.

            What is autonomous resource management? →
            What does autonomous resource management mean?

            Foundations and scope

            Start with the working definition and distinguish resource decisions from general automation.

            01 / Wiki reference

            What is autonomous resource management?

            A practical introduction to resource decisions, feedback loops, operating limits, and human accountability.

            Definition, context & limitations
            Do I need more capacity, or a different allocation?

            Capacity and workload placement

            Compare scaling with scheduling before investigating workload constraints and capacity limits.

            01 / Wiki reference

            Autoscaling and feedback loops

            How capacity follows demand, and why signals, limits, and recovery matter.

            Definition, context & limitations
            02 / Wiki reference

            Resource scheduling and allocation

            Placement decisions, competing objectives, and the difference between capacity and usable capacity.

            Definition, context & limitations
            What did the system consume, and what evidence explains it?

            Cost and operational evidence

            Connect budgets and cost controls to measurements, observed outcomes, and decision records.

            01 / Wiki reference

            FinOps and cost controls

            Relating resource consumption, budgets, and business outcomes without assuming automatic savings.

            Definition, context & limitations
            Which actions can a workflow take, and who can intervene?

            Orchestration and human oversight

            Follow task coordination into delegated permissions, escalation, and accountable review.

            - + diff --git a/wiki/observability/index.html b/wiki/observability/index.html index c3b7c8f..5408ca4 100644 --- a/wiki/observability/index.html +++ b/wiki/observability/index.html @@ -1,7 +1,7 @@ Observability for resource decisions | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Observability for resource decisions

            Connecting measurements to actions without mistaking telemetry for proof of correctness.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Observe the system and its decisions

            Observability helps operators investigate system behavior from available evidence. OpenTelemetry describes signals such as traces, metrics, and logs, which offer different views of system activity.

            +
            Wiki reference

            Observability for resource decisions

            Connecting measurements to actions without mistaking telemetry for proof of correctness.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Observe the system and its decisions

            Observability helps operators investigate system behavior from available evidence. OpenTelemetry describes signals such as traces, metrics, and logs, which offer different views of system activity.

            For resource management, an operational question is not only “what was the CPU load?” but “which measurement led to this allocation, and what happened afterward?” Connecting the decision to its inputs makes that question easier to investigate.

            A useful decision record

            As editorial guidance, consider recording the resource identifier, observation time, policy version, requested change, and resulting state. Record units and measurement windows too: a point-in-time value and a ten-minute average can support different conclusions.

            Separate an action request from its acknowledgement and eventual outcome. A successful API response is not necessarily evidence that a service met its objective.

            @@ -10,4 +10,4 @@

            Evidence quality

            A signal can be delayed, sampl

            Limits

            Telemetry does not independently prove causation, security, compliance, or optimal allocation. A before-and-after cost chart can be affected by workload changes and pricing changes. Claims about an improvement should identify those conditions and the comparison baseline.

            Use audit trails to preserve decision context and human oversight to define who responds when evidence is insufficient.

            Sources and scope

            1. OpenTelemetry: SignalsTelemetry signals used to describe system activity.

            Continue reading

            Explore cost and operational evidence: What did the system consume, and what evidence explains it?

            For the wider context, read what autonomous resource management means.

            Related source briefs

            Dated project developments; these do not independently validate the concepts above.

            View revision history · View article source · Suggest a correction

            - + diff --git a/wiki/resource-scheduling/index.html b/wiki/resource-scheduling/index.html index 8bebee7..b28cbc0 100644 --- a/wiki/resource-scheduling/index.html +++ b/wiki/resource-scheduling/index.html @@ -1,7 +1,7 @@ Resource scheduling and allocation | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Wiki reference

            Resource scheduling and allocation

            Placement decisions, competing objectives, and the difference between capacity and usable capacity.

            ARM Editorial · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What a scheduler decides

            A scheduler matches work to eligible resources. It has to respect constraints before considering preferences. Kubernetes describes filtering candidate nodes and scoring the feasible ones.

            +
            Wiki reference

            Resource scheduling and allocation

            Placement decisions, competing objectives, and the difference between capacity and usable capacity.

            By ARM Editorial · Maintained by Mason Nguyen · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            What a scheduler decides

            A scheduler matches work to eligible resources. It has to respect constraints before considering preferences. Kubernetes describes filtering candidate nodes and scoring the feasible ones.

            Scheduling is distinct from autoscaling. A placement decision can rearrange work within existing capacity; a scaling decision changes available capacity. They interact, but neither alone guarantees that a workload meets its objective.

            Constraints before preferences

            In a hypothetical accelerator queue, eligibility might depend on memory, device compatibility, and data location. Preferences might favor shorter completion time or lower estimated cost. An inexpensive resource that cannot run the task is not a valid choice.

            Record which constraints are mandatory and which objectives can be traded off. A single “efficiency” score can conceal conflicts between throughput, fairness, latency, and expense.

            @@ -16,4 +16,4 @@

            Questions for an allocation policyLimits and related concepts

            Resource quotas constrain resource consumption within Kubernetes namespaces. A quota should not be confused with a financial budget or a guarantee of physical availability.

            Read autoscaling for capacity adjustments and audit trails for recording decisions. Evaluate allocation policies using declared workload conditions rather than unqualified utilization or savings claims.

            Sources and scope

            1. Kubernetes: SchedulerFiltering and scoring nodes for Pod placement.
            2. Kubernetes: Resource quotasNamespace resource constraints and their scope.

            Continue reading

            Explore capacity and workload placement: Do I need more capacity, or a different allocation?

            For the wider context, read what autonomous resource management means.

            Related source briefs

            Dated project developments; these do not independently validate the concepts above.

            View revision history · View article source · Suggest a correction

            - + From 730d651ee489195c58efd05d1470b49a1cf9f60c Mon Sep 17 00:00:00 2001 From: virtualmase Date: Thu, 15 Oct 2026 16:46:46 -0700 Subject: [PATCH 4/4] Keep revision assistance disclosure outside the profile link --- framework/index.html | 2 +- release.json | 4 ++-- scripts/build.mjs | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/framework/index.html b/framework/index.html index 309c575..66030a1 100644 --- a/framework/index.html +++ b/framework/index.html @@ -1,7 +1,7 @@ The ARM working framework | Autonomous Resource Management
            Autonomous Resource
            ManagementKnowledge · Context · Evidence
            -
            Editorial proposal

            The ARM working framework

            An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

            By Mason Nguyen; revision assisted by AI · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Status and authorship

            This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

            +
            Editorial proposal

            The ARM working framework

            An attributed proposal for organizing decision rights, signals, recovery, escalation, and audit evidence.

            By Mason Nguyen; revision assisted by AI · Updated

            AI-assisted source synthesis; no independent expert review claimed.

            Status and authorship

            This working framework was developed by Mason Nguyen and is maintained here as an editorial proposal. It is not an industry standard, certification scheme, or independently validated assurance model. The reference library covers established concepts separately from this synthesis.

            Earlier versions of the homepage placed this framework at the center of the ARM definition. This revision gives it a dedicated location so readers can distinguish the proposal from the broader subject.

            Five design concerns

            Decision rights

            Identify the principal who grants authority, the permitted actions, and the limits of delegation. The proposal recommends explicit approval for actions outside the delegated scope.

            Observable signals

            Record the measurements and assumptions used in a decision. OpenTelemetry's signal vocabulary is relevant background for instrumentation, not an endorsement of this framework.

            diff --git a/release.json b/release.json index 0fff3b2..fb9db5f 100644 --- a/release.json +++ b/release.json @@ -1,6 +1,6 @@ { "schemaVersion": 1, - "contentDigest": "180d0070424aa1355149c67a1c6030b7de616ed5ecbd6841309b545eb9800ce1", + "contentDigest": "ca06ce7a29f2d96f14849115298c88b15fd7b1e778f8a5914f3319ffe11c0a85", "contentRevision": "2026-10-15", "pages": 22, "files": { @@ -13,7 +13,7 @@ "editorial-policy/index.html": "6fcb95e0d00a30730bfef32d0fa80ba82401852bf3522697f3c9f4faa6d04000", "favicon.svg": "3766c9e6c1326cb25b003f88369e29907a8660883228c13ab470e306ed4df91e", "feed.xml": "979325d4616849c8c5bd7d386e98414fdf7d07bfc8aca49e566d945503d14419", - "framework/index.html": "c546ca99d7f55895deeec76c7d9e952be8824ec963ae189f7b2c02a769228004", + "framework/index.html": "1bb352f7550c2c76ce94ad2533cb65deb3fc0f71bad24befd2c3270e8085208d", "googlef40b1c9053cf9205.html": "a2afae8978371b939c5ac9e680468c14f119e38a6478ee92d867d510e39f54d4", "index.html": "7576d19dd333d3bd3206cb22574ab28150bab90f29cf7879fbc21165351f3fb3", "llms.txt": "3954c4e791dff83fbce9e7d596a7513f886547477605f3b28c66022e53975309", diff --git a/scripts/build.mjs b/scripts/build.mjs index 694184a..b7c4aa3 100644 --- a/scripts/build.mjs +++ b/scripts/build.mjs @@ -44,7 +44,7 @@ add('/','Autonomous resource management: wiki and industry context','Explore sou for(const a of articles){ const {html,headings}=renderMarkdown(a.body); const schema=[{'@type':a.kind==='news'?'NewsArticle':a.kind==='page'?'WebPage':'TechArticle','@id':origin+a.path+'#article',url:origin+a.path,headline:a.title,description:a.description,dateModified:a.updated,...(a.published?{datePublished:a.published}:{}),author:a.author.startsWith('Mason')?{'@id':origin+'/about/#maintainer'}:{'@id':origin+'/#publisher'},publisher:{'@id':origin+'/#publisher'},isPartOf:{'@id':origin+'/#website'},citation:(a.sources||[]).map(s=>({'@type':'CreativeWork',name:s.title,url:s.url}))}]; - const byline=a.author.startsWith('Mason')?`By ${e(a.author)}`:`By ${e(a.author)} · Maintained by Mason Nguyen`; + const byline=a.author.startsWith('Mason')?`By Mason Nguyen${e(a.author.slice("Mason Nguyen".length))}`:`By ${e(a.author)} · Maintained by Mason Nguyen`; const topic=topicFor(a); const parent=a.kind==='wiki'?['/wiki/','Wiki']:a.kind==='news'?['/news/','News']:null; const breadcrumb=``;