From 65c8aeeac839fc23c6315599cfd4870b4a955fa0 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 10:46:21 -0500 Subject: [PATCH 01/11] Update 0032-agents.md Fix typo in code comment adapatation -> adaptation --- docs/decisions/0032-agents.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/decisions/0032-agents.md b/docs/decisions/0032-agents.md index 6e1da34b27fe..da91bc64a9c1 100644 --- a/docs/decisions/0032-agents.md +++ b/docs/decisions/0032-agents.md @@ -376,7 +376,7 @@ await WriteMessagesAsync(chat.InvokeAsync(agent1)); await WriteMessagesAsync(chat.InvokeAsync(agent2)); // The entire history may be accessed. -// Agent specific history is an adapataton of the primary history. +// Agent specific history is an adaptaton of the primary history. await WriteMessagesAsync(chat.GetHistoryAsync()); await WriteMessagesAsync(chat.GetHistoryAsync(agent1)); await WriteMessagesAsync(chat.GetHistoryAsync(agent2)); @@ -470,4 +470,4 @@ chat.add_agent(agent3) # Execute the chat until termination await write_message(chat.invoke()) -``` \ No newline at end of file +``` From de43c4493635d84c290d8e3ac9fcd0d4d4324453 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 10:48:09 -0500 Subject: [PATCH 02/11] Update 0032-agents.md Fix typo in code comment adapatation -> adaptation --- docs/decisions/0032-agents.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0032-agents.md b/docs/decisions/0032-agents.md index da91bc64a9c1..d65e8b878ad3 100644 --- a/docs/decisions/0032-agents.md +++ b/docs/decisions/0032-agents.md @@ -401,7 +401,7 @@ await write_message(chat.invoke(agent1)) await write_message(chat.invoke(agent2)) # The entire history may be accessed. -# Agent specific history is an adapataton of the primary history. +# Agent specific history is an adaptaton of the primary history. await write_message(chat.get_history()) await write_message(chat.get_history(agent1)) await write_message(chat.get_history(agent2)) From 785502dab6457f7b64118e4e9c55e461dffb9747 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 10:53:21 -0500 Subject: [PATCH 03/11] Update 0042-samples-restructure.md typo Beginers -> Beginners --- docs/decisions/0042-samples-restructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0042-samples-restructure.md b/docs/decisions/0042-samples-restructure.md index 6dcec8e934d5..c69a0e4cebdc 100644 --- a/docs/decisions/0042-samples-restructure.md +++ b/docs/decisions/0042-samples-restructure.md @@ -70,7 +70,7 @@ samples/ Pros: - Simpler and Less verbose structure (Worse is Better: Less is more approach) -- Beginers will be presented (sibling folders) to other tutorials that may fit better on their need and use case. +- Beginners will be presented (sibling folders) to other tutorials that may fit better on their need and use case. - Getting started will not be imposed. Cons: From 8bfa682c4c7ef855e7e2d0906b9fc335de12608b Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 10:53:56 -0500 Subject: [PATCH 04/11] Update 0042-samples-restructure.md typo starded -> started --- docs/decisions/0042-samples-restructure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0042-samples-restructure.md b/docs/decisions/0042-samples-restructure.md index c69a0e4cebdc..7b7db930a784 100644 --- a/docs/decisions/0042-samples-restructure.md +++ b/docs/decisions/0042-samples-restructure.md @@ -101,7 +101,7 @@ Pros: Cons: -- If the Getting starded example does not have a valid example for the customer it has go back on other folders for more content. +- If the Getting started example does not have a valid example for the customer it has go back on other folders for more content. ### Option 3 - Conservative + Use Cases Based Root Categorization From e1171b7d8351e5edbcdd7eb421638dd32dfbf811 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 10:57:15 -0500 Subject: [PATCH 05/11] Update 0042-samples-restructure.md alphabetizing typos --- docs/decisions/0042-samples-restructure.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/decisions/0042-samples-restructure.md b/docs/decisions/0042-samples-restructure.md index 7b7db930a784..5e0813410a29 100644 --- a/docs/decisions/0042-samples-restructure.md +++ b/docs/decisions/0042-samples-restructure.md @@ -130,7 +130,7 @@ Cons: - More verbose structure adds extra friction to find the samples. - `KernelContent` or `Modalities` is a internal term that may not be clear for the customer - `Documentation` may be confused a documents only folder, which actually contains code samples used in documentation. (not clear message) -- `Use Cases` may suggest an idea of real world use cases implemented, where in reality those are simple demostrations of a SK feature. +- `Use Cases` may suggest an idea of real world use cases implemented, where in reality those are simple demonstrations of a SK feature. ## KernelSyntaxExamples Decomposition Options @@ -449,7 +449,7 @@ Cons: ### KernelSyntaxExamples Decomposition Option 2 - Concept by Components Flattened Version -Similar approach to Option 1, but with a flattened structure using a single level of folders to avoid deep nesting and complexity authough keeping easy to navigate around the componentized concepts. +Similar approach to Option 1, but with a flattened structure using a single level of folders to avoid deep nesting and complexity although keeping easy to navigate around the componentized concepts. Large (Less files per folder): From 6238396932d9b994221717885919785099d2e7cf Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 11:17:34 -0500 Subject: [PATCH 06/11] Update 0046-java-repository-separation.md typo simultaneously --- docs/decisions/0046-java-repository-separation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0046-java-repository-separation.md b/docs/decisions/0046-java-repository-separation.md index 48008bbd28e1..e34898860c45 100644 --- a/docs/decisions/0046-java-repository-separation.md +++ b/docs/decisions/0046-java-repository-separation.md @@ -27,7 +27,7 @@ Also managing repository policies that are preferred by all languages is a chall complex build process to account for building multiple languages. If a user makes accidental changes to the repository outside their own language, or make changes to the common files, require sign off from other languages, leading to delays as we require review from users in other languages. Similarly common files such as GitHub Actions workflows, `.gitignore`, VS Code settings, `README.md`, `.editorconfig` etc, become -more complex as they have to simutaniously support multiple languages. +more complex as they have to simultaneously support multiple languages. In a community point of view, having a separate repo will foster community engagement, allowing developers to contribute, share ideas, and collaborate on the Java projects only. Additionally, it enables transparent tracking of contributions, making it easy to identify top contributors and acknowledge their efforts. From 54b8610df388b9eebfdc38192700e4d9c803b84b Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 11:19:42 -0500 Subject: [PATCH 07/11] Update 0047-azure-open-ai-connectors.md typo potentially --- docs/decisions/0047-azure-open-ai-connectors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0047-azure-open-ai-connectors.md b/docs/decisions/0047-azure-open-ai-connectors.md index c909574b9563..a9fc98e68eb6 100644 --- a/docs/decisions/0047-azure-open-ai-connectors.md +++ b/docs/decisions/0047-azure-open-ai-connectors.md @@ -37,7 +37,7 @@ A documentation guidance and samples/examples will be created to guide on how to ## OpenAI SDK limitations -The new OpenAI SDK introduce some limitations that need to be considered and pontentially can introduce breaking changes if not remediated by our internal implementation. +The new OpenAI SDK introduce some limitations that need to be considered and potentially can introduce breaking changes if not remediated by our internal implementation. - #### ⚠️ No support for multiple results (Choices) per request. From 834f7db538f42513c9fa40d1492ed25d9589d624 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 11:23:52 -0500 Subject: [PATCH 08/11] Update 0049-agents-assistantsV2.md typos --- docs/decisions/0049-agents-assistantsV2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/decisions/0049-agents-assistantsV2.md b/docs/decisions/0049-agents-assistantsV2.md index b606ca87016b..1a34a033a6fc 100644 --- a/docs/decisions/0049-agents-assistantsV2.md +++ b/docs/decisions/0049-agents-assistantsV2.md @@ -154,9 +154,9 @@ A pending change has been authored that introduces `FunctionChoiceBehavior` as a #### Assistant Invocation Options -When invoking an `OpenAIAssistantAgent` directly (no-chat), definition that only apply to a discrete run may be specified. These definition are defined as `OpenAIAssistantInvocationOptions` and ovetake precedence over any corresponding assistant or thread definition. +When invoking an `OpenAIAssistantAgent` directly (no-chat), definition that only apply to a discrete run may be specified. These definition are defined as `OpenAIAssistantInvocationOptions` and overtake precedence over any corresponding assistant or thread definition. -> Note: These definition are also impacted by the `ToolCallBehavior` / `FunctionChoiceBehavior` quadary. +> Note: These definition are also impacted by the `ToolCallBehavior` / `FunctionChoiceBehavior` quandary.

