Design-time metadata
Checked-in model designers, descriptor files, generated-designer relationships, and metadata format clues can frame a review question.
Legacy data surface evidence story
Data-surface review starts as static evidence, not database inspection.
This concept page shows how a future public story could frame legacy data metadata, mapping clues, query-facing references, persistence context, proof paths, and gaps from repository snapshots and checked-in artifacts.
Public claim level: concept. No public conclusion without evidence. This is a narrower data-surface story inside the legacy .NET evidence lane, not a shipped support page or a migration validator.
Placement
A bounded data lane, not a broader modernization claim.
legacy .NET laneThe broader lane names legacy framework families and proof posture; this page narrows the lens to static data-surface questions.hidden ledgerThe legacy evidence ledger remains the promotion boundary for hidden proof and validation detail.modernization mapThe modernization evidence map stays a planning map; this page keeps data evidence attached to limitations.Evidence families
Static clues can narrow owner questions, not answer runtime ones.
Data model metadata
Entity-like descriptors, storage-object descriptors, property or column descriptors, relationship clues, safe hashes, and normalized identities need proof before stronger wording.
ORM/mapping clues
Mapping documents, mapping attributes, generated-code links, and unsupported ORM metadata gaps remain deterministic static evidence questions.
SQL/query-facing references
Query builder calls, stored-procedure references, table or view references, checked-in query references, and call sites must be summarized without raw SQL or private values.
Storage/persistence context
Provider family, connection-name metadata, configuration surface presence, repository or service context, package clues, and owner handoff questions stay public-safe and static.
Limitations and analysis gaps
Unsupported metadata, malformed descriptors, missing generated code, failed project load, build failure, syntax fallback, and unknown evidence keep coverage labels visible.
Evidence-status matrix
Every family carries status, proof path, limitation, and owner follow-up.
| Evidence family | Possible static evidence | Evidence status | Proof path requirement | Limitation | Owner follow-up | Allowed wording | Forbidden wording |
|---|---|---|---|---|---|---|---|
| Design-time metadata | Checked-in model designer or descriptor files, generated-designer relationships, and metadata format clues. | concept |
Public-safe descriptor summary with rule family, evidence tier, coverage label, and limitation. | Does not prove tool designer execution, database connectivity, database state, or data contents. | Application owner verifies intended model source; database owner verifies live storage questions. | Concept: design-time metadata may frame a review question. | Forbidden example: TraceMap proves design-time models execute against a database. |
| Data model metadata | Entity-like descriptors, storage-object descriptors, property or column descriptors, relationship clues, safe hashes, and normalized identities. | concept |
Sanitized descriptor summary with rule family, evidence tier, coverage label, safe hashes, or normalized identities before stronger wording. | Does not prove live schema, rows, permissions, data values, or schema compatibility. | Database owner verifies schema and data-state questions; application owner verifies code intent. | Concept: data model metadata may identify static descriptors. | Forbidden example: TraceMap proves live schema compatibility or production data contents. |
| ORM/mapping clues | Mapping documents, mapping attributes, generated-code links, framework-specific mapping families, or unsupported ORM metadata gaps. | future |
Future public-safe rule IDs and evidence tiers; unsupported formats are labeled gap in implementation-specific rows. | Does not prove ORM runtime behavior, lazy loading, query generation, package compatibility, or persistence success. | Application owner reviews mapping intent; database owner reviews storage implications. | Future: ORM or mapping clues may be extractable as static evidence. | Forbidden example: TraceMap proves ORM mappings work at runtime. |
| SQL/query-facing references | Query-facing call sites, query builder calls, stored-procedure references, table or view references, or checked-in query references summarized without raw SQL. | future |
Future public-safe rule IDs confirming extraction without raw SQL exposure; unresolved references are labeled gap. | Does not prove query execution, runtime SQL text, database results, performance, permissions, or production usage. | Application owner reviews call-site intent; database owner reviews live query, schema, and permission questions. | Future: SQL/query-facing references may be identified without raw SQL. | Forbidden example: TraceMap executes SQL or proves runtime SQL behavior. |
| Storage/persistence context | Provider family, connection-name metadata, configuration surface presence, repository or service context, package or assembly clues. | concept |
Public-safe configuration or package summary with no raw values before stronger wording; unavailable proof becomes a gap. | Does not prove connectivity, credential validity, live database existence, or storage state. | Database owner verifies connectivity and storage; service owner verifies runtime configuration. | Concept: persistence context may provide handoff clues. | Forbidden example: TraceMap connects to your database or proves storage state. |
| Analysis gaps | Failed project load, parser bounds, unsupported metadata, malformed descriptors, missing generated code, build failure, syntax fallback, or unknown evidence. | gap |
Gap fact, reduced-coverage label, parser limitation, or validation result for the exact scenario. | Does not prove absence of data surfaces and does not convert failed build or load into clean coverage. | Engineering owner resolves build, load, or parser gaps, or accepts reduced evidence in review. | Gap: failed load, parser bounds, unsupported metadata, and syntax fallback remain labeled. | Forbidden example: failed load still proves complete data coverage. |
Proof paths
Stronger copy needs reviewed proof, not inference.
Required before conclusionsRule ID or rule family, evidence tier, coverage label, limitation, public-safe proof path, and reviewed provenance such as commit SHA, extractor version, file path, line span, supporting ID, or snippet hash when safe.
Artifact familiesPublic copy may name scan-manifest.json, facts.ndjson, index.sqlite, report.md, and logs/analyzer.log as artifact types, but it must not publish raw private contents from them.
Reducer boundaryThe page does not say a surface is impacted unless a reducer-backed finding and public-safe supporting evidence are present.
Boundaries
Non-claims stay visible.
- No raw source snippets, raw SQL, raw config values, secrets, tokens, connection strings, table dumps, raw fact streams, raw SQLite content, analyzer logs, raw remotes, local absolute paths, generated scan directories, private sample names, hidden validation details, raw command output, private URLs, or credential-like values.
- No database execution, database connectivity, runtime SQL behavior, production traffic, endpoint performance, outage cause, migration success, schema compatibility, release approval, release safety, operational safety, AI impact analysis, LLM analysis, embeddings, vector databases, or prompt classification.