Schemas
The bootstrap does not provide
dl_resolved.people, dl_graph, dl_cache, or
dl_override as a managed identity-graph contract.
SQL API
POST /api/v2/db/query accepts one SQL statement and max_rows (up to 1,000).
The response contains rows, columns, row_count_returned, and truncated.
The SDK equivalent is client.db.query({ sql, maxRows }).
Reads include SELECT, read-only WITH, and EXPLAIN subject to the query
policy. Writes must identify a schema-qualified target in storage or an
allowed customer-managed schema. Managed data, internal runtime objects,
public, information_schema, and pg_* schemas are not customer write targets.
Retired internal schema names are also reserved. Choose a new schema name
when the query API reports a reserved target.
Example against a provisioned company table:
Roles and direct connections
dl_ingest_customer_db: This customer connection role reads managed tables. Ownership grants let this role own permitted customer storage objects.dl_ingest_runtime: This Deepline runtime role can write managed ingestion data and customer storage.dl_ingest_customer_owner: ownership role for customer-managed objects.dl_ingest_owner,dl_ingest_storage_owner, anddl_ingest_protected_owner: platform ownership roles, not customer credentials.
Persistence and caching
Saved database rows and reusable tool-call results serve different purposes. Persistence alone does not make future provider requests free. The SDK freshness options control durable call reuse:
Edition 11 requires an explicit choice. Earlier admitted editions retain their
omitted-value behavior. The admitted
authoring contract determines the applicable rules.
Reuse also depends on the operation, inputs, authentication identity, and
version policy. Certain live-state tools are always fresh. Plays execute at least once. Cache reuse does not guarantee that a provider effect occurs exactly once.