Automation and maintenance

Complete recurring maintenance review

Run the whole library with one command:

python scripts/run_certification_maintenance.py --output-dir .maintenance/2026-09-27 --mode monthly

Choose a new output directory each time. The command runs the objective, discovery, and source-health checks sequentially, reducing competing requests to the same vendor. It writes objective candidates into that directory, compares them with accepted snapshots, and creates maintenance-report.json, maintenance-report.md, and objective-candidates.diff. Every published guide receives a row, including retired guides whose objective baselines stay frozen but whose links are checked. No guide, certification status, accepted snapshot, or verification date changes.

The report joins objective differences, exact source URLs needing attention, vendor catalog signals, overdue lifecycle reviews, and dated review tasks from config/certification-maintenance.json. Tasks appear 30 days ahead and remain due after their date until a maintainer resolves or reschedules them with evidence. Dates trigger review, never automatic retirement or a claim that an exam launched. Future blueprints remain distinct from the currently taught exam baseline.

The Review certification maintenance workflow is a manual full sweep in Actions. It checks all configured catalogs and announcement channels, retains reports/logs/candidate snapshots for 90 days, publishes a run summary, and creates or refreshes one Recurring certification maintenance review issue. Its GITHUB_TOKEN needs contents: read and issues: write; no external AI service, API key, or paid enrollment is required. Routine scheduled monitoring uses the smaller objective cohorts and the separate source-health and discovery workflows. An issue permission failure leaves the summary and artifact available and fails visibly.

The objective-cohort, discovery, and source-health workflows remain available. The consolidated workflow provides a complete review task; it does not replace their approved baselines. A maintainer or research agent opens canonical vendor evidence, applies supported guide/catalog/source corrections, runs the shared validation gate, and accepts only the corresponding reviewed baselines. The monthly broader-search checklist and technical/lab review still require actual review work. HTML shells, gated objectives, and PDF extraction limitations are reported explicitly; a successful HTTP response is not objective validation.

To reassemble a collected run without more network requests:

python scripts/run_certification_maintenance.py --reports-dir .maintenance/2026-09-27

Missing/partial source inventories, missing objective results, stale dated reports, missing collection receipts, and unexpected monitor failures fail the assembly. Documented manual-review results remain visible review tasks. Reports preserve the distinction between a matching extraction and a completed technical review. See the September 27 repository review for the first combined evidence ledger, current updates, and remaining limitations.

Subagent refresh workflow

The repository's agent instructions request delegation for substantial refreshes. Start with the deterministic maintenance evidence, then use one coordinator and up to three research subagents within the session's concurrency limit:

Role	Research scope	Required output
Exam researcher	Official objectives, credential identity, eligibility and lifecycle	Opened canonical evidence, dates and current/future scope differences
Technical researcher	Product docs, releases, weak claims and unresolved findings	Confirmed behavior, contradictions, proposed bounded corrections and remaining gaps
Learning-resource researcher	Specific tutorials, workshops, code, courses and videos	Objective fit, catalog matches, access, time basis, strengths and caveats
Coordinator	Evidence reconciliation, shared edits and validation	Accepted changes, preserved limitations, source/health records and accurate review receipts

Research workers do not edit shared files. Assign separate scratch paths and require exact source URLs, observation dates, affected exams and proposed actions. Reuse existing catalog entries; do not count rediscovered URLs as new resources. First-party freshness results and evaluated supplementary learning resources retain their separate authority and workflow boundaries. Keep normal packets around ten guides, at most twelve.

Keep the existing maintenance runner's automated channels sequential. For a targeted vendor pass, use the objective monitor's selected exams or a scoped catalog, discovery --only selectors, and a scoped source catalog; record the selection explicitly. Do not present scoped reports as a complete whole-library run or replace unselected health/snapshot evidence. A generated work packet is pending research, not completion.

After applying changes, give a separate fresh-context agent a read-only review packet: the complete affected guides and current hashes, accepted/candidate objectives, current diff, exact source evidence and the audit rubric. Supply facts and artifacts rather than the editing conversation. The reviewer reports findings and does not repair its own review targets. The coordinator resolves material findings and reruns appropriate checks. A workflow/diff review alone is not a completed full semantic audit.

Record the reviewed scope and remaining work in a dated research report. Preserve historical full-review dates unless the complete review requirements were satisfied. Keep product execution, offline checks, AI review and human review separate. For small corrections, or when delegation is unavailable, proceed with one agent and disclose the actual review method. Publication and delivery follow the user's requested scope.

