Asset Context Curation
The Context tab on every asset is a living workspace where you feed information to the AI curation engine. The engine processes your inputs and returns an Understanding document — a structured markdown summary of what it knows about the asset — alongside concrete suggestions for properties, links to other assets, and child assets to create. All suggestions are human-confirmed; nothing is written to your assets automatically.
How Curation Works
Curation is triggered automatically in the background whenever you add a context note or upload a document to an asset. The engine:
- Assembles the asset’s corpus — all context notes, uploaded documents, inherited material from ancestor assets, and the structured facts already in VSEC: current property values, fully-expanded Record data (with record attachments), and the names of linked assets and risks.
- Computes a corpus hash. If the hash matches the last run, the asset is skipped (no re-billing for unchanged assets). Clicking Re-curate bypasses this check and always runs.
- Sends the corpus to the configured intelligence provider.
- Stores the result: updated Understanding document + structured suggestion rows.
Corpus Limits
| Limit | Value |
|---|---|
| Max text per document | 60,000 characters |
| Max total corpus text | 200,000 characters |
| Max media files (vision) | 6 files |
| Max media size per file | 20 MB |
| Max media total | 28 MB |
| Ancestor depth for inherited context | 5 levels |
Inherited Context
Descendants automatically inherit context from their ancestors (up to 5 ancestor levels): each ancestor’s Understanding document is folded into the corpus, truncated to 4,000 characters per ancestor, and each ancestor’s PDF and image files ride along as vision media. Ancestor text and office documents are not re-read — their content reaches the child only through the ancestor’s Understanding. Curating a parent asset therefore enriches the context available to all of its children without any manual re-upload.
Adding Context Notes
Context notes are free-text observations, summaries, or any other information you want the engine to consider. Example: “The team confirmed this ECU has a debug UART on pins 4 and 5.”
- Open an asset and click Add context in the header (or Add context… from the asset’s right-click menu).
- On the Add context tab of the dialog, type your note under What do you know about this asset?
- Click Add context. The note is saved and a background curation run is queued.
Notes are stored individually and listed in the Context tab’s Context notes panel. You can delete a note at any time from there; deletion also queues a curation re-run.
Uploading Documents
The engine can ingest a wide range of file formats to extract text and visual content.
Supported Formats
| Category | Formats |
|---|---|
| Office documents | .docx, .pptx, .xlsx and their ODF equivalents (.odt, .odp, .ods) |
| Spreadsheets | .xls, .xlsm, .xlsb |
| Plain text | .txt, .md, .csv, .json, .log, .xml, .yaml, .yml, .html |
.pdf — sent whole to the provider’s vision capability (no local text extraction) | |
| Images | .png, .jpg, .jpeg, .gif, .webp — sent to vision |
- Open an asset and click Add context in the header (or Add context… from the right-click menu).
- On the Add context tab of the dialog, click Attach files and select one or more files, then click Add context to submit them (a note is optional alongside them).
- Per-file ingestion status is displayed in the Context tab’s Documents in context list and updates as each file is processed.
Ingestion Status
Each uploaded file shows a color-coded status chip after curation:
| Status | Color | Meaning |
|---|---|---|
full / vision | Green | File was fully ingested |
truncated / not_reached | Yellow | File was partially read (corpus size limit reached) |
skipped_provider | Yellow | PDFs skipped because the active provider lacks PDF vision |
skipped_too_big / skipped_unreadable | Red | File could not be processed |
skipped_unsupported / skipped_empty | Grey | Format not supported or file was empty |
pending | Blue | Processing in progress |
A summary line shows “X of Y files ingested in the last curation.”
The Understanding Document
After curation, the Understanding section displays a markdown document written by the AI describing what it knows about the asset: its purpose, interfaces, connectivity, data and functions, and open questions. This document is re-generated on every curation pass and serves as the anchor for all downstream suggestions.
Reviewing Suggestions
Curation produces four categories of suggestions — properties, links, link removals, and child assets — each shown in its own section. Use the Apply selected (N) button to commit accepted rows.
Property Suggestions
The engine proposes values for every property defined by the asset’s type, covering:
- Scalar fields — plain text or numeric values
- Single-select enumerations — one value chosen from the type’s allowed list
- Multi-select / tag fields — zero or more values from the allowed list
Record-type properties are excluded from AI property proposals — their values reference human-managed record instances, so the engine never proposes values for them.
Each row shows the property name, current values (outlined chips), the proposed values (filled chips for new values), and a rationale. For multi-valued properties, accepting a suggestion adds the proposed values without removing existing ones.
Link Suggestions
The engine identifies existing assets in your workspace that appear to be related to the current asset. Each suggestion shows the candidate asset name, its type, and the evidence from the corpus.
Select the rows you want and click Apply selected to create the links.
Link Removal Suggestions
The engine can also propose detaching existing links it believes no longer belong, based on the corpus. Removals are destructive, so they are held to a higher bar: only assets that are actually still linked are surfaced, low-confidence removal suggestions are dropped server-side, and rows are opt-in — nothing is detached without explicit confirmation. Accepting a removal detaches the link only; it never deletes the linked asset.
Child Asset Suggestions
When the corpus contains evidence of sub-components, sub-features, or other children not yet in the hierarchy, the engine surfaces them as candidates with a confidence rating.
| Confidence | Default selection | Meaning |
|---|---|---|
| High | Pre-checked | Asset is named explicitly in the context |
| Medium | Unchecked | Asset is inferred from context |
Low-confidence child suggestions are never shown — they are dropped server-side before the list reaches the UI.
Accepting Child Asset Suggestions
- Review the suggested children and their rationales.
- Check the ones you want to create.
- Click Create selected (N).
- The platform creates each new asset, links it as a child, generates initial property values from the parent’s corpus, and seeds it with a provenance note explaining its origin so its own curation loop can continue downward.
API Reference
All paths are relative to /api/v1/asset-manager.
| Method | Path | Description |
|---|---|---|
GET | /assets/:id/context | Fetch current context, understanding, and all suggestion rows. |
POST | /assets/:id/context/entry | Add a new context note. Body: { text } |
DELETE | /assets/:id/context/entry/:entryId | Delete a context note. |
POST | /assets/:id/context/apply | Apply confirmed suggestions. Body: confirmedProperties, confirmedLinks, confirmedRemoveLinks. Child assets are created via create-assets, not here. |
POST | /assets/:id/context/create-assets | Create accepted child-asset suggestions. Body: { uuid, children: [{name, type}] } |
POST | /assets/:id/context/analyze | Trigger a forced re-curation run (ignores corpus hash). |
Database Schema
Two schema objects underpin the context system.
am_asset_context (one row per asset, extended by this release)
| Column | Type | Notes |
|---|---|---|
lastCorpusHash | VARCHAR(64) | SHA-1 of the last curated corpus; prevents redundant re-runs. Added by idempotent bootstrap migration. |
am_asset_context_entries (new table — one row per context note)
| Column | Type | Notes |
|---|---|---|
id | int PK | Auto-generated. |
baseAssetId | FK → AMAssets | The asset this note belongs to. |
source | varchar(16) | 'user' for notes typed in the UI; 'system' for provenance notes seeded on child-asset creation; 'email' for submissions from an outside person via a context-request magic link. |
text | mediumtext | The free-text note body. |
authorEmail | varchar, nullable | Attribution for an external (source='email') contributor who is not a VSEC user. |
authorName | varchar, nullable | Display name for an external contributor. |
createdBy | FK → User | Optional — set to the acting user’s ID (null for external contributors). |
createdAt | datetime | Auto-managed. |
updatedAt | datetime | Auto-managed. |
Both schema changes are applied automatically on server startup via idempotent bootstrap checks — no manual migration is required.