diff --git a/wiki/CatalogLaneScaffoldContract.md b/wiki/CatalogLaneScaffoldContract.md
new file mode 100644
index 0000000..f8faaf2
--- /dev/null
+++ b/wiki/CatalogLaneScaffoldContract.md
@@ -0,0 +1,82 @@
+# Catalog lane scaffold contract — P4 owner proposal
+
+Date: 2026-10-03 · Owner: ops-warden · Work: WARDEN-WP-0041
+Origin: CUST-WP-0075; proposal 79549660-4fc8-44d5-989e-074f6c7b6f07.
+Status: proposed seam for railiance-platform review. This document authorizes no apply.
+
+## Existing surfaces
+
+`src/warden/plan.py::_ccr_stub` offers a prose checklist for an unroutable need.
+It does not create files or a CCR-schema-valid request. `RouteEntry` and
+`routing/catalog.py` already define and validate the pointer catalog;
+`wiki/playbooks/catalog-lane-promotion.md` defines promotion evidence.
+The platform's `scripts/credential-change.py` already validates CCR v1,
+renders policy/role metadata and operator runbooks, and records lifecycle evidence.
+The missing piece is reviewed draft generation across these owner surfaces,
+not another policy applier or approval implementation.
+
+## Ownership and proposed input
+
+The first supported shape is one exact KV-v2 workload read lane. Login,
+ceremony, dynamic-secret and tenant paths need their own reviewed extensions;
+no generic fallback may manufacture an identity or auth binding.
+
+A proposed non-secret input document has `schema_version: 1`, `lane_id`,
+`title`, `need_keywords`, `consumer_repo`, `owner_repo`, `workload_ref`,
+`risk`, `wiki_ref`, `canon_ref`, and `platform_request_ref`.
+`workload_ref` uses the existing catalog structure without inference from a
+repository, lane name or secret path. Missing owner identity remains explicit
+`unknown_reason`. `risk` must be supplied and covers the entire readable path.
+`platform_request_ref` points to the platform-owned draft request rather than
+duplicating its path, field set, policies, auth-role claims or ESO bindings.
+The two references must point to their reviewed eventual owner destinations.
+
+ops-warden owns validation of those catalog fields and a draft catalog fragment
+plus playbook checklist. It owns no CCR renderer. railiance-platform owns the
+CCR schema/input extension, CCR draft, policy/role rendering, ESO manifest and
+evidence scaffold under RPF-WP-0050-T04. Its implementation must decide and
+publish the precise platform request schema and invocation; this proposal
+contains no invented command to invoke it.
+
+## Output and verification contract
+
+Generation writes into a caller-selected staging directory and fails on any
+existing output by default. It does not insert into a live catalog, modify an
+owner repo, call OpenBao, query credentials, approve a request or contact a
+cluster. File names and references are deterministic and contain no values.
+
+The catalog fragment always has `status: draft`, `warden_executes: false`,
+`exec_capable: false`, and no executable fetch command. Delegation and rotation
+remain explicit owner-reviewed questions, never an inferred permanent proxy.
+The playbook is a checklist with owner pointers, not a copied platform procedure.
+
+Platform output remains `status: proposed`, frontdoor pending-review and
+unresolvable, with no approval, bound-claims confirmation or verification
+receipt invented. A draft is not an admission or a capability. ExternalSecret
+metadata must retain the current annotation-containment requirements. Evidence
+scaffolds use metadata/capability checks and contain no secret reads or raw
+subprocess error dumps. The platform owner chooses those implementations.
+
+Offline acceptance covers schema/unknown-field errors, collision refusal,
+round-trip catalog validation, missing identity, explicit risk, secret-material
+rejection, immutable input, no network/subprocess execution, and all outputs
+remaining draft. A representative platform fixture must prove cross-owner
+references and field mapping before end-to-end generation is claimed.
+
+## Activation remains separate
+
+Review and merge of generated metadata does not replace CCR approval,
+confirmed identity/auth bindings, attended value provisioning, deployment
+approval or positive/negative evidence. Existing catalog promotion criteria
+still apply. Novel authority, trust-root or value-delivery design needs its
+own work record; routine lanes fitting an accepted template may become PRs.
+The proposal's “only the value step needs the window” is a goal, not a claim
+that current approvals disappeared.
+
+## Evidence receipt
+
+Source review: catalog models/validator, `_ccr_stub`, promotion checklist,
+platform credential-change validator and CCR-2026-0031 (metadata only).
+Knowledge: emergent-security 0.2.6, start and local-work, verified-files,
+orientation-only; package digest
+`8d1d6a9d4d07fec7b619618de7dfe2be2254c1790f85f4198c7fe19db9751c02`.
diff --git a/workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md b/workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md
new file mode 100644
index 0000000..22f9fc7
--- /dev/null
+++ b/workplans/WARDEN-WP-0041-catalog-lane-scaffolding.md
@@ -0,0 +1,78 @@
+---
+id: WARDEN-WP-0041
+type: workplan
+title: "Draft catalog lane scaffolding with platform-owned credential rendering"
+domain: infotech
+repo: ops-warden
+status: ready
+flavor: implementation
+owner: ops-warden
+topic_slug: netkingdom
+created: "2026-10-03"
+updated: "2026-10-03"
+depends_on: []
+---
+
+Accepts the ops-warden portion of P4 from CUST-WP-0075, proposal message
+`79549660-4fc8-44d5-989e-074f6c7b6f07`. The platform owns its renderer and
+CCR schema; no production act or approval is included here.
+
+## Establish the catalog and platform seam
+
+```task
+id: WARDEN-WP-0041-T01
+status: done
+priority: medium
+```
+
+Reviewed existing catalog validation, plan CCR stub, promotion checklist and
+platform CCR rendering. The stub does not scaffold; platform rendering already
+exists for reviewed CCRs. Proposed exact owner seam, inputs, fail-safe draft
+outputs and offline acceptance in `wiki/CatalogLaneScaffoldContract.md`.
+Platform's matching owner task is `RPF-WP-0050-T04`.
+
+## Implement offline draft catalog and playbook generation
+
+```task
+id: WARDEN-WP-0041-T02
+status: todo
+priority: medium
+```
+
+Implement the ops-warden portion of the seam proposal: deterministic staging
+output, validated catalog fields, draft-only defaults, collision refusal,
+explicit workload unknowns and risk, no secret inputs, no credential execution.
+Add meaningful rejection/round-trip fixtures; reuse catalog validation. Do not
+write platform-owned artifacts or invent its CLI. The local fragment generator
+can progress independently while platform contract review is pending.
+
+## Verify the accepted cross-owner scaffold
+
+```task
+id: WARDEN-WP-0041-T03
+status: wait
+priority: medium
+depends_on:
+  - WARDEN-WP-0041-T02
+  - RPF-WP-0050-T04
+blocked_on: message-from:railiance-platform
+blocking_reason: "Platform owner must confirm the request schema/invocation and deliver its CCR/policy-role/ESO/evidence scaffold with an offline fixture."
+```
+
+Integrate through reviewed owner references and demonstrate one exact KV-v2
+workload-read fixture end to end. Record both owner commits and validation
+results. Generation success alone does not admit or activate a lane. Update
+`warden plan`'s unroutable guidance only once a real supported command exists.
+
+## Report owner uptake and gates
+
+```task
+id: WARDEN-WP-0041-T04
+status: done
+priority: medium
+```
+
+Return the scoped P4 acceptance and this live owner record to the-custodian's
+original proposal thread. Existing admission, approval, identity confirmation,
+attended values and deployment evidence gates remain; no secret read or
+production action was taken. Source/knowledge receipt is in the seam document.