Example request: “Refresh the Microsoft/Azure guides using an exam researcher, a technical researcher and a learning-resource researcher. Keep shared edits with the coordinator, then use a fresh-context reviewer. Report completed coverage and remaining work.”

Certification discovery inventory

config/certification-seeds.json records the official catalog URL, explicit selection rule, and last verification date for each discovery scope. Repository validation checks its structure, requires every published guide to remain in the inventory, and prevents CERTIFICATIONS.txt from drifting from it.

config/certification-discovery.json separately defines the broader official catalogs to inspect, including credentials outside the selected guide inventory. scripts/check_certification_discovery.py compares their public listings against data/certification-discovery-baseline.json and reports added, missing, and changed observations. It also compares listing URLs and vendor-scoped exam codes with the seed inventory, published guide sources, and partner reference links. Matches indicate a reference, not complete guide coverage; unmatched URLs need identity/alias review.

The discovery workflow is configured for Wednesdays at 13:23 UTC. On the first of each month at 14:23 UTC it also fetches configured announcement/status pages and produces the broader discovery checklist. Both schedules become active when the workflow is on the repository's default branch and Actions is enabled. Reports appear in the run summary and JSON/Markdown artifacts retained 90 days. The workflow requires only read access and does not depend on permission to create PRs.

The monthly checklist still needs a maintainer or research agent to search official announcements, inspect additional catalogs and pagination, verify individual blueprints and eligibility, and classify certificates/badges separately from certifications. A scheduled fetch does not claim that this review has happened. See the September 17 catalog audit for the initial findings and catalog coverage limits.

One certification at a time

Notification pilot reservation — September 28, 2026: hold GH-900, GH-200, GH-100, GH-500 and GH-600 for the five-certificate notification pilot. These are the first five catalog entries without a receipt in the current deep-review program. Continue other guide reviews while preserving urgent corrections and normal source monitoring for the reserved guides. The pilot starts with manual baselines and notification delivery disabled; selection alone does not enable conditional email.

The Microsoft review tracker distinguishes this deep-review program from historical source validation. data/deep-reviews.json stores dated receipts with the reviewed guide hash, objective count, report/evidence paths, lab execution level and unresolved limitations. The schema and repository validator check the records. Changed guide text, a 30-day-old review, or a due event dated after the latest receipt makes a guide eligible for the next batch. Unresolved blockers remain open, but a recent review waits for that next trigger so initial reviews can progress. Events on or before the latest receipt remain visible without scheduling the same review repeatedly; set a later event review date when another check is needed. The queue reports outstanding work separately from eligibility and shows the next eligible review date. Lifecycle events and changing/beta exams affect priority. Retired guides are archived in this queue while ordinary link monitoring continues.

The default Microsoft queue covers both microsoft and microsoft-office: role-based, fundamentals, specialty, and the five published Microsoft 365 Apps MOS guides. The September 27–28 first pass covered the 50 guides in the first vendor group only. GitHub remains a separate vendor and can be selected with --vendor-id github. For MOS, read the detailed linked skills PDF as well as the credential page; the automatic objective adapter currently compares the page's broad domain list. Record the PDF hash and detailed mapping in the research receipt. A course, product, exam version, and earned credential can have different retirement/expiration dates.

Prepare a small work packet without changing content or completion records:

python scripts/prepare_deep_review_queue.py --output-dir .maintenance/next-review --size 3

The recurring maintenance command also writes deep-review/review-queue.json, review-queue.md and next-batch.json. Packets contain official blueprint links, registered sources, queued candidates and the required review steps. The workflow includes progress in its maintenance issue. It does not run an unattended AI editor or mark a certification reviewed after a successful fetch.

For each certification:

1. Read the complete guide and map every detailed objective to substantive teaching. Recheck the official credential, current/future blueprint, prerequisites and lifecycle.
2. Inspect current product documentation, release channels and useful public blog articles. Record author, date, relevance, limitations and primary corroboration; reject exam dumps, search-snippet-only evidence and unsupported compatibility claims.
3. Correct the guide and add original explanations, examples and answer checkpoints where they improve learning. Update affected supporting documentation, source catalog, health evidence, validation record and a dated research report. Keep objective baselines intact unless an actual reviewed blueprint change justifies replacing them. Synchronize its shared resource entry with python scripts/sync_learning_resources.py --exam-code AB-210 --write (replace the example code), and reconcile the README's review status. This copies the guide's resource section with adjusted local links; it does not fetch sources or create a review receipt. --reviewed --write reconciles all currently matching review receipts.
4. Record content review, independent/human review and live lab execution separately. Complete research with unresolved vendor conflicts as reviewed-with-blockers; preserve the guide's stricter review-required/blocked status until the evidence gap is resolved.
5. Add the receipt, run the command above with --publish-status, and run the shared gate: unit tests, repository validation, python scripts/sync_learning_resources.py --reviewed, site preparation, strict MkDocs build and site validation. The resource command checks for drift without writing by default; CI checks it before validation/deployment proceeds. Inspect the diff, stage the certification and its supporting changes, commit, and push. Confirm GitHub validation/deployment before treating publication as complete, then move to the next certification. Record any actual failure and repair it before continuing.

