> ## Documentation Index
> Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Components and Structure

> How Kodexa components are owned by organizations and shared across the platform, including resource types, URI schemes, and the resolver API.

## Ownership of Components by Organizations

Each component in the Kodexa platform is uniquely owned by a single organization. Components can be designated as "public", permitting their utilization by other organizations.

## Resource URIs

Components are identified by a **resource URI** that combines a scheme, the organization's slug, and the component's slug:

```
scheme://org_slug/component_slug
```

For example:

```
module://kodexa/pdf-parser
taxonomy://acme-corp/invoice-taxonomy
data-form://kodexa/spreading-form
```

<Note>
  Versions are no longer used in resource URIs. The platform resolves resources by organization and slug only. If a legacy URI includes a version suffix (e.g., `module://kodexa/pdf-parser:1.0.0`), the version is stripped automatically.
</Note>

## Resolver API

The platform provides a resolver endpoint that converts a resource URI into the concrete API path for that resource.

### Resolving a Resource

```bash theme={null}
POST /api/resolve?path=module://kodexa/pdf-parser
```

**Response:**

```json theme={null}
{
  "uri": "module://kodexa/pdf-parser",
  "path": "/api/modules/abc-123-def-456"
}
```

The returned `path` is the ID-based API endpoint you can use for subsequent operations on that resource.

### Discovering Available Schemes

```bash theme={null}
GET /api/resolve/schemes
```

Returns the list of all supported resource schemes and their API endpoint patterns.

## Resource Types

Kodexa supports the following resource types, each with a URI scheme and corresponding API path:

| Scheme                   | Aliases                  | API Path                       | Scope   | Description                                                         |
| ------------------------ | ------------------------ | ------------------------------ | ------- | ------------------------------------------------------------------- |
| `module`                 | `model`, `model-runtime` | `/api/modules`                 | Org     | Modules for parsing, transforming, and labeling documents           |
| `document-store`         | `store`                  | `/api/document-stores`         | Org     | Repositories for files and their document representations           |
| `data-store`             |                          | `/api/data-stores`             | Org     | Structured data extracted from documents                            |
| `taxonomy`               | `data-definition`        | `/api/data-definitions`        | Org     | Data structure definitions within Kodexa                            |
| `project-template`       |                          | `/api/project-templates`       | Org     | Blueprints for creating new projects with predefined configurations |
| `prompt`                 | `prompt-template`        | `/api/prompts`                 | Org     | Prompt templates for LLM-based processing                           |
| `data-form`              |                          | `/api/data-forms`              | Org     | Form definitions for data entry and review interfaces               |
| `knowledge-set`          |                          | `/api/knowledge-sets`          | Org     | Collections of knowledge items for reference and extraction         |
| `knowledge-item-type`    |                          | `/api/knowledge-item-types`    | Org     | Type definitions for knowledge items                                |
| `knowledge-feature-type` |                          | `/api/knowledge-feature-types` | Org     | Type definitions for knowledge features                             |
| `service-bridge`         |                          | `/api/service-bridges`         | Org     | Bridge definitions for external service integrations                |
| `task-status`            |                          | `/api/project-task-statuses`   | Project | Task status definitions within a project                            |
| `task-template`          |                          | `/api/task-templates`          | Project | Task template blueprints within a project                           |

Aliases resolve to the same underlying resource. For example, `model://kodexa/invoice-extractor` and `module://kodexa/invoice-extractor` both resolve via `/api/modules`.

### Project-Scoped Resources

Most resource schemes are scoped to the organization. However, some resources (`task-status`, `task-template`) are scoped to a project within an organization. Their URIs use a three-part path:

```
scheme://orgSlug/projectSlug/resourceSlug
```

For example:

```
task-status://acme-corp/invoice-project/approved
task-template://acme-corp/invoice-project/document-review
```

The resolver looks up the project by `orgSlug/projectSlug` and then finds the resource within that project by its slug.

## Referencing Components

When referencing a component in YAML configuration files, use the URI scheme format:

```yaml theme={null}
# Module reference in a pipeline step
ref: module://kodexa/pdf-parser

# Taxonomy reference
ref: taxonomy://acme-corp/invoice-taxonomy

# Service bridge reference in an Activity step
serviceBridgeRef: service-bridge://acme-corp/ap-system
```

In contexts where the scheme is implicit (such as a `taxonomies` section that only accepts taxonomy references), you can use the short form:

```yaml theme={null}
taxonomies:
  - ref: "acme-corp/invoice-taxonomy"
```

## Projects and Entities

Projects amalgamate various components to address a specific use-case. Components capture metadata and are deployable, while entities store data or link to content. Typical entities include:

* Projects
* Documents
* Data objects
* Activity runs
* Tasks

Entities each have a unique ID and are typically managed by a type of component or fall under the organization's purview. This distinction is critical: components form part of the organizational configuration for a use-case, whereas entities are associated with the projects, data, or documents being worked on.