update structure and links

Author: jyecusch

docs/basics/project-structure.mdx

@@ -10,7 +10,7 @@ Nope, the Nitric CLI can run applications for development and testing directly o
 
 ## What programming languages does Nitric support?
 
-Nitric's API is built on gRPC. There are SDKs already available for [several languages](/concepts/language-support), and gRPC also provides support and code generation for many other languages. If you'd like to work on a new language SDK, reach out in [Discord](https://nitric.io/chat).
+Nitric's API is built on gRPC. There are SDKs already available for [several languages](/reference/languages), and gRPC also provides support and code generation for many other languages. If you'd like to work on a new language SDK, reach out in [Discord](https://nitric.io/chat).
 
 ## Does Nitric help with data portability?
 

docs/faq.mdx

@@ -14,7 +14,7 @@ Projects can have as many service files as desired, and each one will map to a c
 
 The Nitric SDK offers a comprehensive set of tools, including handlers for events/topics, queues, storage, key-value (KV) stores, schedules, APIs and secrets. These components are the essential building blocks for building cloud applications.
 
-SDKs communicate with the Nitric Server using gRPC and Protocol Buffers, which enables the framework to support [many languages](/concepts/language-support). Resources defined in the SDK do not require low-level configuration, which means that application code will never contain parameters or annotations for config, such as the replication policies for data stores. This fine-grained control is handled by [Providers](/concepts/how-ops-use-nitric#nitric-providers), which are described in the Ops workflow.
+SDKs communicate with the Nitric Server using gRPC and Protocol Buffers, which enables the framework to support [many languages](/reference/languages). Resources defined in the SDK do not require low-level configuration, which means that application code will never contain parameters or annotations for config, such as the replication policies for data stores. This fine-grained control is handled by [Providers](/foundations/deployment/providers), which are described in the Ops workflow.
 
 ## Local Cloud Emulation
 

docs/further-reading/how-devs-use-nitric.mdx

@@ -29,4 +29,4 @@ A combination of a Runtime and Deployment Plugin in Nitric is called a “provid
 
 ## Language SDKs
 
-Language SDKs enable Nitric to support various programming languages and execution environments. Language support is idiomatic, designed to feel familiar to developers of each language and make the best use of unique language features. Community support is offered for the [following languages](/concepts/language-support).
+Language SDKs enable Nitric to support various programming languages and execution environments. Language support is idiomatic, designed to feel familiar to developers of each language and make the best use of unique language features. Community support is offered for the [following languages](/reference/languages).

docs/further-reading/how-nitric-works.mdx

@@ -6,7 +6,7 @@ description: 'How to deploy Nitric applications'
 
 Nitric applications are decoupled from the underlying hosting provider, allowing you to develop your application locally and deploy it to your preferred cloud provider or another platform without these concerns bleeding into the application code.
 
-You can read more the [concepts](/concepts/how-nitric-works) behind Nitric to understand why this separation is important and how it is achieved. This page will focus on the deployment process and how to configure your application for deployment.
+You can read about why this separation is important on the [why nitric](/foundations/why-nitric) page. This page will focus on the deployment process and how to configure your application for deployment.
 
 <Note>
   If you're new to Nitric we recommend starting with the [quickstart
@@ -64,7 +64,7 @@ You can also extend the existing providers to change which cloud services are us
 
 ## Deploying your application
 
-Read the concepts page on [deployment](/concepts/deployment) to understand how Nitric prepares your application for deployment. This section focuses on how to configure your application for deployment and how to deploy it.
+This section focuses on how to configure your application for deployment and how to deploy it.
 
 There are two primary commands for deploying your application with Nitric:
 

docs/basics/deployment.mdx renamed to docs/get-started/foundations/deployment/index.mdx

@@ -1,8 +1,8 @@
 ---
-description: Introducing the concept of Infrastructure from Code (IfC) and how Nitric uses it to automate infrastructure and deployment.
+description: Nitric allows applications to declare infrastructure requirements and generate the cloud infrastructure automation needed to deploy and manage the services, using Infrastructure-from-Code.
 ---
 
-# Infrastructure from Code (IfC)
+# Infrastructure
 
 Infrastructure from Code (IfC) is an extension of Infrastructure as Code (IaC) that takes runtime application code into consideration and enhances Separation of Concerns (SoC).
 

docs/concepts/infrastructure-from-code.mdx renamed to docs/get-started/foundations/infrastructure/index.mdx

@@ -0,0 +1,17 @@
+---
+description: 'Nitric Services Overview'
+---
+
+# Services
+
+In Nitric, a service is an entrypoint for your application's logic. Each service represents a specific task or function your app needs to handle, such as managing APIs, processing events, handling web socket connections, or running scheduled tasks. Services are designed to be highly flexible and scalable, meaning you can have a single service handling multiple routes or create multiple services that each handle specific tasks.
+
+## How Services Work
+
+When you define a service in your nitric.yaml file, Nitric automatically takes care of turning it into a container. Each service can then run independently, allowing your app to scale and manage different workloads efficiently. Services can interact with resources like databases, queues, and buckets, which are defined separately but linked at runtime by Nitric.
+
+## Standard Services
+
+## Batch Services
+
+Batch services are designed to process large amounts of data in a single operation. They are ideal for tasks like data processing, image resizing, or running scheduled jobs. Batch services can be triggered by events, run on a schedule, or be manually invoked.

docs/basics/resources-overview.mdx renamed to docs/get-started/foundations/infrastructure/resources.mdx

@@ -4,7 +4,7 @@ description: 'Configuring a Nitric Project using nitric.yaml'
 
 # Configuration
 
-The Nitric CLI uses a configuration file named `nitric.yaml` to define the structure of your project. This file defines the name of your project, where nitric should look for the entrypoints to your application, and other project-specific settings.
+The Nitric CLI uses a configuration file named `nitric.yaml` to define the structure of your project. This file specifies the name of your project, where nitric should look for the entrypoints to your application, and other project-specific settings.
 
 Projects created from a template using the Nitric CLI will have a `nitric.yaml` file created for you. If you are creating a project from scratch, you can create a `nitric.yaml` file in the root of your project.
 
@@ -39,7 +39,7 @@ The name of your project. This is used to identify your project and it used when
 
 ### `services`
 
-A list of [service](/concepts/service) types that make up your project. Typically, nitric will build each service in your project into a separate container image. Each service can have its own runtime, build configuration, and start command.
+A list of [service](/foundations/infrastructure/services) types that make up your project. Typically, nitric will build each service in your project into a separate container image. Each service can have its own runtime, build configuration, and start command.
 
 #### `match`
 
@@ -95,7 +95,7 @@ If a runtime is provided it must match the name of a runtime configuration in th
 
 Type is essentially the name for this group of services. It is used to group services together for deployment and resource management. If not provided, the service will be grouped under the 'default' type.
 
-The most common use case for this is grouping service with similar deployed resource requirements together. For example, you make have a set of services that required additional vCPU or memory resources at runtime. You can group these services together under a specific type and apply resource constraints to that type in a [stack file](/concepts/stack).
+The most common use case for this is grouping service with similar deployed resource requirements together. For example, you make have a set of services that required additional vCPU or memory resources at runtime. You can group these services together under a specific type and apply resource constraints to that type in a [stack file](/foundations/deployment/stacks).
 
 For example, if you have a set of services that require additional memory, you can group them together under a type named `memory-intensive`, separate from the default type.
 
@@ -144,9 +144,9 @@ go run ./services/service2/main.go
 
 ### `batch-services` (optional)
 
-A list of [batch service](/concepts/batch-service) types that make up your project. Batch services are used to run high-performance computing tasks, data processing or tasks requiring GPUs, or a large number of vCPUs or memory.
+A list of [batch service](/foundations/infrastructure/services#batch-services) types that make up your project. Batch services are used to run high-performance computing tasks, data processing or tasks requiring GPUs, or a large number of vCPUs or memory.
 
-Batch services are similar to services but are optimized for running batch processing tasks. You can read more about batch services in the [batch services](/concepts/service#batch) section.
+Batch services are similar to services but are optimized for running batch processing tasks. You can read more about batch services in the [batch service](/foundations/infrastructure/services#batch-services) section.
 
 The configuration options for `batch-services` are the same as for `services`.