present-in-scripts
Compatible static evidence exists in the analyzed script set. A database owner still validates effective access.
SQL operator handoff
Before anyone runs the scripts, make the evidence boundary visible.
A manager or database owner can review intended context, prerequisite candidates, protected handling steps, validation expectations, stop conditions, and gaps without turning static evidence into permission to execute.
Public claim level: demo. This is a synthetic, public-safe illustration of the merged sql-operator-runbook-packet/v2 contract. It is not raw scan output, executable SQL, runtime validation, or DBA approval.
Manager question
What can the repository establish before operator action?
Expected contextCategorical engine, server role, database role, schema role, and manual, scheduled, or validation-only mode.
Prerequisite candidatesChecked-in grant and ownership evidence labeled without claiming effective runtime authorization.
Protected stepsCategory-only handling flags for user mappings, connection material, remote query input, and scheduled command boundaries.
Validation expectationsA checked-in validation step is visible as intent; no query result or live database state is observed.
Stops and ownersMissing, conflicting, unknown, or reduced evidence becomes a stop condition and a named owner question.
Public-safe packet illustration
A compact handoff keeps proof and limitation together.
The rows below use synthetic categorical values. They show the fields a manager can discuss while omitting statement text, identities, credentials, connection data, scheduled bodies, and observed validation output.
context checkpoint 01admin / admin / extension / manual · independently verify the active pgAdmin tab, connection, server, and database · rule database.sql.context.declaration.v1 · Tier2Structural · complete · setup.sql:1-1 · sql-execution-context/0.1.0context transition 02archive-target / archive-data / archive / manual · wrong-tab and wrong-database review checkpoint · rule database.sql.context.declaration.v1 · Tier2Structural · complete · setup.sql:3-3 · sql-execution-context/0.1.0protected stepuser-mapping / credential-option · route material through an owner-approved process · rule database.sql.secret-bearing-step.v1 · Tier2Structural · complete · setup.sql:7-7 · sql-secret-safety/0.1.0permission candidateusage-foreign-server: present-in-scripts · checked-in compatible evidence only, not effective permission · rule database.postgres.permission.coverage.v1 · Tier2Structural · complete · setup.sql:7-7 · postgres-permission-evidence/0.1.0scheduled surfacepg_cron / scheduled · declaration only; no job execution is observed · rule database.postgres.archive-link.v1 · Tier2Structural · complete · setup.sql:15-15 · postgres-archive-link/0.1.0validation expectationvalidation-step-present / validation-evidence-not-provided · rule database.sql.context.declaration.v1 · Tier2Structural · complete · setup.sql:17-17 · sql-execution-context/0.1.0PostgreSQL-first surfaces
The packet names mechanisms without claiming they work.
postgres_fdwExtension, foreign-server, user-mapping, schema-import, foreign-table, and server-grant surfaces can be classified.
dblinkExtension and call boundaries are visible; connection material and remote query input remain protected.
Logical replicationPublication and subscription declarations can be paired as static candidates, never as proof of replication health.
pg_cronExtension and scheduled-operation surfaces create a scheduled context, not evidence that a job ran.
Permission language
Five statuses prevent a checked-in statement from becoming a runtime claim.
missing-evidence
No compatible checked-in evidence was found within current coverage. Runtime absence is not established.
conflicting-evidence
Static grant, revoke, context, or ordering evidence disagrees and needs review.
unknown
Identity, parsing, or coverage is insufficient for a stronger static status.
needs-owner-review
Administrative capability, cross-file order, protected handling, or context requires a human owner.
Milestones and validation
Intent and observation stay in different columns.
intended-by-scriptA supported extension, link, permission, publication, subscription, scheduled job, or cleanup candidate appears in checked-in evidence.validation-step-presentA validation-shaped step is checked in. TraceMap does not inspect its result.validation-evidence-not-providedV0 has no live connection and accepts no raw database output.Cleanup candidateA destructive or rollback-shaped step is intent only; reversibility and completion remain unknown.
Stop conditions and owner questions
A partial packet is useful only when it says where to stop.
- Stop when expected context is missing or conflicting; ask who verifies the active client connection and database.
- Stop at protected-material boundaries; ask who owns the approved credential and connection handling process.
- Stop when permission evidence is missing, conflicting, unknown, or administrative; ask a database owner to validate the prerequisite candidate.
- Stop when cross-file order is not established or parsing is reduced; ask who owns execution order and coverage review.
- Stop when a validation step or observation is not established; ask who performs independent validation outside TraceMap.
Non-claims
The handoff informs human review; it does not authorize action.
- TraceMap does not execute SQL, connect to a live database, or observe the selected pgAdmin tab.
- TraceMap does not certify a script for execution or establish that setup completed.
- TraceMap does not establish effective permissions, object existence, replication health, scheduled execution, validation results, or successful rollback.
- TraceMap does not replace database owners, operators, security review, change controls, tests, telemetry, logs, or human approval.
- The core scanner and reducer do not use LLM calls, embeddings, vector databases, or prompt-based classification.
Continue the proof path