The queue is reproducible prioritization, not exhaustive automatic research. Guide hashes detect text changes; separate objective, discovery and link monitors detect upstream signals. Product changes behind a stable URL still need the scheduled content review. The progress page is a deliberately published snapshot; live workflow artifacts can be newer. Append or prepend a new receipt rather than rewriting historical evidence; put the latest same-day receipt first. A completed AI content review does not satisfy pending human review.

For two source reviews of the same exam on the same day, append the new record with supersedes_review_id pointing to its immediate predecessor. Keep the earlier record's dates, checks, snapshot, verdict and link counts unchanged. Each reference must name a same-day source-validation record for the same exam, with no forks or cycles. Superseded records retain internally checked historical evidence and cannot satisfy today's passed source gate. Audit binding follows the applicable unsuperseded record as of its date; the documented earliest-record legacy fallback remains separate.

GitHub and Microsoft use the public JSON feeds requested by their current catalog websites. These are website interfaces, not guaranteed integration APIs. The Microsoft adapter checks the returned total, unique identities, and next-page marker; a partial response requires manual review. Required-exam references are compared as well as credential names, so a new exam under an existing credential can produce a change. GitHub Applied Skills remain separate from certifications. The follow-up review records browser observations for Cisco, MongoDB, ServiceNow, and IBM. Their scheduled HTML checks still require manual review; browser evidence is not an accepted HTML baseline.

The published-exam validation records a separate check of all 223 published guides. Its evidence ledger is ADLC_Docs/operations/2026-09-17-exam-validation.json. The objective monitor ran against a temporary copy of data/objective-snapshots; accepted snapshots were preserved. Public PDF, complete HTML, and unsigned browser checks recovered 37 sources outside the monitor. These findings do not turn manual HTTP limitations into automated passes or renew historical technical-audit dates.

python scripts/check_certification_discovery.py --mode weekly
python scripts/check_certification_discovery.py --mode monthly

Review the report, then accept selected successful observations explicitly:

python scripts/check_certification_discovery.py --mode monthly --only databricks-catalog --write

The default commands do not modify the baseline. --write preserves failed and unselected sources. Missing markers, empty/undersized extraction, access-denied pages, and a catalog shrinking by more than 40% require manual review and cannot replace a baseline. Network/HTTP errors remain visible and fail the run. A changed source/extraction configuration requires a new baseline; a missing listing is never automatically classified as retired. Listing comparisons do not inspect every linked exam's availability, code, or objective body; use the objective monitor and source-freshness review for that work. Seed last_verified dates are not advanced by discovery runs, and guides are never silently added or rewritten.

Objective monitoring

The objective workflow checks one of four stable cohorts on the 1st, 8th, 15th, and 22nd of each month at 12:17 UTC. Each active exam belongs to exactly one cohort, so the full selected catalog is checked over the month. A manual Actions run can check one cohort or a single exam code. The workflow selects the adapter registered for each exam's provider in data/vendors.json, compares normalized objective and exam-status snapshots with the accepted versions under data/objective-snapshots, and saves a JSON report and candidate diff as run artifacts. When differences are detected, it opens a review issue with one checklist item per affected exam. It does not commit, open a pull request, or update a guide. Review and accept each affected exam separately. New exams keep their cohort assignment stable without reshuffling existing exams.

Some reachable provider pages do not expose their reviewed objective content to a non-browser HTML extractor. Known exact extraction failures are recorded in config/objective-monitor-limitations.json with a review date, reason, and manual freshness route. The monitor still requests those pages. Only an exact documented failure becomes a visible manual-review result; a different network, HTTP, or extraction failure remains an error and fails the workflow. If a provider begins exposing parseable content, normal snapshot comparison resumes automatically. Manual-review guides remain in the recurring docs/SOURCE-FRESHNESS.md process and are not claimed as continuously machine-validated.

