Settings, categories, logical entities, exclusions, and the indexing procedure.
Before creating a schema, source files need to live somewhere Codegraphs can read them. The Resource Management panel manages these source locations independently of any specific schema, so the same resource can later be attached to one or more schemas.
| Source Type | How it's added |
|---|---|
| Uploads | Upload a ZIP and extract it into a managed folder |
| Git | Clone a repository URL, with a branch, access token, or SSH key |
| SharePoint | OAuth-delegated sync of a Microsoft 365 site/drive |
| WebDAV | Sync from a WebDAV server URL with credentials |
| Local | Point to an existing filesystem path |
| OneDrive | Mount a OneDrive location |
The panel shows a storage summary broken down by source type, and flags orphaned folders — extracted or cloned, but not attached to any schema — so they can be cleaned up. Creating a schema from a resource is a single action from the same panel.
Resource names may only contain lowercase letters, digits, underscores, and hyphens.
Each schema's Overview tab is the general settings surface. Fields you can change:
| Field | Notes |
|---|---|
| Owning organization | Re-registers the schema to a different org |
| Architecture | Free text, or use Auto-detect to have Codegraphs infer it |
| Child schema | Links a schema as a child of another |
| Display name, owner, description, notes | Metadata shown across the UI |
| Local path / Git source | Where the source lives — see Resource Management above |
| Encoding | utf-8, sjis, euc_jp, cp932, iso2022jp, or auto-detect |
| Incremental indexing | Only re-index changed files on subsequent runs |
Saving these settings pushes the change into the live search runtime immediately — no service restart required.
On mainframe platforms, file extensions are often missing or unreliable. A logical extension override maps a specific file to a different parser without renaming the file on disk or changing anything about the original source — it only affects how that one file is indexed.
# Example: index member "ACCT001" as COBOL
Schema → Files → ACCT001 → Set Logical Extension → cbl
Every override is recorded in a history log, so you can see what changed and when. Setting a file's logical extension back to its real extension (or clearing it) removes the override.
Changing a logical extension marks the schema as having a pending change — reindex to apply it, or save with auto-reindex enabled to do it in one step.
Codegraphs classifies files for display, search filtering, and architecture analysis using two independent mechanisms.
Every extension maps to one of a fixed set of built-in categories — source code, job control, screen definition, DB schema, config, build definition, document, log data, binary, unknown. You can remap which category an extension falls into, and set a per-extension color or mark it as binary.
For classification beyond the built-in set, define your own categories with a custom ID, label, color, and icon. Extended categories play no role in indexing — they exist purely for how files are displayed, searched, and grouped in architecture views.
| Field | Constraint |
|---|---|
| ID | Lowercase letters, digits, underscore; must start with a letter; 2–30 characters; cannot reuse a standard category ID |
| Label | Required |
| Color | Hex, rgb(), hsl(), or a named CSS color |
| Icon | Up to 4 characters |
If a preset exists for your schema's detected architecture, you can apply it to pre-fill a starting set of categories instead of defining every one by hand. Categories can be reordered for how they're displayed.
The Logical Entities tab maintains a glossary of named business or data entities and which source files define them — independent of the file-category classification above. Each entry has an ID, name, entity type, defining filenames, summary, keywords, and aliases.
Entities can be added by hand, bulk-imported/exported as a spreadsheet-friendly file, or auto-extracted for COBOL/AIM-based schemas:
| Auto-extract kind | What it finds |
|---|---|
| MQN / SMQN | Message-queue names (Fujitsu AIM), optionally including where each is used |
| External | COBOL 01 name EXTERNAL. shared-storage declarations |
This catalog powers entity-aware search and documentation. It does not affect how files are indexed.
Two independent exclusion mechanisms live in the Exclusion Settings tab.
.noindex)A gitignore-style file at the root of your source directory:
# .noindex
*.tmp # any file ending in .tmp
test/ # exclude a directory (trailing slash)
/build # anchored to the .noindex file's own location
!important.tmp # un-exclude a specific file
# starts a comment, blank lines are ignored, * matches any characters except /, and ** matches across directories.
A separate list of named members to exclude from call/dependency-relationship extraction — not from indexing itself — useful for skipping known false-positive CALL targets. One member name per line; scope a block to a specific extension with a [.ext] header. A read-only log on the same tab shows members that were automatically excluded because they matched a reserved keyword.
Indexing runs as a background job — creating or reindexing a schema queues the work and returns immediately with a job ID you can poll for status.
.noindex and member exclusions), parses each file with the appropriate parser (honoring any logical extension overrides), and extracts relationships (CALL, COPY, SQL, DD, and more).Most of the configuration changes described above — logical extensions, exclusions, settings — mark the schema as having a pending deploy. Reindex to build the change, then deploy to make it live; saving with auto-reindex enabled does both automatically.