6. Settings Reference
Forge settings are stored in Obsidian plugin data.
All paths are vault-relative and should not begin with:
/
Most users can start with the defaults and customize gradually as their workflows evolve.
Documentation
| Setting | Meaning |
|---|---|
| Install Documentation | Installs bundled docs and examples into A-I/Forge/Engine |
The installer skips existing files so local edits remain untouched.
General Paths
These settings define where Forge stores operational files inside the vault.
| Setting | Default | Meaning |
|---|---|---|
| System folder | System | Base folder for operational vault content |
| Forge folder | System/Forge | Forge docs, examples, exports, patches, and generated files |
| Schema note | System/Registry/schema.md | Schema used by validation and lint workflows |
| Default patch file | System/Forge/Patches/vault-patch.md | Patch note loaded by Apply Vault Patch |
| Inbox folder | System/Inbox | Staging area used by workflows and maintenance |
| Exports folder | System/Exports | Export output, lint reports, dashboards, and indexes |
Most users should avoid changing paths frequently after workflows are established.
Stable paths make exports, dashboards, and automation easier to maintain.
Lint Tab
Vault Lint checks notes against schemas, metadata rules, inline metadata rules, and optional shape validation.
| Setting | Default | Meaning |
|---|---|---|
| Schema note | System/Registry/schema.md | Path to the schema note Forge reads |
| Version field location | Inline | Where the schema version lives — inline metadata or frontmatter |
| Version field | version | Which field holds the schema version; schema-driven dropdown |
| Prefill from schema | n/a | Loads field and value choices from the current schema |
| Strict mode | Off | Raises selected shape validation severities to error |
| Lint run retention | 20 | Number of lint run notes to keep |
| Lint file links | Off | Writes file paths as Obsidian links in reports |
| Lint inline metadata | On | Validates key:: value metadata against inline.allowed |
| Repair prompt threshold | Errors only | When the Open Vault Repair button appears after lint |
| Enable stale note review | Off | Flags notes whose review cycle has elapsed |
| Cycle field | review_cycle | Schema-driven dropdown — field containing review cadence |
| Updated field | updated | Schema-driven dropdown — field containing last updated date |
| Filter field | status | Schema-driven dropdown — field limiting stale review scope |
| In-scope values | Empty | Values of the filter field included in stale review |
Recommended starting point:
- enable inline metadata lint
- keep strict mode off initially
- enable stale review later if needed
Patch Tab
Patch settings control backups, restore manifests, and post-patch workflows.
| Setting | Default | Meaning |
|---|---|---|
| Patches folder | System/Forge/Patches | Patch workspace and history folder |
| Backup before patch | On | Creates backups before confirmed patch writes |
| Backup folder | System/Forge/Patches/Backups | Patch backup destination |
| Generate restore manifest | On | Writes restore data for Restore Patch Run |
| Run lint after patch | On | Runs Vault Lint after successful patch apply |
| Run maintenance after patch | Off | Runs maintenance automatically after patch apply |
Recommended default:
- keep backups enabled
- keep restore manifests enabled
- keep auto-lint enabled
- leave automatic maintenance off initially
Maintenance Tab
Maintenance trims generated operational history and report files over time.
Maintenance does not clean personal notes.
| Setting | Default | Meaning |
|---|---|---|
| Backup retention days | 14 | Age cutoff for old patch backups |
| Inbox retention days | 30 | Age cutoff for stale inbox handling |
| Inbox retention action | Delete in maintenance | Either remove stale inbox notes during maintenance or list them under Needs Review after Vault Lint |
| Lint history retention days | 14 | Age cutoff for lint history entries |
| Lint history max entries | 20 | Hard cap for lint history entries |
| Patch report retention | 20 | Number of patch reports to keep |
Longer retention is useful during large migrations or schema redesigns.
Export Tab
Export settings control inventory exports, dashboards, and relationship indexes.
| Setting | Default | Meaning |
|---|---|---|
| Enable export | Off | Enables export commands and export settings |
| Export Vault Overview | n/a | Runs overview export from settings |
| Export Ontology Index | n/a | Runs relationship index export |
| Dashboard note name | Blank | Optional dashboard filename |
| Private notes | Off | Enables private-note detection |
| Private field | Blank | Frontmatter field used as private flag |
| Domain field | Blank | Field used as domain grouping |
| Type field | Blank | Field used as type grouping |
| Status field | Blank | Field used as status grouping |
| Reload from schema | n/a | Refreshes export field and value choices |
| Filter field | Blank | Field used to group relationship indexes |
| Filter values | Empty | Values exported as relationship indexes |
| Relationship heading | Related | Heading scanned for relationship links |
| Excluded folders | Empty | Folders excluded from export processing |
Relationship indexes become much more useful when metadata remains consistent across the vault.
Shapes Tab
Shapes validate reusable note structures and heading organization.
| Setting | Default | Meaning |
|---|---|---|
| Enable Vault Shape Engine | Off | Enables shape workflows |
| Shapes folder | System/Shapes | Folder containing shape notes |
| Include subfolders | Off | Reads shape notes inside nested folders |
| Enable template refinement | Off | Allows templates to be generated from shape notes |
| Run refinement | n/a | Generates template notes from shape definitions |
| Enable shape heading validation | Off | Includes shape validation during Vault Lint |
| Lint scope | all | Lint all notes or selected folders |
| Lint folders | Empty | Folder list used when scope is folder |
| Enable shape repair | Off | Enables shape repair commands |
| Repair scope | all | Repair all notes or selected folders |
| Repair folders | Empty | Folder list used when repair scope is folder |
| Repair file links | Off | Writes repaired file paths as wikilinks |
| Repair history retention | 20 | Number of shape repair history entries to keep |
| Run shape repair | n/a | Runs shape repair from settings |
| Run dry run | n/a | Previews repairs without writing changes |
| Type target field | type | Field matched to shape or template names |
| Created field | created | Date field stamped by templates |
| Updated field | updated | Date field stamped by templates |
| Inject relationship headings | Off | Injects relationship headings from ontology.relationships into templates |
| Relationship parent heading | Related | Heading name for the relationship section |
| Relationship heading level | H2 | Heading level for the parent; subheadings are always one level below |
| Relationship injection position | Append | Append section at end, or inject under existing heading |
| Template fields | Schema-derived | Fields included in generated templates |
Most users should start with:
- shape validation enabled
- repair disabled initially
- dry runs before actual repairs
Frontmatter Field Order
Forge uses the configured frontmatter field order when:
- writing notes
- sorting frontmatter
- applying repairs
- normalizing metadata
Fields not explicitly listed are appended alphabetically afterward.
Consistent field ordering improves:
- readability
- diffs
- review workflows
- template consistency
- Dataview reliability
Recommended Starting Configuration
For most users:
- keep default paths
- enable inline metadata lint
- keep patch backups enabled
- keep restore manifests enabled
- leave strict mode off initially
- experiment with exports after schemas stabilize
- start shape workflows gradually
Forge works best when adopted incrementally instead of all at once.
