WT-08 · proof-gated configuration
Workflow and reporting setup
Proof-gated contracts for attachment types, labels, worksheet templates, and subgroups with generated-output checks.
Before using this page
- Use only a designated non-production tenant with synthetic records.
- Confirm the exact effective role and route before changing anything.
- Capture the pre-state and the supported reversal before the first mutation.
- If any route, field, transition, or downstream effect differs, stop and mark the action tenant-dependent.
Tenant-dependent · runtime pending
CFG-30
Attachment Types
Who can do it: Separately authorized configuration administrator candidate.
Who cannot: Ordinary operational users and delegated LIMS User Admin. Upstream availability does not grant tenant authority.
Default navigation candidate: LIMS Setup → Attachment Types. The exact route and permission must be read back from the frozen tenant runtime.
Source-grounded contract
Create/edit; activate/deactivate
Existing evidence: workflows.xml:190-191
Field and dependency status
On a small screen, scroll the table horizontally to view every column.
| Area | Current contract | Release condition |
|---|---|---|
| Required and optional fields | Not yet accepted as a tenant-effective field contract. | Record visible labels, required markers, validation, immutable fields, and approved synthetic examples. |
| Dependencies | Use only prerequisites established by source and runtime. | Prove both valid selection and safe behavior when the prerequisite is absent or inactive. |
| Existing-record impact | No blanket retroactive-effect claim. | Compare a pre-existing synthetic record with a newly created one after the change. |
Proof-gated walkthrough
- Permission preflight: authenticate as the claimed owner and as a delegated LIMS User Admin; record allow and deny behavior.
- Route and field capture: record the exact route, labels, defaults, required fields, and validation without using real lab data.
- Smallest transaction: create or edit one uniquely named synthetic record only when the expected reversal is known.
- Persistence: read the value directly, restart the disposable runtime, and read it again.
- Downstream check: exercise the smallest dependent synthetic workflow; do not infer effects from a success notice.
- Reversal: restore the prior value or use the source-supported deactivate/reactivate transition. If neither exists, record Support/CTM ownership rather than invent deletion.
- Negative proof: repeat the route/action as an unauthorized persona and verify no partial mutation.
Step-to-proof matrix
On a small screen, scroll the table horizontally to view every column.
| Step | Required proof | Failure gate |
|---|---|---|
| Permission preflight | Effective roles, permission check, route status, and adjacent denial. | Unexpected access or redirect blocks publication. |
| Transaction | Exact request/action, success state, and object identifier using synthetic data. | Validation ambiguity, partial save, or unsupported field blocks publication. |
| Persistence | Direct readback before and after restart. | Toast-only evidence or changed post-state blocks publication. |
| Functional effect | Dependent synthetic selection, report, worksheet, QC, or label result where relevant. | No downstream proof means the effect remains unclaimed. |
| Reversal | Restored values/state and repeated readback. | No safe reversal changes disposition to Clearline-managed. |
Expected outcome and failures
The action remains non-executable in public documentation until every proof row passes. A missing route, different label, denied permission, validation mismatch, unsupported transition, or failed reversal is an expected stop condition—not a prompt to improvise.
Escalation evidence: sanitized tenant/build identity, role/account type, route, exact validation text, synthetic object identifier, pre/post state, and attempted reversal. Never include credentials, regulated data, customer records, results, reports, or production exports.
Tenant-dependent · runtime pending
CFG-31
Batch Labels
Who can do it: Separately authorized configuration administrator candidate.
Who cannot: Ordinary operational users and delegated LIMS User Admin. Upstream availability does not grant tenant authority.
Default navigation candidate: LIMS Setup → Batch Labels. The exact route and permission must be read back from the frozen tenant runtime.
Source-grounded contract
Create/edit; activate/deactivate
Existing evidence: workflows.xml:193-194
Field and dependency status
On a small screen, scroll the table horizontally to view every column.
| Area | Current contract | Release condition |
|---|---|---|
| Required and optional fields | Not yet accepted as a tenant-effective field contract. | Record visible labels, required markers, validation, immutable fields, and approved synthetic examples. |
| Dependencies | Use only prerequisites established by source and runtime. | Prove both valid selection and safe behavior when the prerequisite is absent or inactive. |
| Existing-record impact | No blanket retroactive-effect claim. | Compare a pre-existing synthetic record with a newly created one after the change. |
Proof-gated walkthrough
- Permission preflight: authenticate as the claimed owner and as a delegated LIMS User Admin; record allow and deny behavior.
- Route and field capture: record the exact route, labels, defaults, required fields, and validation without using real lab data.
- Smallest transaction: create or edit one uniquely named synthetic record only when the expected reversal is known.
- Persistence: read the value directly, restart the disposable runtime, and read it again.
- Downstream check: exercise the smallest dependent synthetic workflow; do not infer effects from a success notice.
- Reversal: restore the prior value or use the source-supported deactivate/reactivate transition. If neither exists, record Support/CTM ownership rather than invent deletion.
- Negative proof: repeat the route/action as an unauthorized persona and verify no partial mutation.
Step-to-proof matrix
On a small screen, scroll the table horizontally to view every column.
| Step | Required proof | Failure gate |
|---|---|---|
| Permission preflight | Effective roles, permission check, route status, and adjacent denial. | Unexpected access or redirect blocks publication. |
| Transaction | Exact request/action, success state, and object identifier using synthetic data. | Validation ambiguity, partial save, or unsupported field blocks publication. |
| Persistence | Direct readback before and after restart. | Toast-only evidence or changed post-state blocks publication. |
| Functional effect | Dependent synthetic selection, report, worksheet, QC, or label result where relevant. | No downstream proof means the effect remains unclaimed. |
| Reversal | Restored values/state and repeated readback. | No safe reversal changes disposition to Clearline-managed. |
Expected outcome and failures
The action remains non-executable in public documentation until every proof row passes. A missing route, different label, denied permission, validation mismatch, unsupported transition, or failed reversal is an expected stop condition—not a prompt to improvise.
Escalation evidence: sanitized tenant/build identity, role/account type, route, exact validation text, synthetic object identifier, pre/post state, and attempted reversal. Never include credentials, regulated data, customer records, results, reports, or production exports.
Tenant-dependent · runtime pending
CFG-32
Labels
Who can do it: Separately authorized configuration administrator candidate.
Who cannot: Ordinary operational users and delegated LIMS User Admin. Upstream availability does not grant tenant authority.
Default navigation candidate: LIMS Setup → Labels. The exact route and permission must be read back from the frozen tenant runtime.
Source-grounded contract
Create/edit; activate/deactivate
Existing evidence: workflows.xml:229-230
Field and dependency status
On a small screen, scroll the table horizontally to view every column.
| Area | Current contract | Release condition |
|---|---|---|
| Required and optional fields | Not yet accepted as a tenant-effective field contract. | Record visible labels, required markers, validation, immutable fields, and approved synthetic examples. |
| Dependencies | Use only prerequisites established by source and runtime. | Prove both valid selection and safe behavior when the prerequisite is absent or inactive. |
| Existing-record impact | No blanket retroactive-effect claim. | Compare a pre-existing synthetic record with a newly created one after the change. |
Proof-gated walkthrough
- Permission preflight: authenticate as the claimed owner and as a delegated LIMS User Admin; record allow and deny behavior.
- Route and field capture: record the exact route, labels, defaults, required fields, and validation without using real lab data.
- Smallest transaction: create or edit one uniquely named synthetic record only when the expected reversal is known.
- Persistence: read the value directly, restart the disposable runtime, and read it again.
- Downstream check: exercise the smallest dependent synthetic workflow; do not infer effects from a success notice.
- Reversal: restore the prior value or use the source-supported deactivate/reactivate transition. If neither exists, record Support/CTM ownership rather than invent deletion.
- Negative proof: repeat the route/action as an unauthorized persona and verify no partial mutation.
Step-to-proof matrix
On a small screen, scroll the table horizontally to view every column.
| Step | Required proof | Failure gate |
|---|---|---|
| Permission preflight | Effective roles, permission check, route status, and adjacent denial. | Unexpected access or redirect blocks publication. |
| Transaction | Exact request/action, success state, and object identifier using synthetic data. | Validation ambiguity, partial save, or unsupported field blocks publication. |
| Persistence | Direct readback before and after restart. | Toast-only evidence or changed post-state blocks publication. |
| Functional effect | Dependent synthetic selection, report, worksheet, QC, or label result where relevant. | No downstream proof means the effect remains unclaimed. |
| Reversal | Restored values/state and repeated readback. | No safe reversal changes disposition to Clearline-managed. |
Expected outcome and failures
The action remains non-executable in public documentation until every proof row passes. A missing route, different label, denied permission, validation mismatch, unsupported transition, or failed reversal is an expected stop condition—not a prompt to improvise.
Escalation evidence: sanitized tenant/build identity, role/account type, route, exact validation text, synthetic object identifier, pre/post state, and attempted reversal. Never include credentials, regulated data, customer records, results, reports, or production exports.
Tenant-dependent · runtime pending
CFG-33
Worksheet Templates
Who can do it: Separately authorized configuration administrator candidate.
Who cannot: Ordinary operational users and delegated LIMS User Admin. Upstream availability does not grant tenant authority.
Default navigation candidate: LIMS Setup → Worksheet Templates. The exact route and permission must be read back from the frozen tenant runtime.
Source-grounded contract
Create/edit service/method/instrument layout; activate/deactivate
Existing evidence: rolemap.xml:347-352; workflows.xml:277-278
Field and dependency status
On a small screen, scroll the table horizontally to view every column.
| Area | Current contract | Release condition |
|---|---|---|
| Required and optional fields | Not yet accepted as a tenant-effective field contract. | Record visible labels, required markers, validation, immutable fields, and approved synthetic examples. |
| Dependencies | Use only prerequisites established by source and runtime. | Prove both valid selection and safe behavior when the prerequisite is absent or inactive. |
| Existing-record impact | No blanket retroactive-effect claim. | Compare a pre-existing synthetic record with a newly created one after the change. |
Proof-gated walkthrough
- Permission preflight: authenticate as the claimed owner and as a delegated LIMS User Admin; record allow and deny behavior.
- Route and field capture: record the exact route, labels, defaults, required fields, and validation without using real lab data.
- Smallest transaction: create or edit one uniquely named synthetic record only when the expected reversal is known.
- Persistence: read the value directly, restart the disposable runtime, and read it again.
- Downstream check: exercise the smallest dependent synthetic workflow; do not infer effects from a success notice.
- Reversal: restore the prior value or use the source-supported deactivate/reactivate transition. If neither exists, record Support/CTM ownership rather than invent deletion.
- Negative proof: repeat the route/action as an unauthorized persona and verify no partial mutation.
Step-to-proof matrix
On a small screen, scroll the table horizontally to view every column.
| Step | Required proof | Failure gate |
|---|---|---|
| Permission preflight | Effective roles, permission check, route status, and adjacent denial. | Unexpected access or redirect blocks publication. |
| Transaction | Exact request/action, success state, and object identifier using synthetic data. | Validation ambiguity, partial save, or unsupported field blocks publication. |
| Persistence | Direct readback before and after restart. | Toast-only evidence or changed post-state blocks publication. |
| Functional effect | Dependent synthetic selection, report, worksheet, QC, or label result where relevant. | No downstream proof means the effect remains unclaimed. |
| Reversal | Restored values/state and repeated readback. | No safe reversal changes disposition to Clearline-managed. |
Expected outcome and failures
The action remains non-executable in public documentation until every proof row passes. A missing route, different label, denied permission, validation mismatch, unsupported transition, or failed reversal is an expected stop condition—not a prompt to improvise.
Escalation evidence: sanitized tenant/build identity, role/account type, route, exact validation text, synthetic object identifier, pre/post state, and attempted reversal. Never include credentials, regulated data, customer records, results, reports, or production exports.
Tenant-dependent · runtime pending
CFG-34
Subgroups
Who can do it: Separately authorized configuration administrator candidate.
Who cannot: Ordinary operational users and delegated LIMS User Admin. Upstream availability does not grant tenant authority.
Default navigation candidate: LIMS Setup → Subgroups. The exact route and permission must be read back from the frozen tenant runtime.
Source-grounded contract
Create/edit; activate/deactivate
Existing evidence: rolemap.xml:309-314; workflows.xml:268-269
Field and dependency status
On a small screen, scroll the table horizontally to view every column.
| Area | Current contract | Release condition |
|---|---|---|
| Required and optional fields | Not yet accepted as a tenant-effective field contract. | Record visible labels, required markers, validation, immutable fields, and approved synthetic examples. |
| Dependencies | Use only prerequisites established by source and runtime. | Prove both valid selection and safe behavior when the prerequisite is absent or inactive. |
| Existing-record impact | No blanket retroactive-effect claim. | Compare a pre-existing synthetic record with a newly created one after the change. |
Proof-gated walkthrough
- Permission preflight: authenticate as the claimed owner and as a delegated LIMS User Admin; record allow and deny behavior.
- Route and field capture: record the exact route, labels, defaults, required fields, and validation without using real lab data.
- Smallest transaction: create or edit one uniquely named synthetic record only when the expected reversal is known.
- Persistence: read the value directly, restart the disposable runtime, and read it again.
- Downstream check: exercise the smallest dependent synthetic workflow; do not infer effects from a success notice.
- Reversal: restore the prior value or use the source-supported deactivate/reactivate transition. If neither exists, record Support/CTM ownership rather than invent deletion.
- Negative proof: repeat the route/action as an unauthorized persona and verify no partial mutation.
Step-to-proof matrix
On a small screen, scroll the table horizontally to view every column.
| Step | Required proof | Failure gate |
|---|---|---|
| Permission preflight | Effective roles, permission check, route status, and adjacent denial. | Unexpected access or redirect blocks publication. |
| Transaction | Exact request/action, success state, and object identifier using synthetic data. | Validation ambiguity, partial save, or unsupported field blocks publication. |
| Persistence | Direct readback before and after restart. | Toast-only evidence or changed post-state blocks publication. |
| Functional effect | Dependent synthetic selection, report, worksheet, QC, or label result where relevant. | No downstream proof means the effect remains unclaimed. |
| Reversal | Restored values/state and repeated readback. | No safe reversal changes disposition to Clearline-managed. |
Expected outcome and failures
The action remains non-executable in public documentation until every proof row passes. A missing route, different label, denied permission, validation mismatch, unsupported transition, or failed reversal is an expected stop condition—not a prompt to improvise.
Escalation evidence: sanitized tenant/build identity, role/account type, route, exact validation text, synthetic object identifier, pre/post state, and attempted reversal. Never include credentials, regulated data, customer records, results, reports, or production exports.