All objective and source-health requests pass through a shared outbound URL policy. The policy rejects non-HTTPS schemes, embedded credentials, localhost, non-public literal IP addresses, and non-default HTTPS ports before opening a connection, then validates the final redirect. Objective retrieval additionally restricts redirects to the configured site's host or its www equivalent. Source-health monitoring permits cross-host redirects because detecting canonical moves is part of that workflow, but the final destination must still remain public HTTPS. A rejected destination is evidence for review, not permission to bypass the guard.

The workflow detects:

• A changed skills-version or tested-product baseline
• A newly announced future update or retirement
• The appearance of more than one published skills version
• Added, removed, or renamed objective groups
• Changed percentage weightings when the provider publishes them
• Added, removed, or reworded objective bullets

What it deliberately does not automate

It does not rewrite the explanatory study guides. A changed bullet might require:

• New technical research
• Removal of a retired feature
• Updated labs or screenshots
• A terminology migration
• Changes to security or data-handling guidance
• New VERIFY CURRENT flags

A generated prose rewrite could look convincing while misunderstanding the exam change. The automation therefore produces evidence and a review task.

Source catalog health monitoring

The separate weekly source-health workflow checks every approved entry in data/sources.json. It records a reviewable baseline in data/source-health.json and reports:

• missing pages and request errors;
• redirects and canonical-URL changes;
• changed public page titles;
• changed duration signals found in public HTML or structured metadata;
• catalog entries whose last_checked date is older than the configured threshold; and
• providers that block automated requests.

The monitor does not scrape authenticated content, automatically replace a URL, change a runtime, or update last_checked. A blocked automated request is informational because a legitimate provider may reject non-browser clients. Missing pages and metadata changes open or update a maintenance issue for human review; the complete JSON and Markdown reports remain workflow artifacts for 30 days.

YouTube title, canonical-URL, and duration metadata are not compared because consent, localization, and bot-handling responses vary by runner region. YouTube entries still receive reachability, HTTP-status, and redirect checks; course titles and runtimes remain deliberate catalog-review fields.

After reviewing and accepting intentional source changes, run the monitor locally with --write and commit the refreshed snapshot with the catalog change. Until that review occurs, the monitor may continue reporting the difference.

Use repeated --only SOURCE_ID arguments with --write for a reviewed subset; unselected observations are preserved. Duration-signal ordering is ignored, while changed values still require review. SAML sign-in redirects are reported as blocked access instead of changes to course metadata; signed login parameters are not retained.

Official-source freshness discovery

Health monitoring can inspect only URLs the repository already knows. The separate AI-assisted freshness workflow searches official credential catalogs, product documentation, release notes, roadmaps, retirement notices, and vendor announcements for material that is not registered yet. Its findings are recorded in data/source-freshness.json; unreviewed URLs enter data/source-candidates.json rather than being silently promoted.

For Dynamics 365, Power Platform and Dataverse, include the AI at Work roadmap alongside current product documentation and release notes. Microsoft's August 25 transition announcement says new roadmap disclosure moves there from September 2026, with Release Planner retirement planned by November 15. Older Learn release plans remain historical references. Record product, feature ID, observed status/date and source URL; verify availability and prerequisites in product documentation before changing a guide. A missing roadmap card alone does not prove launch, cancellation or removal. CSV/RSS can aid discovery, but roadmap-feed ingestion is not implemented by this repository's monitor. Keep feature research separate from credential discovery, and use dated maintenance events to revisit rollout claims and support deadlines.

Prepare a recurring risk-ordered batch with:

python3 scripts/prepare_source_freshness_scan.py \
  --batch-id freshness-2026-09-12-01 \
  --size 10 \
  --output .site-build/freshness-2026-09-12-01.json

The default seven-day recurrence matters even when local files are unchanged, because a new external page cannot alter a stored hash. A guide or registered official-source change also creates a new baseline immediately. The agent is read-only; source promotion and guide repair remain separate review steps. See Official-source freshness scans for the rubric and result contract.

Independent AI-audit batches

The batch preparer selects guides that do not have a completed audit for their current objective-snapshot hash and audit-rubric version. Its default risk order puts changing, beta, retiring, scheduled-change, source-health, and visible VERIFY CURRENT evidence first. It emits the complete guide, snapshot, review, and source handoff needed by a fresh-context agent; it does not edit a guide or decide that a finding is fixed.

python3 scripts/prepare_ai_audit_batch.py \
  --batch-id audit-2026-09-04-01 \
  --size 10 \
  --output .site-build/audit-2026-09-04-01.json

