+
+## Learning outcomes
+
+By the end of this module, you can:
+
+- Differentiate procedural control flow from declarative rule evaluation.
+- Explain rules, facts, working memory, production memory, activations and agenda.
+- Create and execute a minimal rule project.
+- Recognize suitable and unsuitable rule-engine use cases.
+
+## Why a rule engine?
+
+A rule engine externalizes decision logic that would otherwise become scattered conditional code. The value is not simply “fewer `if` statements”; it is the ability to represent changing policy in a form that can be reviewed, tested, versioned and evaluated against facts.
+
+A strong use case has explicit decision policy, frequent rule change, many interacting conditions, a need for explanation or business/technical collaboration, or a requirement to apply the same policy consistently across channels. A weak use case is a trivial deterministic transformation with no policy volatility.
+
+## Core engine model
+
+Drools evaluates **facts** against **rules**. Rules are stored in production memory. Facts are inserted into working memory. Matching conditions create activations coordinated through the agenda. A consequence can change state or derive new facts, potentially creating more matches.
+
+Think: *declare what conditions make a rule applicable, then let the engine determine matches and execution according to runtime semantics.*
+
+## First DRL
+
+```text
+package academy.pricing
+
+rule "Flag high value order"
+when
+ $o : Order(total >= 10000)
+then
+ $o.setReviewRequired(true);
+end
+```
+
+The left-hand side describes the pattern; the right-hand side describes the consequence. `$o` binds the matched fact.
+
+## Design discipline
+
+Use intent-revealing rule names. Keep conditions side-effect free and consequences small. Keep external I/O out of rule consequences; use application/service boundaries for network calls and durable side effects.
+
+## Scenario
+
+The course reuses the legacy repository's insurance theme with synthetic data. You will progressively automate eligibility, risk classification, premium adjustments and event-driven fraud indicators without processing real health or financial records.
+
+## Knowledge check
+
+1. Why is “many `if` statements” not by itself a sufficient reason to introduce Drools?
+2. What changes in working memory can cause new activations?
+3. Why should external REST calls normally not occur inside a rule consequence?
+4. Describe one decision that benefits from traceable policy rules.
+
+**Mastery target:** 4/4 with explanations in your own words.
diff --git a/course-site/docs/modules/02-drl.md b/course-site/docs/modules/02-drl.md
new file mode 100644
index 0000000..df09ef4
--- /dev/null
+++ b/course-site/docs/modules/02-drl.md
@@ -0,0 +1,74 @@
+---
+title: Module 2 — DRL Rule Authoring
+description: Self-paced Drools course module 2 with concepts, examples, checks and practice guidance.
+sidebar_position: 2
+---
+
+# Module 2 — DRL Rule Authoring
+
+
+
+## Learning outcomes
+
+- Write readable DRL patterns, constraints and bindings.
+- Use collections, logical composition and rule attributes deliberately.
+- Separate domain intent from technical side effects.
+- Review rule sets for ambiguity, overlap and maintainability.
+
+## Rule anatomy
+
+```text
+rule "Adult applicant with standard risk"
+when
+ $a : Applicant(age >= 18, riskScore < 60)
+then
+ $a.setBand("STANDARD");
+end
+```
+
+Constraints narrow matches. Bindings make matched objects available to later patterns or consequences.
+
+## Constraint composition
+
+Use explicit conditions a reviewer can reason about. If a rule represents regulatory/commercial policy, include a traceable policy identifier in metadata or comments. Consider overlap: two valid rules may match the same fact and create contradictory outcomes.
+
+## `exists`, `not`, collections and joins
+
+```text
+rule "Require manual review for applicant with open alert"
+when
+ $a : Applicant($id : id)
+ exists Alert(applicantId == $id, status == "OPEN")
+then
+ $a.setManualReview(true);
+end
+```
+
+When joining fact types, constrain relationships. Broad patterns can create cross-products and performance problems.
+
+## Consequence hygiene
+
+Prefer consequences that update domain state or emit a decision result. Do not hide database access, HTTP calls, credential use or retry loops in consequences.
+
+## Rule attributes
+
+Salience and agenda grouping can control execution, but they should not substitute for a clear model. A web of numeric priorities is difficult to maintain. Where ordering is essential, document why and test it.
+
+## Language level
+
+Drools 10 includes newer language capabilities. Record the chosen language level and avoid mixing examples from incompatible documentation versions.
+
+## Knowledge check
+
+1. What problem can an unconstrained join create?
+2. How does `exists` differ from binding every matching fact?
+3. Why can extensive salience values become a maintenance smell?
+4. How would you move an HTTP side effect outside a consequence?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/03-kie-runtime.md b/course-site/docs/modules/03-kie-runtime.md
new file mode 100644
index 0000000..d5f35c3
--- /dev/null
+++ b/course-site/docs/modules/03-kie-runtime.md
@@ -0,0 +1,58 @@
+---
+title: Module 3 — KIE Runtime and Sessions
+description: Self-paced Drools course module 3 covering KIE runtime, stateful/stateless sessions and Rule Units.
+sidebar_position: 3
+---
+
+# Module 3 — KIE Runtime and Sessions
+
+
+
+## Learning outcomes
+
+- Explain KIE base/container/session responsibilities.
+- Choose stateless versus stateful execution from requirements.
+- Describe lifecycle obligations of a stateful session.
+- Compare traditional KIE session and Rule Unit-oriented designs.
+
+## Runtime layers
+
+A KIE base represents compiled knowledge. A KIE session is the runtime context that accepts data and executes rules. Applications may work through KIE containers/sessions or newer Rule Unit-oriented APIs. The decision is based on runtime state and isolation, not API brevity.
+
+## Stateless sessions
+
+A stateless session fits validation, calculation, routing and filtering when requests are independent and no prior invocation state is required.
+
+## Stateful sessions
+
+A stateful session retains facts and supports iterative inference/event scenarios. Define session ownership, concurrency boundaries, fact update/retraction, disposal, memory bounds and recovery/persistence behaviour.
+
+## Rule Units
+
+Drools 10 supports Rule Unit style; official getting-started guidance recommends it for microservice/cloud-native-oriented applications. Treat it as an architectural option, not a mandatory rewrite of every KIE session application.
+
+## Selection exercise
+
+Choose and justify an execution model for:
+
+- one independent insurance quote;
+- transaction events correlated over a rolling period;
+- a batch of independent validations;
+- an evolving eligibility case with inserted/retracted evidence.
+
+Your justification must mention state lifetime, concurrency, explainability and recovery.
+
+## Knowledge check
+
+1. Why is a long-lived stateful session an operational resource?
+2. What does stateless execution simplify?
+3. What evidence would justify a stateful design?
+4. When might Rule Units be preferable?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/04-inference.md b/course-site/docs/modules/04-inference.md
new file mode 100644
index 0000000..5ddc93b
--- /dev/null
+++ b/course-site/docs/modules/04-inference.md
@@ -0,0 +1,63 @@
+---
+title: Module 4 — Inference, Truth Maintenance and Execution Control
+description: Self-paced Drools module on forward chaining, truth maintenance, agenda behaviour and loop prevention.
+sidebar_position: 4
+---
+
+# Module 4 — Inference, Truth Maintenance and Execution Control
+
+
+
+## Learning outcomes
+
+- Explain forward chaining and inference.
+- Use logical insertion/truth maintenance conceptually and safely.
+- Analyse agenda/conflict behaviour rather than assuming source order.
+- Design tests that prove rule interaction.
+
+## Forward chaining
+
+A matched rule can change state, satisfy another rule and continue until no relevant activations remain or execution is controlled. This is inference. Test the rule set as a system, not only rule-by-rule.
+
+## Truth maintenance
+
+Truth maintenance links logically derived facts to the evidence supporting them. When support disappears, derived conclusions can be retracted. Use this only where derivation semantics are explicit.
+
+## Conflict and agenda reasoning
+
+Multiple rules can be eligible simultaneously. Do not assume visual file order is business ordering. Model and test essential control explicitly.
+
+## Avoiding loops
+
+A rule update can reactivate itself. Design stable transitions and state guards:
+
+```text
+rule "Classify unprocessed applicant"
+when
+ $a : Applicant(classification == null, riskScore >= 80)
+then
+ $a.setClassification("HIGH");
+ update($a);
+end
+```
+
+The null guard helps make the transition one-way.
+
+## Interaction tests
+
+Cover single-rule firing, cooperative multiple rules, conflict, evidence removal, repeated evaluation and termination/no-loop behaviour.
+
+## Knowledge check
+
+1. What is inference?
+2. Why is source-file order a poor business control?
+3. What problem does truth maintenance solve?
+4. How can a state guard prevent a loop?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/05-decision-models.md b/course-site/docs/modules/05-decision-models.md
new file mode 100644
index 0000000..ef253a8
--- /dev/null
+++ b/course-site/docs/modules/05-decision-models.md
@@ -0,0 +1,53 @@
+---
+title: Module 5 — Decision Tables and DMN
+description: Self-paced module on choosing DRL, decision tables or DMN and validating decision boundaries.
+sidebar_position: 5
+---
+
+# Module 5 — Decision Tables and DMN
+
+
+
+## Learning outcomes
+
+- Select DRL, decision tables or DMN based on decision structure and audience.
+- Explain DMN decision requirements and FEEL expressions at a practical level.
+- Create tabular logic with coverage/overlap review.
+- Test decision models with representative boundaries.
+
+## Choose a representation deliberately
+
+- **DRL** fits expressive rule interactions and fact-centric reasoning.
+- **Decision tables** fit repetitive condition/action matrices reviewers naturally understand as policy tables.
+- **DMN** fits explicit decision requirements, business-readable decision logic and portable decision-service models.
+
+The best representation makes policy easiest to understand, validate, test and change without losing technical control.
+
+## Decision tables
+
+Define input columns, output/action columns, hit expectations and boundaries. Review uncovered combinations, overlap, defaults and null/missing-input behaviour.
+
+## DMN
+
+DMN is an OMG standard for operational decision modeling. A model can show input data, decisions and dependencies, with logic expressed using FEEL or decision tables.
+
+Example chain: `Applicant data → Eligibility → Risk Band → Premium Adjustment → Decision`.
+
+## Boundary testing
+
+For an age threshold of 18, test 17, 18 and 19. For a band ending at 79, test 78, 79 and 80. Boundary tests reveal specification defects efficiently.
+
+## Knowledge check
+
+1. When is a decision table preferable to DRL?
+2. What does a DMN decision-requirements view communicate?
+3. Why are boundary tests essential?
+4. What is the risk of hiding policy in Java helpers?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/06-cep.md b/course-site/docs/modules/06-cep.md
new file mode 100644
index 0000000..fef9af1
--- /dev/null
+++ b/course-site/docs/modules/06-cep.md
@@ -0,0 +1,49 @@
+---
+title: Module 6 — Complex Event Processing
+description: Self-paced Drools module on events, stream reasoning, temporal constraints and bounded state.
+sidebar_position: 6
+---
+
+# Module 6 — Complex Event Processing
+
+
+
+## Learning outcomes
+
+- Distinguish state facts from occurrence events.
+- Explain stream-oriented processing and temporal reasoning.
+- Use windows/temporal constraints to express bounded event patterns.
+- Identify operational risks in long-lived event sessions.
+
+## Facts versus events
+
+A fact often represents current state; an event represents something that occurred at a point/interval in time. CEP is valuable when a decision depends on what happened, when, and in what sequence/frequency.
+
+## Stream reasoning
+
+Temporal operators and windows allow bounded reasoning rather than retaining every event forever.
+
+Example intent: flag an account when at least three high-value transactions occur within ten minutes and it is not already under review. Define timestamp source, threshold, bounded window, duplicate/replay behaviour and stable action semantics.
+
+## Time semantics
+
+Specify ingestion time vs event time vs test clock. Production systems must account for late, duplicate and out-of-order events. Tests should control time rather than sleep.
+
+## Memory and lifecycle
+
+Long-running sessions can accumulate state. Use expiration/window semantics and monitoring. A correct rule set that grows without bound is unsafe.
+
+## Knowledge check
+
+1. Why is a time window both business and resource-management policy?
+2. What happens when duplicate events replay?
+3. Why should tests control time?
+4. How does CEP state differ operationally from a stateless quote decision?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/07-quality.md b/course-site/docs/modules/07-quality.md
new file mode 100644
index 0000000..3f711fe
--- /dev/null
+++ b/course-site/docs/modules/07-quality.md
@@ -0,0 +1,58 @@
+---
+title: Module 7 — Testing, Performance and Troubleshooting
+description: Self-paced Drools module on automated verification, diagnostics, performance risks and root-cause analysis.
+sidebar_position: 7
+---
+
+# Module 7 — Testing, Performance and Troubleshooting
+
+
+
+## Learning outcomes
+
+- Build positive, negative, boundary and interaction tests.
+- Use logs/listeners/diagnostics without business side effects.
+- Identify broad joins, unbounded state and activation churn.
+- Use a systematic defect-isolation workflow.
+
+## Rule quality is executable evidence
+
+Compilation proves syntax/packaging, not business correctness. Build tests for positive, negative, boundary, null/missing, interaction, repeated evaluation and regression cases.
+
+## Testing levels
+
+Use fast rule-level tests, integration tests for packaging/configuration, and a small number of critical end-to-end tests. Every production policy defect should become a regression test.
+
+## Diagnostics
+
+Use runtime event listeners/logging to understand activations while keeping diagnostic code simple and side-effect free.
+
+## Performance
+
+Watch for broad cross-products, expensive constraints, unnecessary updates, activation churn, unbounded sessions and excessive hot-path logging. Measure with representative data before optimizing.
+
+## Defect isolation
+
+1. Capture input and expected decision.
+2. Pin versions.
+3. Reduce to the smallest failing test.
+4. Inspect matches/activations.
+5. Verify fact lifecycle.
+6. Check control mechanisms.
+7. Fix the responsible policy/implementation.
+8. Add regression evidence.
+
+## Knowledge check
+
+1. What does a compilation test fail to prove?
+2. Why use representative facts for performance testing?
+3. Why can unnecessary `update()` calls be expensive?
+4. What is the value of one smallest failing test?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/modules/08-operations.md b/course-site/docs/modules/08-operations.md
new file mode 100644
index 0000000..cbba706
--- /dev/null
+++ b/course-site/docs/modules/08-operations.md
@@ -0,0 +1,51 @@
+---
+title: Module 8 — Integration, Security and Operations
+description: Self-paced Drools module on service boundaries, version traceability, security, observability and rollout controls.
+sidebar_position: 8
+---
+
+# Module 8 — Integration, Security and Operations
+
+
+
+## Learning outcomes
+
+- Place Drools behind a clear application/service boundary.
+- Version decision assets and expose trace metadata.
+- Apply secure development and data minimization.
+- Design observability and safe rollout controls.
+
+## Integration boundary
+
+A service boundary should validate/normalize input, map transport models to domain facts, invoke the decision runtime, capture outcome/version metadata, perform approved external side effects outside rules, and return a stable contract.
+
+## Versioning and explainability
+
+Record application release, rule/model version or commit, timestamp, correlation identifier and non-sensitive reason/outcome codes. Do not dump secrets or unnecessary personal data for traceability.
+
+## Security
+
+Authenticate/authorize callers, validate input, minimize data, protect data in transit/at rest, keep credentials outside source, restrict rule/model changes, review dependencies, separate environments and preserve an auditable change trail. “Business editable” rules still require governance.
+
+## Deployment and rollback
+
+Use immutable versioned artifacts. Promote tested versions through environments and define rollback before rollout. For high-impact changes, use canary/shadow comparison when architecture permits.
+
+## Observability
+
+Measure decision count/latency, errors/timeouts, rule/model version distribution, unexpected defaults/no-decisions, domain outcome shifts and state/session resource indicators where relevant.
+
+## Knowledge check
+
+1. Why avoid network side effects inside rules?
+2. Which metadata supports traceability without full input logging?
+3. Why do rule assets require change control?
+4. What is the value of shadow/canary comparison?
+
+**Mastery target:** 80%.
diff --git a/course-site/docs/quality/accessibility.md b/course-site/docs/quality/accessibility.md
new file mode 100644
index 0000000..0c3b93e
--- /dev/null
+++ b/course-site/docs/quality/accessibility.md
@@ -0,0 +1,48 @@
+---
+title: Accessibility and Inclusive Publishing
+description: WCAG 2.2 AA authoring and QA requirements for the course.
+sidebar_position: 2
+---
+
+# Accessibility and Inclusive Publishing
+
+## Target
+
+Learner-facing web content targets **WCAG 2.2 Level AA**.
+
+## Authoring requirements
+
+- Use headings in logical hierarchy.
+- Give links meaningful text; avoid repeated “click here”.
+- Provide text alternatives for informative images.
+- Do not encode meaning by colour alone.
+- Ensure tables have understandable headers and avoid layout tables.
+- Provide captions/transcripts for instructional audio/video.
+- Keep code examples available as selectable text.
+- Explain diagrams in surrounding prose.
+- Avoid timed interactions for ordinary learning content.
+- Use plain language without removing necessary terminology.
+- Expand acronyms at first use.
+
+## Interaction requirements
+
+- All site navigation/controls must be operable by keyboard.
+- Focus must remain visible and not be obscured.
+- Custom touch/click targets should satisfy WCAG 2.2 target-size expectations.
+- Host-platform authentication should follow accessible-authentication criteria.
+- Error messages must identify the error and recovery guidance.
+
+## QA procedure before release
+
+1. Build the production site.
+2. Navigate every route keyboard-only.
+3. Test responsive layouts at 320 px and common desktop widths.
+4. Run automated accessibility scanning on representative page types.
+5. Manually inspect headings, landmarks, link purpose, code and table semantics.
+6. Verify captions/transcripts for media.
+7. Check contrast for authored/custom styles.
+8. Test zoom/reflow at 200–400% as applicable.
+9. Record defects and corrective commits.
+10. Retain the accessibility review with release evidence.
+
+Automated scanning is necessary but not sufficient; manual testing remains required.
diff --git a/course-site/docs/quality/publishing-checklist.md b/course-site/docs/quality/publishing-checklist.md
new file mode 100644
index 0000000..9d10a6b
--- /dev/null
+++ b/course-site/docs/quality/publishing-checklist.md
@@ -0,0 +1,64 @@
+---
+title: Publishing Checklist
+description: Release gate for technical, instructional, accessibility and governance quality.
+sidebar_position: 3
+---
+
+# Publishing Checklist
+
+A release owner must complete this checklist for each public course version.
+
+## Technical
+
+- [ ] Drools baseline/version verified against current Apache KIE documentation.
+- [ ] All lab projects execute from a clean environment.
+- [ ] Docusaurus production build passes.
+- [ ] Content validation script passes.
+- [ ] Internal Markdown links and routes pass.
+- [ ] No secrets or credentials are present.
+- [ ] Dependency changes reviewed.
+
+## Instructional design
+
+- [ ] Outcomes use measurable performance verbs.
+- [ ] Every course outcome has learning activity and assessment evidence.
+- [ ] Labs contain goal, tasks, evidence and acceptance criteria.
+- [ ] Final assessment blueprint matches stated outcomes.
+- [ ] Capstone rubric is calibrated by a second reviewer.
+- [ ] Estimated effort is checked against pilot learner evidence.
+
+## Content
+
+- [ ] Technical SME approves examples.
+- [ ] Terminology is consistent.
+- [ ] Deprecated Drools patterns are identified or removed.
+- [ ] References are current.
+- [ ] Legacy PDF content is not the sole source of required learning.
+
+## Accessibility
+
+- [ ] WCAG 2.2 AA review completed for representative pages and custom interactions.
+- [ ] Keyboard navigation verified.
+- [ ] Images/diagrams have alternatives.
+- [ ] Media has captions/transcripts.
+- [ ] Contrast/reflow/zoom checks completed.
+- [ ] Accessibility defects are closed or accepted with remediation plan.
+
+## Governance
+
+- [ ] Course owner identified.
+- [ ] Version/release date recorded.
+- [ ] Next review date recorded.
+- [ ] Changes summarized in `CHANGELOG.md`.
+- [ ] Controlled assessment keys are not published in learner docs.
+- [ ] Learner support/feedback channels are configured.
+- [ ] Completion/certificate rules are configured in the host learning platform.
+- [ ] Release approval recorded.
+
+## Post-release
+
+- [ ] Monitor learner completion and assessment difficulty.
+- [ ] Review accessibility/support incidents.
+- [ ] Review broken/external links.
+- [ ] Analyse evaluation feedback.
+- [ ] Open corrective actions for material defects.
diff --git a/course-site/docs/quality/standards-alignment.md b/course-site/docs/quality/standards-alignment.md
new file mode 100644
index 0000000..7044564
--- /dev/null
+++ b/course-site/docs/quality/standards-alignment.md
@@ -0,0 +1,60 @@
+---
+title: Standards Alignment
+description: Evidence-oriented mapping from the course design to current education, e-learning and learning-service quality standards.
+sidebar_position: 1
+---
+
+# Standards Alignment
+
+This page is a **design and evidence map**, not a certification statement. Exact ISO conformity must be assessed against legitimately obtained standard text and the organization's wider management system.
+
+## Current standards baseline
+
+### ISO 21001:2025
+
+The current Educational Organizations Management Systems standard. Course evidence supports learner-centred competence development through defined outcomes, inclusive delivery expectations, assessment, feedback, traceability, review and continual improvement.
+
+**Evidence:** Start Here, Learner Guide, Course Map, assessment blueprint, capstone rubric, accessibility page, publishing checklist and governance files.
+
+### ISO 29993:2017
+
+Addresses learning services outside formal education, including technology-mediated learning, with emphasis on defined learning goals and evaluation.
+
+**Evidence:** target audience/prerequisites, measurable outcomes, service/course information, structured activities, assessment and learner evaluation requirements.
+
+### ISO/IEC 40180:2017
+
+Provides a quality reference framework for ICT-enhanced learning.
+
+**Evidence:** design process, learning-resource structure, technology/publishing controls, quality review, accessibility, learner support and improvement evidence.
+
+### ISO/PAS 25171:2026
+
+Provides audit guidance for ISO 21001:2025 using questions, evidence and measures.
+
+**Evidence:** repository version history, review records, evidence register, release checklist and measurable completion/evaluation criteria.
+
+### WCAG 2.2 AA
+
+The current web accessibility target adopted for authored course pages.
+
+**Evidence:** text-first material, keyboard/focus requirements, semantic Markdown, accessible alternatives, contrast/responsive CSS and accessibility QA checklist.
+
+## Design control matrix
+
+| Quality concern | Implemented control | Evidence location |
+|---|---|---|
+| Defined competence | Measurable course/module outcomes | Start Here + modules |
+| Learner information | scope, effort, prerequisites, completion rules | Start Here + Learner Guide |
+| Constructive alignment | outcome-to-evidence map | Course Map |
+| Practical competence | eight labs + capstone | Labs + Capstone |
+| Assessment validity | blueprint, pass standards, rubric | Assessment + private assessor guide |
+| Accessibility | WCAG 2.2 AA target + QA procedure | Accessibility |
+| Version control | Git + course/release metadata | repository + changelog |
+| Continual improvement | review cadence + evaluation + corrective actions | governance |
+| Publishing integrity | build/content/link/accessibility gates | workflow + checklist |
+| Confidentiality/integrity | answer keys outside public docs; synthetic lab data | instructor notes + learner guide |
+
+## Required organizational evidence not supplied by code
+
+An ISO audit may also require organization-level evidence such as leadership commitments, documented processes, responsibilities, personnel competence, complaints handling, supplier controls, management review, internal audits and corrective-action records. Those are outside the scope of a single course repository.
diff --git a/course-site/docs/resources/cheat-sheet.md b/course-site/docs/resources/cheat-sheet.md
new file mode 100644
index 0000000..e1019e2
--- /dev/null
+++ b/course-site/docs/resources/cheat-sheet.md
@@ -0,0 +1,62 @@
+---
+title: Drools Cheat Sheet
+description: Compact reference for course labs and troubleshooting.
+sidebar_position: 2
+---
+
+# Drools Cheat Sheet
+
+## DRL pattern
+
+```text
+package academy.example
+
+rule "Intent-revealing business rule"
+when
+ $fact : DomainFact(field >= 10)
+then
+ $fact.setOutcome("VALUE");
+ update($fact);
+end
+```
+
+## Condition reminders
+
+- Bind a fact: `$a : Applicant(...)`
+- Relate facts using a shared key.
+- Use `exists` when only existence matters.
+- Use `not` when absence is the condition.
+- Guard state transitions to avoid loops.
+- Treat broad joins as a performance warning.
+
+## Test checklist
+
+- positive match
+- negative/no-match
+- lower boundary
+- exact boundary
+- upper boundary
+- null/missing input
+- multi-rule interaction
+- repeat/idempotency
+- regression case
+
+## Reproduction commands
+
+```bash
+java -version
+mvn -version
+mvn -q test
+mvn dependency:tree
+git status
+git rev-parse HEAD
+```
+
+## Review questions
+
+- What business statement does this rule represent?
+- Could two rules write contradictory outcomes?
+- Does the consequence contain hidden I/O?
+- What causes this rule to stop matching?
+- Which test proves the boundary?
+- Which artifact/version produced the decision?
diff --git a/course-site/docs/resources/glossary.md b/course-site/docs/resources/glossary.md
new file mode 100644
index 0000000..5291440
--- /dev/null
+++ b/course-site/docs/resources/glossary.md
@@ -0,0 +1,26 @@
+---
+title: Glossary
+description: Key Drools, decision automation and course quality terminology.
+sidebar_position: 1
+---
+
+# Glossary
+
+**Activation** — a rule instance eligible for execution because its conditions matched.
+**Agenda** — runtime mechanism coordinating eligible rule executions.
+**CEP** — Complex Event Processing; reasoning about event patterns, timing and sequences.
+**Decision table** — tabular representation of conditions and outcomes/actions.
+**DMN** — Decision Model and Notation, an OMG standard for operational decision modeling.
+**DRL** — Drools Rule Language.
+**Fact** — data made available to the rule engine for matching/evaluation.
+**FEEL** — Friendly Enough Expression Language used in DMN.
+**Inference** — deriving new conclusions/state through rule interactions.
+**KIE base** — compiled knowledge repository used to create runtime sessions.
+**KIE session** — runtime context for inserting data and executing rules.
+**Production memory** — conceptual storage of rule definitions in the engine.
+**Rule Unit** — model for grouping rule data and execution, useful in modern/cloud-native patterns.
+**Salience** — rule priority control; use sparingly and test explicitly.
+**Stateful session** — session retaining runtime state across interactions.
+**Stateless session** — execution model that does not retain prior invocation state.
+**Truth maintenance** — management of logically derived facts relative to supporting evidence.
+**WCAG** — Web Content Accessibility Guidelines.
diff --git a/course-site/docs/resources/references.md b/course-site/docs/resources/references.md
new file mode 100644
index 0000000..ffff8cc
--- /dev/null
+++ b/course-site/docs/resources/references.md
@@ -0,0 +1,24 @@
+---
+title: References
+description: Primary technical, accessibility and quality references for course maintenance.
+sidebar_position: 5
+---
+
+# References
+
+## Technical
+
+- Apache KIE / Drools 10.2 documentation: `https://kie.apache.org/docs/10.2.x/`
+- Apache KIE downloads/current release information: `https://kie.apache.org/docs/start/download/`
+- Docusaurus documentation: `https://docusaurus.io/docs/`
+- DMN specification/resources: Object Management Group (OMG), `https://www.omg.org/dmn/`
+
+## Quality and accessibility
+
+- ISO 21001:2025 — Educational organizations — Management systems for educational organizations — Requirements with guidance for use.
+- ISO 29993:2017 — Learning services outside formal education — Service requirements.
+- ISO/IEC 40180:2017 — Information technology — Quality for learning, education and training — Fundamentals and reference framework.
+- ISO/PAS 25171:2026 — Educational organizations — Management systems — Guidance for auditing ISO 21001.
+- W3C Web Content Accessibility Guidelines (WCAG) 2.2.
+
+The repository records alignment intent and evidence locations. It does not reproduce copyrighted ISO standards and does not assert certification.
diff --git a/course-site/docs/resources/student-notes.md b/course-site/docs/resources/student-notes.md
new file mode 100644
index 0000000..8468dcf
--- /dev/null
+++ b/course-site/docs/resources/student-notes.md
@@ -0,0 +1,52 @@
+---
+title: Student Notes Template
+description: Structured learner-note format for reflection, evidence and spaced retrieval.
+sidebar_position: 4
+---
+
+# Student Notes Template
+
+Copy this structure into your private learning journal for each module.
+
+## Module
+
+**Date:**
+**Course version:**
+**Commit/lab SHA:**
+
+### Three ideas I can explain without notes
+
+1.
+2.
+3.
+
+### One misconception I corrected
+
+-
+
+### One example I can reproduce
+
+```text
+# Write the smallest useful example here.
+```
+
+### Evidence generated
+
+- tests:
+- lab files:
+- screenshots/logs if required:
+- decision/architecture note:
+
+### Questions or uncertainties
+
+-
+
+### Retrieval prompts for later
+
+1.
+2.
+3.
+
+### Production transfer
+
+What would need stronger security, scalability, observability or governance before I used this pattern in a real system?
diff --git a/course-site/docs/resources/troubleshooting.md b/course-site/docs/resources/troubleshooting.md
new file mode 100644
index 0000000..c6fe797
--- /dev/null
+++ b/course-site/docs/resources/troubleshooting.md
@@ -0,0 +1,56 @@
+---
+title: Troubleshooting Guide
+description: Structured root-cause workflow for Drools lab and runtime failures.
+sidebar_position: 3
+---
+
+# Troubleshooting Guide
+
+## Build failure
+
+Capture `java -version`, `mvn -version`, the full Maven error and `mvn dependency:tree`. Confirm the project uses the intended Drools release family and that the IDE is not silently running a different JDK.
+
+## Rule compiles but does not fire
+
+Check:
+
+1. Is the expected fact inserted?
+2. Does its runtime type match the pattern?
+3. Do all constraints evaluate as expected?
+4. Is a field null or differently normalized?
+5. Is the rule in the expected KIE base/session?
+6. Is an agenda/rule attribute suppressing execution?
+7. Does the test actually execute/fire rules?
+
+Reduce to one fact and one rule.
+
+## Rule fires repeatedly
+
+Look for a consequence updating a fact without moving it out of the condition. Add a stable transition/guard and test termination.
+
+## Unexpected multiple matches
+
+Search for overlapping rules and unconstrained joins. Record all matched rule names for the smallest reproducible input.
+
+## Decision model boundary defect
+
+Write three tests around the threshold: below, equal and above. Verify hit/overlap semantics and missing-input handling.
+
+## CEP test is flaky
+
+Replace real waiting with a controllable clock/test time source. Make event timestamps explicit and define ordering/replay/duplicate assumptions.
+
+## Production-style incident worksheet
+
+- correlation ID:
+- application version:
+- rule/model version:
+- sanitized input class:
+- expected outcome:
+- actual outcome:
+- first known bad version:
+- reproducible test:
+- root cause:
+- corrective change:
+- regression test:
+- rollback/forward-fix decision:
diff --git a/course-site/docs/start-here.md b/course-site/docs/start-here.md
new file mode 100644
index 0000000..2e01124
--- /dev/null
+++ b/course-site/docs/start-here.md
@@ -0,0 +1,63 @@
+---
+title: Start Here
+description: Orientation, scope, completion requirements and learning contract for the Drools self-paced course.
+sidebar_position: 1
+---
+
+# Drools Decision Automation — Self-Paced
+
+