Add external governance checkpoint sample

[jw_ond (jw-ond)]

Summary

• Adds a minimal .NET Filtering concept sample for placing an external governance checkpoint before automatic function invocation.
• Demonstrates constructing a function-call action envelope, computing a stable SHA-256 checkpoint reference, and mapping checkpoint verdicts to execute, pause, or block behavior.
• Keeps the checkpoint vendor-neutral with an in-memory example client and no external dependencies.

Test Plan

• git diff --cached --check
• gh api repos/microsoft/semantic-kernel/compare/main...jw-ond:osuite/external-governance-checkpoint
• Not run: dotnet test dotnet/samples/Concepts/Concepts.csproj --no-restore --filter "FullyQualifiedName=Filtering.ExternalGovernanceCheckpoint" (dotnet is not installed in this environment: zsh: command not found: dotnet)

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 53% | Result: All clear

Reviewed: Correctness, Security Reliability, Test Coverage, Failure Modes, Design Approach

---

Automated review by jw-ond's agents

[Copilot]

Pull request overview

Adds a new .NET Concepts/Filtering sample demonstrating how an external governance checkpoint can be evaluated before proceeding with automatic function invocation, and links it from the Concepts samples README.

Changes:

• Add ExternalGovernanceCheckpoint sample showing an IAutoFunctionInvocationFilter that maps checkpoint verdicts to execute/pause/deny outcomes and annotates results with governance metadata.
• Add SHA-256-based checkpoint reference computation for the action envelope.
• Update Concepts samples README to include the new Filtering sample link.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
dotnet/samples/Concepts/README.md	Adds the new filtering sample to the Concepts index.
dotnet/samples/Concepts/Filtering/ExternalGovernanceCheckpoint.cs	New sample demonstrating an external checkpoint gate for auto function invocation and result metadata.

Suppressed comments (1)

dotnet/samples/Concepts/Filtering/ExternalGovernanceCheckpoint.cs:70

• Same issue as above: ImportPluginFromFunctions clones the function, so the function variable here isn’t the one stored in the kernel’s plugins (and will typically have a null PluginName). Use the imported function instance when creating the context so the envelope reflects real auto-invocation behavior.

        kernel.ImportPluginFromFunctions("CustomerAdmin", [function]);

        var context = CreateAutoFunctionInvocationContext(kernel, function, new KernelArguments());

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jw_ond (jw-ond)]

Updated in fcedcd9 to address the review items:\n\n- Use the imported KernelFunction instance returned from ImportPluginFromFunctions when constructing the auto-invocation context, so PluginName reflects real plugin invocation behavior.\n- Treat ActionEnvelope.PluginName as nullable and format labels safely when the upstream API does not provide one.\n- Compute the checkpoint reference from the semantic action fields (plugin, function, arguments) rather than ToolCallId / sequence fields, so the stable reference is not churned by model-generated call IDs. The full envelope still carries sequence and ToolCallId context to the checkpoint.\n\nVerification: ran git diff --check on the changed sample file locally. This machine does not have dotnet installed, so I could not run the Concepts sample build locally; the remote CLA/label checks are green.