Keep normal batches at 10 guides and never exceed 12. Record scrutinized results in data/ai-audits.json; repository validation enforces the snapshot hashes, exact check set, finding dispositions, verdict logic, result coverage, and aggregate summary. The complete rubric and repair separation are in Independent AI guide audits.

First run

The accepted snapshot catalog is already committed. A scheduled run reports differences for its cohort; a manual run can target one exam. Review each candidate diff against the official page before changing its accepted snapshot and guide. A failed extraction does not erase or accept the existing baseline.

Required repository settings

1. Enable GitHub Actions.
2. Ensure the default GITHUB_TOKEN can receive the read and issue permissions declared in the workflows.
3. Allow the source-health and objective workflows to create or refresh their maintenance issues.
4. Protect main with a pull-request requirement and normal review.

The objective-monitor-report artifact retains the objective report and available candidate patch for 30 days. Setup/test failures and source-extraction failures are reported separately. The Action never merges a snapshot or guide change.

No PAT or external API key is required. The workflow uses the repository-scoped GITHUB_TOKEN.

Delivery and dependency policy

The validation and Pages workflows call the same repository-local composite action at .github/actions/validate/action.yml. That action owns Python setup, dependency installation, unit tests, repository validation, the strict site build, and generated-site validation. Change the shared gate once and keep workflow-specific permissions, triggers, artifact upload, and deployment in their owning workflows.

Third-party GitHub Actions must use a full 40-character commit SHA. Retain the release-major comment beside the SHA so review remains readable, and let Dependabot propose both Actions and Python dependency updates. A dependency PR must still pass the shared gate and be reviewed for release notes, compatibility, provenance, and unexpected transitive changes; an automated PR is not approval to merge.

Manual execution

Run Actions → Check certification objectives → Run workflow after:

• A GitHub product announcement
• A Microsoft Learn blueprint update
• A guide revision
• An exam scheduling decision

Local tests

python3 -m unittest discover -s tests -v

The live download may be run locally when the configured official sites are reachable:

python3 scripts/check_official_study_guides.py --write

For a reviewed provider wave, repeat --exam-code to refresh only the selected records before running the full dry-run monitor:

python3 scripts/check_official_study_guides.py --write \
  --exam-code 1Z0-1085-26 --exam-code 1Z0-1072-26

Refresh the approved source-health baseline only after reviewing its findings:

python3 scripts/check_source_health.py \
  --report source-health-report.json \
  --markdown-report source-health-report.md

# Review both reports, then deliberately update the baseline.
python3 scripts/check_source_health.py --write

Automated title and duration detection is a change signal, not proof that the library metadata is wrong. Dynamic pages and regional variants require judgment.

Review checklist for an objective-change PR

When accepting a changed objective snapshot, preserve the text used by historical reviews before replacing it. Store the exact prior bytes under data/objective-snapshots/archive/<exam>-<sha256>.txt. Older audit records may point to that byte-identical archive; keep their hashes, dates, checks, findings and verdicts unchanged. A newly completed guide review can reference the newly accepted snapshot and hash. Retain the original source-validation record under its original ID and date, pointing to the archive; give the new review its own dated ID. Validation binds historical audits to the latest retained source review on or before their audit date. An audit after a replacement review must use that review's baseline. Historical link counts retain their original evidence instead of adopting today's guide links. Legacy gaps without a contemporaneous source review bind to the earliest retained review with the required exact snapshot path and hash; this preserves the ledger without establishing missing contemporaneous evidence. New audits still need a current source review, as described in AI-audit binding rules. Record the before/after hashes, reason for acceptance and any source-path migration in the review evidence. PL-300's September 27 deep-review record demonstrates this for editorial-only changes. Future-dated objectives must still remain distinct from the current exam baseline until their effective date.

• Confirm the extraction is genuine and not page-navigation noise.
• Record the new skills-version, exam version, or tested-product baseline.
• Check whether the page announces a future update or retirement and update the guide status line.
• Update the affected guide’s objective map and any provider-published weights; do not invent weights for unweighted blueprints.
• Add or remove technical coverage.
• Recheck all product names, paths, permissions, and preview status.
• Update labs and readiness checklist.
• Verify links against the relevant provider's official blueprint and product documentation.
• Run tests and inspect Markdown rendering.
• Merge the snapshot and guide changes together when practical.

Optional Copilot-assisted maintenance

An objective-change issue can be assigned to a configured coding agent to prepare a draft guide update. Keep human review mandatory. The agent should receive:

• The changed snapshot diff
• The affected guide path
• A requirement to use official sources
• A prohibition on invented product behavior or exam questions
• Instructions to retain VERIFY CURRENT labels
• Required Markdown and link validation