Implement Governance Layer for Education-Based Runtime

Governance, Trust, and Enforcement Layer for an Educational Runtime (Win32) Overview This project extends an existing educational, operating-system–inspired runtime, implemented in user space on Windows (Win32). The runtime already provides deterministic scheduling, cooperative execution, quota-based control, an internal message bus, and a plugin mechanism, all demonstrated through a runnable console-based harness. The goal of this phase is to add a governance, trust, and enforcement layer that makes execution decisions intentional, observable, and explainable, with a strong emphasis on clear, walk-through-friendly demonstrations. This work focuses on how decisions are made, explained, and enforced, not on performance optimization or infrastructure scale. Objective The objective is to implement a policy-driven control layer that governs: when tasks are allowed to execute how plugins participate in the runtime how messages are permitted to flow how quotas and credits are consumed and adjusted All decisions must be: deterministic explicitly logged explainable in simple, human-readable terms The resulting system should clearly demonstrate cause → decision → consequence during execution. Scope of Work 1. Governance & Policy Layer You will design and implement a governance layer that: intercepts key runtime decisions, including: task execution eligibility plugin activation and participation message send / receive requests quota or credit usage evaluates decisions using explicit, rule-based logic produces structured, readable output describing: what was requested which rule applied what decision was made Configuration-Driven Behavior (Important) Governance behavior must be externally configurable so that decision logic can be adjusted and re-demonstrated without rebuilding the executable. The configuration mechanism should: be loaded at runtime allow changing thresholds, limits, or rule parameters support re-running the same binary to observe different outcomes Configuration should be organized in a small, well-defined set of files, each with a clear purpose (for example, policy rules, trust/enforcement parameters, or demo scenario selection). Exact file names and internal structure may be designed as appropriate, provided their intent remains clear and stable. 2. Trust & Enforcement Logic You will extend governance with enforcement behavior that reflects ongoing trust and usage patterns, such as: tracking basic trust or reputation indicators per task or plugin dynamically adjusting credits, quotas, or execution eligibility applying enforcement actions including: execution throttling temporary suspension restricted operation modes Enforcement actions must be: deterministic visible in runtime output clearly tied to specific rule evaluations 3. Demonstration of Misbehaving Components The implementation must include one or more intentionally misbehaving components (tasks or plugins) used solely for demonstration. These components should: operate through the runtime’s normal APIs deliberately exceed or misuse allowed behavior, such as: excessive message sending repeated quota exhaustion attempts to perform actions beyond their assigned role Their purpose is to demonstrate how the governance and enforcement logic: detects undesirable behavior explains the decision taken limits or constrains impact All such behavior must remain within the normal runtime control flow. Demo Expectations (Critical) The final deliverable must support a live, walk-through-friendly demo. When the demo executable is run, an audience should be able to follow: what the system is doing what decisions are being evaluated why a specific decision was made what consequence followed The demo must clearly support the following flow: Run the executable with one configuration Modify configuration values (e.g., limits or thresholds) Re-run the same executable Observe and explain changed behavior Example (illustrative only): [Policy] Plugin Sender requests SendMessage [Policy] Rule: MaxMessagesPerRound = 1 → DENY [Trust] Repeated violation detected [Enforcement] Credits reduced to 0 [Scheduler] Plugin execution paused The emphasis is on clarity, narration, and predictability of output. Execution Model All behavior is demonstrated within a single runtime context Execution order is deterministic to keep decision flow observable Control flow must remain easy to reason about during live demos This execution model is intentional and should be preserved. Required Skills Strong C / C++ systems programming experience Familiarity with OS concepts such as scheduling, resource control, and policy enforcement Comfort with Win32 user-mode development Ability to write clear, readable, explainable system code Ability to reason about control logic and decision boundaries Experience with teaching operating systems, runtime engines, or policy-driven systems is a plus. Deliverables Source code integrated into the existing runtime A runnable demo executable External configuration files controlling governance behavior Demonstration scenarios including: normal behavior misbehaving behavior enforcement outcomes Documentation explaining: governance rules trust indicators enforcement behavior how to walk through the demo Success Criteria This phase is considered successful if: The demo runs without requiring code inspection An observer can clearly understand why decisions occur Misbehavior results in visible, explainable consequences Modifying configuration leads to observable behavioral changes Existing runtime mechanisms remain largely unchanged Engagement Model Milestone-based delivery Early demos expected Emphasis on correctness, clarity, and explanation Architectural discipline is as important as implementation Closing Context This project is about building a runtime that makes control decisions visible and understandable under stress, rather than one that merely executes logic. The emphasis is on intentional behavior, explicit reasoning, and clean demonstration flow.

ID do Projeto: 40149249