{"version":"2.1.265","anchor":"db-write-schema-gains-as-level-as-level-confirmed-fields","canonical_anchor":"artifact-db-readwrite-gains-an-as-level-run-as-parameter","heading":"Artifact db_read\/db_write gain an as_level run-as parameter with server-confirmed enforcement","tier":"use","area":"Artifacts","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/db-write-schema-gains-as-level-as-level-confirmed-fields","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Artifact db_read\/db_write gain an as_level run-as parameter with server-confirmed enforcement\n\nArtifact database calls can now request a different access level, and results say whether the server actually enforced it\n\n**Unclear.** What as_level and as_level_confirmed actually represent or enable is not established by this finding.\n\n**What**\n\n- `db_read` and `db_write` calls can now include an `asLevel` parameter (returned as `as_level`), letting a call ask to run as if at a different access level.\n\n- Results now include `as_level_confirmed` (from the server's `levelConfirmed` field), reporting whether the server actually enforced the requested level; when unconfirmed, a caveat message is added.\n\n- The batch-write fallback path also tracks this confirmation across a sequence of writes, and appends a warning to error messages when a requested level wasn't confirmed, noting the writes may have run at the caller's own level instead.\n\n- The `db_write` validation schema was updated to accept the new `as_level` (max 16 characters) and `as_level_confirmed` fields.\n\n**Why** This makes it clear when an artifact database operation requesting an elevated or different access level actually got that treatment from the server, instead of silently succeeding or failing under the wrong permissions.\n\n- Area: Artifacts\n- Names: `as_level`, `as_level_confirmed`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 2\/5\n- Present in the build but not switched on"}