+
+ |
|
@@ -59,15 +49,18 @@ Semantic Kernel is available to explore AI and build apps with C# and Python: Using Semantic Kernel in Python | +
+
+
+ |
+
+### Option #2: Folder naming matches assembly name
+
+```text
+SK-dotnet
+├── samples/
+└── libraries/
+ ├── SK-dotnet.sln
+ │
+ ├── Microsoft.SemanticKernel.Connectors.AI.OpenAI*
+ │ ├── src
+ │ └── tests
+ │ (Not shown but all projects will have src and tests subfolders)
+ ├── Microsoft.SemanticKernel.Connectors.AI.HuggingFace
+ ├── Microsoft.SemanticKernel.Connectors.Memory.AzureCognitiveSearch
+ ├── Microsoft.SemanticKernel.Connectors.Memory.Qdrant
+ │
+ ├── Microsoft.SemanticKernel.Planners*
+ │
+ ├── Microsoft.SemanticKernel.Reliability.Basic*
+ ├── Microsoft.SemanticKernel.Reliability.Polly
+ │
+ ├── Microsoft.SemanticKernel.TemplateEngines.Basic*
+ │
+ ├── Microsoft.SemanticKernel.Functions.Semantic*
+ ├── Microsoft.SemanticKernel.Functions.Grpc
+ ├── Microsoft.SemanticKernel.Functions.OpenAPI
+ │
+ ├── Microsoft.SemanticKernel.Plugins.Core*
+ ├── Microsoft.SemanticKernel.Plugins.Document
+ ├── Microsoft.SemanticKernel.Plugins.MsGraph
+ ├── Microsoft.SemanticKernel.Plugins.Web
+ │
+ ├── InternalUtilities
+ │
+ ├── IntegrationTests
+ │
+ ├── Microsoft.SemanticKernel.Core*
+ ├── Microsoft.SemanticKernel.Abstractions*
+ └── Microsoft.SemanticKernel.MetaPackage
+```
+
+***Notes:***
+
+- There will only be a single solution file (initially).
+- Projects will be grouped in the solution i.e., connectors, planners, plugins, functions, extensions, ...
+- Each project folder contains a `src` and `tests` folder.
+- There will be a gradual process to move existing unit tests to the correct location as some projects will need to be broken up.
+
+## More Information
+
+### Current Project Structure
+
+```text
+SK-dotnet
+├── samples/
+└── src/
+ ├── connectors/
+ │ ├── Connectors.AI.OpenAI*
+ │ ├── Connectors...
+ │ └── Connectors.UnitTests
+ ├── extensions/
+ │ ├── Planner.ActionPlanner*
+ │ ├── Planner.SequentialPlanner*
+ │ ├── Planner.StepwisePlanner
+ │ ├── TemplateEngine.PromptTemplateEngine*
+ │ └── Extensions.UnitTests
+ ├── InternalUtilities/
+ ├── skills/
+ │ ├── Skills.Core
+ │ ├── Skills.Document
+ │ ├── Skills.Grpc
+ │ ├── Skills.MsGraph
+ │ ├── Skills.OpenAPI
+ │ ├── Skills.Web
+ │ └── Skills.UnitTests
+ ├── IntegrationTests
+ ├── SemanticKernel*
+ ├── SemanticKernel.Abstractions*
+ ├── SemanticKernel.MetaPackage
+ └── SemanticKernel.UnitTests
+```
+
+\\* - Means the project is part of the Semantic Kernel meta package
+
+### Project Descriptions
+
+| Project | Description |
+|-------------------------------------|-------------|
+| Connectors.AI.OpenAI | Azure OpenAI and OpenAI service connectors |
+| Connectors... | Collection of other AI service connectors, some of which will move to another repository |
+| Connectors.UnitTests | Connector unit tests |
+| Planner.ActionPlanner | Semantic Kernel implementation of an action planner |
+| Planner.SequentialPlanner | Semantic Kernel implementation of a sequential planner |
+| Planner.StepwisePlanner | Semantic Kernel implementation of a stepwise planner |
+| TemplateEngine.Basic | Prompt template engine basic implementations which are used by Semantic Functions only |
+| Extensions.UnitTests | Extensions unit tests |
+| InternalUtilities | Internal utilities which are reused by multiple NuGet packages (all internal) |
+| Skills.Core | Core set of native functions which are provided to support Semantic Functions |
+| Skills.Document | Native functions for interacting with Microsoft documents |
+| Skills.Grpc | Semantic Kernel integration for GRPC based endpoints |
+| Skills.MsGraph | Native functions for interacting with Microsoft Graph endpoints |
+| Skills.OpenAPI | Semantic Kernel integration for OpenAI endpoints and reference Azure Key Vault implementation |
+| Skills.Web | Native functions for interacting with Web endpoints e.g., Bing, Google, File download |
+| Skills.UnitTests | Skills unit tests |
+| IntegrationTests | Semantic Kernel integration tests |
+| SemanticKernel | Semantic Kernel core implementation |
+| SemanticKernel.Abstractions | Semantic Kernel abstractions i.e., interface, abstract classes, supporting classes, ... |
+| SemanticKernel.MetaPackage | Semantic Kernel meta package i.e., a NuGet package that references other required Semantic Kernel NuGet packages |
+| SemanticKernel.UnitTests | Semantic Kernel unit tests |
+
+### Naming Patterns
+
+Below are some different examples of Assembly and root namespace naming that are used in the projects.
+
+```xml
+ 
+
diff --git a/docs/decisions/0009-function-and-kernel-result-types.md b/docs/decisions/0009-function-and-kernel-result-types.md
new file mode 100644
index 000000000000..bf5d6552837b
--- /dev/null
+++ b/docs/decisions/0009-function-and-kernel-result-types.md
@@ -0,0 +1,84 @@
+---
+# These are optional elements. Feel free to remove any of them.
+status: accepted
+date: 2023-09-21
+deciders: shawncal, dmytrostruk
+consulted:
+informed:
+---
+# Replace SKContext as Function/Kernel result type with FunctionResult and KernelResult models
+
+## Context and Problem Statement
+
+Methods `function.InvokeAsync` and `kernel.RunAsync` return `SKContext` as result type. This has several problems:
+
+1. `SKContext` contains property `Result`, which is `string`. Based on that, it's not possible to return complex type or implement streaming capability in Kernel.
+2. `SKContext` contains property `ModelResults`, which is coupled to LLM-specific logic, so it's only applicable to semantic functions in specific cases.
+3. `SKContext` as a mechanism of passing information between functions in pipeline should be internal implementation. Caller of Kernel should provide input/request and receive some result, but not `SKContext`.
+4. `SKContext` contains information related to the last executed function without a way to access information about specific function in pipeline.
+
+## Decision Drivers
+
+1. Kernel should be able to return complex type as well as support streaming capability.
+2. Kernel should be able to return data related to function execution (e.g. amount of tokens used) in a way, when it's not coupled to AI logic.
+3. `SKContext` should work as internal mechanism of passing information between functions.
+4. There should be a way how to differentiate function result from kernel result, since these entities are different by nature and may contain different set of properties in the future.
+5. The possibility to access specific function result in the middle of pipeline will provide more insights to the users how their functions performed.
+
+## Considered Options
+
+1. Use `dynamic` as return type - this option provides some flexibility, but on the other hand removes strong typing, which is preferred option in .NET world. Also, there will be no way how to differentiate function result from Kernel result.
+2. Define new types - `FunctionResult` and `KernelResult` - chosen approach.
+
+## Decision Outcome
+
+New `FunctionResult` and `KernelResult` return types should cover scenarios like returning complex types from functions, supporting streaming and possibility to access result of each function separately.
+
+### Complex Types and Streaming
+
+For complex types and streaming, property `object Value` will be defined in `FunctionResult` to store single function result, and in `KernelResult` to store result from last function in execution pipeline. For better usability, generic method `GetValue