From df1208ca8150d9bb9c917cb65ab49deabc72aa55 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 11:37:07 -0500 Subject: [PATCH 09/11] Update 0050-updated-vector-store-design.md Spelling typos --- docs/decisions/0050-updated-vector-store-design.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/decisions/0050-updated-vector-store-design.md b/docs/decisions/0050-updated-vector-store-design.md index c008068b1e95..bd5237f4986b 100644 --- a/docs/decisions/0050-updated-vector-store-design.md +++ b/docs/decisions/0050-updated-vector-store-design.md @@ -113,7 +113,7 @@ classDiagram class IVectorRecordStore~TModel~{ <> +Upsert(TModel record) string - +UpserBatch(TModel record) string + +UpsertBatch(TModel record) string +Get(string key) TModel +GetBatch(string[] keys) TModel[] +Delete(string key) @@ -619,7 +619,7 @@ Option 1 is problematic on its own, since we have to allow consumers to create c a single interface like this, it will require them to implement many methods that they do not want to change. Options 4 & 5, gives us more flexibility while still preserving the ease of use of an aggregated interface as described in Option 1. -Option 2 doesn't give us the flexbility we need for break glass scenarios, since it only allows certain types of collections to be created. It also means +Option 2 doesn't give us the flexibility we need for break glass scenarios, since it only allows certain types of collections to be created. It also means that each time a new collection type is required it introduces a breaking change, so it is not a viable option. Since collection create and configuration and the possible options vary considerable across different database types, we will need to support an easy @@ -964,14 +964,14 @@ builder.Services.AddTransient ### Collection Creation 7. Release Collection Creation public interface. -8. Create cross db collection creation config that supports common functionality, and per daatabase implementation that supports this configuration. +8. Create cross db collection creation config that supports common functionality, and per database implementation that supports this configuration. 9. Add support for registering collection creation with SK container to allow automatic dependency injection. ### First Party Memory Features and well known model support 10. Add model and mappers for legacy SK MemoryStore interface, so that consumers using this has an upgrade path to the new memory storage stack. 11. Add model and mappers for popular loader systems, like Kernel Memory or LlamaIndex. -11. Explore adding first party implementations for common scenarios, e.g. semantic caching. Specfics TBD. +11. Explore adding first party implementations for common scenarios, e.g. semantic caching. Specifics TBD. ### Cross Cutting Requirements @@ -983,7 +983,7 @@ Need the following for all features: - Common Exception Handling - Samples, including: - Usage scenario for collection and record management using custom model and configured collection creation. - - A simple consumption example like semantic caching, specfics TBD. + - A simple consumption example like semantic caching, specifics TBD. - Adding your own collection creation implementation. - Adding your own custom model mapper. - Documentation, including: From 2ea8973cc7c1f6608778b399b5799626660c584d Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 11:58:01 -0500 Subject: [PATCH 10/11] Update 0058-vector-search-design.md typo behavior --- docs/decisions/0058-vector-search-design.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/decisions/0058-vector-search-design.md b/docs/decisions/0058-vector-search-design.md index c60ce2073018..63081a645076 100644 --- a/docs/decisions/0058-vector-search-design.md +++ b/docs/decisions/0058-vector-search-design.md @@ -247,7 +247,7 @@ class AzureAISearchVectorStoreRecordCollection : IVectorSearch One of the main requirements is to allow future extensibility with additional query types. One way to achieve this is to use an abstract base class that can auto implement new methods that throw with NotSupported unless overridden by each implementation. This behavior would -be similar to Option 1. With Option 1 though, the same bahvior is achieved via extension methods. +be similar to Option 1. With Option 1 though, the same behavior is achieved via extension methods. The set of methods end up being the same with Option 1 and Option 3, except that Option 1 also has a Search method that takes `VectorSearchQuery` as input. From 828ea7cf0f86171a6882ef9e2a7c8b6b4f2c0347 Mon Sep 17 00:00:00 2001 From: Kyle McMaster Date: Mon, 3 Mar 2025 12:01:05 -0500 Subject: [PATCH 11/11] Update 0061-function-call-behavior.md typo space in s upplied --- docs/decisions/0061-function-call-behavior.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/decisions/0061-function-call-behavior.md b/docs/decisions/0061-function-call-behavior.md index 8bfa43704943..843fc332c18c 100644 --- a/docs/decisions/0061-function-call-behavior.md +++ b/docs/decisions/0061-function-call-behavior.md @@ -242,8 +242,7 @@ More details can be found here: [Serialize polymorphic types](https://learn.micr To support custom function choice behaviors, the custom types should be registered for polymorphic deserialization. Clearly, the approach using the JsonDerivedType attribute is not viable, as users cannot annotate `FunctionChoiceBehavior` SK class. However, they could register their custom type resolver that would register their custom type(s) if they had access to JsonSerializerOptions used by JsonSerializer during deserialization. -Unfortunately, SK does not expose those options publicly today. Even if it had, there are YAML prompts that are deserialized by the YamlDotNet library that would require same custom types s -upplied via YAML specific deserializer extensibility mechanisms - YamlTypeConverter. +Unfortunately, SK does not expose those options publicly today. Even if it had, there are YAML prompts that are deserialized by the YamlDotNet library that would require same custom types supplied via YAML specific deserializer extensibility mechanisms - YamlTypeConverter. This would mean that if a user wants the same custom function calling choice to be used in both YAML and JSON prompts, they would have to register the same custom type twice - for JSON via a custom type resolver and for YAML via a custom YamlTypeConverter. That would also require a mechanism of supplying custom resolvers/converters to all SK `CreateFunctionFrom*Prompt` extension methods. @@ -378,4 +377,4 @@ There were a few decisions taken during the ADR review: - Option 1.1 was chosen as the preferred option for the new function call behavior model. - It was decided to postpone the implementation of the inheritance mechanism that allows a service to inherit the parent function choice behavior configuration. - It was decided that the Breaking Glass support is out of scope for now, but it may be included later if necessary. -- Option 2.5, which presumes supplying function call choices and function invocation configurations via prompt execution settings, was preferred over the other options due to its simplicity, absence of breaking changes, and familiar developer experience. \ No newline at end of file +- Option 2.5, which presumes supplying function call choices and function invocation configurations via prompt execution settings, was preferred over the other options due to its simplicity, absence of breaking changes, and familiar developer experience.