# Configure API reference structure and filtering

Use the Delphi entry under `content` to control how DocInsight organizes generated API reference and which symbols it publishes. These settings are separate from the source-analysis options under `sources`. First, configure a Delphi source and content entry.

## Configuration overview

The following expanded content entry shows semantic name filters together with the structure, reference, section, and visibility options:

json

    {
      "content": {
        "api": {
          "type": "delphi",
          "source": "main",
          "structure": {
            "toc": {
              "scope": "project"
            },
            "path": {
              "project": "auto"
            }
          },
          "reference": {
            "inherited_members": "linked"
          },
          "filter": {
            "projects": {
              "include": ["MyLibrary*"],
              "exclude": ["*.Tests"]
            },
            "units": {
              "exclude": ["*.Internal"]
            },
            "symbols": {
              "exclude": ["*.Deprecated", "*.Internal*"]
            },
            "sections": {
              "implementation": false
            },
            "visibility": {
              "private": false,
              "strict_private": false,
              "protected": true,
              "strict_protected": true
            }
          }
        }
      }
    }

The project, unit, and symbol filters in this example are sample publication constraints; omit any dimension to select all names in it. The remaining values shown are their effective defaults. You normally omit fields that keep their defaults and set only the values you want to change. When omitted, `strict_private` follows `private`, and `strict_protected` follows `protected`.

## Organize generated reference topics

Use `structure.toc.scope` to choose how generated API navigation is divided:

Value | Navigation structure
--- | ---
`unified` | One TOC for the entire Delphi content entry
`project` | A project list with a separate TOC view for each project
`unit` | A project list with a separate TOC view for each unit

The default is `project`.

## Configure generated page paths

Use `structure.path.project` to control whether generated API paths contain a project or package segment:

Value | Project path segment
--- | ---
`none` | Never included
`auto` | Included for programs and libraries, but not packages
`always` | Always included

The default is `auto`.

## Configure inherited members

Use `reference.inherited_members` to control inherited members on generated type pages:

Value | Type-page behavior
--- | ---
`linked` | List inherited members that resolve to published API topics
`none` | List only members declared by the type

The default is `linked`.

## Control published API symbols

Control publication at the project, unit, declaration-section, visibility, or individual-symbol level:

- Use `sources.<name>.files` and `exclude` to select direct project-entry files during discovery.

- Use the Delphi content entry's `filter` block to select Xref namespaces, projects, units, and symbols and to control implementation declarations and member visibility.

- Use `<exclude />` in an XML documentation comment to omit one declaration.

### Filter by semantic name

The four semantic dimensions each accept the same name-filter object:

Property | Name matched
--- | ---
`filter.xref_namespaces` | Effective Xref namespace assigned to a project
`filter.projects` | Delphi project name derived from the `.dproj` filename stem
`filter.units` | Declared fully qualified unit name
`filter.symbols` | Unit-qualified symbol name without a parameter list or overload signature

Each name filter accepts `include`, `exclude`, or both. Every present array must be non-empty. Omitting the dimension selects every name in it; omitting only `include` also starts from every name. Patterns in one array are alternatives, then `exclude` is applied after `include`, so exclusion wins when both match.

Patterns are case-insensitive and match the complete semantic name. They are wildcard patterns rather than filesystem globs: `*` matches zero or more characters, `?` matches exactly one, and all other characters are literal. A `.` has no special boundary behavior, so `*` can match across qualified-name segments. `/` and `\\` are not allowed.

`filter.xref_namespaces` uses the namespace selected by the source's `xref` settings. `filter.projects` applies to every project with a matching portable name; project groups are discovery containers and are not matched. Unit patterns apply to every occurrence of the qualified unit name in an eligible project. Symbol patterns select an entire overload family because parameter types and overload signatures are not part of the matched name.

The dimensions combine by containment: a symbol is publishable only when its project passes both `xref_namespaces` and `projects`, its unit passes `units`, and the symbol passes `symbols` plus the section and visibility rules. Declarations omitted from publication remain available for analysis and cross-reference resolution.

### Filter by visibility

Public, published, and automated declarations are always included. Protected and strict protected members are included by default; private and strict private members are excluded by default. Set `filter.visibility.private`, `strict_private`, `protected`, or `strict_protected` only when you want to override that behavior.

### Filter by source section

Interface declarations are always eligible for publication. Implementation declarations are excluded by default. Set `filter.sections.implementation` to `true` when generating internal documentation that should include them.

### Exclude one declaration

Add `<exclude />` to the XML documentation comment for a declaration that should remain in source but should not have a published API topic:

pascal

    /// <exclude />
    procedure InternalResetCache;

For all Delphi content fields and accepted values, see the Manifest reference.